On Fri, 2018-06-22 at 08:05 +, marc marc wrote:
> Le 22. 06. 18 à 01:26, Yves a écrit :
> > Why adding 'platform' where there's no physical platform?
>
> public_transport=platform describe where passagers wait
> for a public transport.
> if there is no dedicated area, use a node outside the ro
On Tue, 2018-06-19 at 15:13 +, marc marc wrote:
> Le 19. 06. 18 à 16:30, Daniel Koć a écrit :
> > I realized that highway=platform is not only marked on wiki as much
> > less
> > popular, but is also really 10 times less popular in the database.
>
> and for 93 906 highway=platform, 84 031 alre
On Fri, 2016-04-08 at 17:03 +0300, Александр wrote:
> Sorry, this is link
> https://wiki.openstreetmap.org/wiki/AssociatedAddress_(new)
>
There's already a relation in use that solves that problem
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature
/Markus
__
On 27 May 2015 at 10:48, Martin Koppenhoefer wrote:
>
> 2015-05-27 10:38 GMT+02:00 Markus Lindholm :
>>
>> On 27 May 2015 at 09:48, Martin Koppenhoefer
>> wrote:
>> >> Am 27.05.2015 um 09:38 schrieb Jean-Marc Liotier :
>> >> Also, the address mu
On 27 May 2015 at 09:48, Martin Koppenhoefer wrote:
>> Am 27.05.2015 um 09:38 schrieb Jean-Marc Liotier :
>> Also, the address must be unique
> why?
Otherwise they make bad routing targets
/Markus
___
Tagging mailing list
Tagging@openstreetmap.org
htt
On 7 May 2015 at 19:02, Janko Mihelić wrote:
> +1 for solution 1. It's the most future-safe, it's easiest to explain, and
> most likely not to be misunderstood by new mappers. A few extra nodes is a
> small price.
+1
/Markus
___
Tagging mailing list
On 18 March 2015 at 08:21, Frederik Ramm wrote:
> So please, don't go over board here by trying to force-involve every
> mapper in tag votes; they're simply not important enough, and they
> *should not be*. Don't try to make them important, lasting, or binding.
+1
A thought, how difficult would
On 15 March 2015 at 10:17, Andreas Goss wrote:
>> in this case the reception will refer to the company and not to the
>> building.
>
>
> How?
Have a look at the provides_feature relation
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature
if it might work for you to create an e
On 11 March 2015 at 23:52, Martin Koppenhoefer wrote:
>> Am 11.03.2015 um 19:43 schrieb Markus Lindholm :
>>
>> reference to
>> the definition found in Wikipedia and that's also how I've used the
>> tag.
>
> and if someone changes the Wikipedia page
On 11 March 2015 at 20:14, althio wrote:
>
> On Mar 11, 2015 7:44 PM, "Markus Lindholm"
> wrote:
>>
>> On 11 March 2015 at 18:04, althio wrote:
>> > The trouble is there is no definition yet of city_block
>>
>> Not so. When I added i
On 11 March 2015 at 18:04, althio wrote:
> The trouble is there is no definition yet of city_block
Not so. When I added it to osm wiki I also put there a reference to
the definition found in Wikipedia and that's also how I've used the
tag.
/Markus
___
On 9 February 2015 at 12:58, Martin Koppenhoefer wrote:
> 2015-02-09 8:29 GMT+01:00 Markus Lindholm :
>> The road isn't between the tracks.
> you could understand this by looking at the width of the road.
Doesn't seem to be an ideal solution to draw the objects in a way th
On 8 February 2015 at 22:32, Jo wrote:
> is it one asphalt way with one track? Then I agree. Or is it one asphalt way
> with two tracks, one for each direction of the tram lines? Then I'd draw 3
> ways, 2 for the tracks, and 1 for the highway.
Fair enough, but that doesn't quite correspond to the
On 8 February 2015 at 19:57, Jo wrote:
> I don't like to reuse the same ways for both railway and highway. The shape
> of the railways follow smooth curves for obvious reasons, whereas cars can
> make 90 degree turns.
I don't understand why that is a problem. If the road is such that the
vehicles
On 21 January 2015 at 07:59, Friedrich Volkmann wrote:
> On 19.01.2015 12:37, Markus Lindholm wrote:
>> Treating addresses as attributes might be fast and convenient but that
>> kind of scheme
>> becomes incoherent as there is no one-to-one relationship between
>> a
On 19 January 2015 at 10:39, Friedrich Volkmann wrote:
> On 18.01.2015 22:23, Markus Lindholm wrote:
>> I think addresses are proper features, so a distinct address
>> should be found only once in the database.
>
> And I see it the other way. Addresses are just attributes. It
On 18 January 2015 at 22:11, Dan S wrote:
> 2015-01-18 20:52 GMT+00:00 Markus Lindholm :
>> On 17 January 2015 at 22:16, Friedrich Volkmann wrote:
>>> With the addrN schema, we need one object (a node tagged shop=* and
>>> addrN:*=*) for a shop.
>>> With the p
On 17 January 2015 at 22:16, Friedrich Volkmann wrote:
> With the addrN schema, we need one object (a node tagged shop=* and
> addrN:*=*) for a shop.
> With the provides_feature relation we need one node for the shop, one node
> for each address, and one relation.
And if there are two shops that
On 16 January 2015 at 01:04, Friedrich Volkmann wrote:
> We can discuss its pros and cons, but I
> think the main message is that multiple addresses are mapped differently all
> over the world. Every country has its local OSM community which concoct
> their own tagging rules. The result is databas
On 15 January 2015 at 12:43, Janko Mihelić wrote:
> 2015-01-15 12:23 GMT+01:00 Andrew Shadura :
>>
>> On 15 January 2015 at 03:02, johnw wrote:
>> > The proposal seems to be a good solution to this problem.
>>
>> This particular proposal seems to be a terrible solution to this
>> problem. It requ
On 5 December 2014 at 17:51, Jack Burke wrote:
> Lately I've been playing with using a multipolygon as a way to handle the
> too-many-address-entries problem. Join the building=roof and
> building=retail into a multipolygon, then apply the address data to that.
> (I do have to do this before appl
On 5 December 2014 at 14:15, Martin Koppenhoefer wrote:
>
> 2014-12-05 12:40 GMT+01:00 Markus Lindholm :
>>
>> In general it is not sustainable to place address tags on
>> area/building elements as there can be many addresses within such an
>> element.
>
>
>
On 5 December 2014 at 10:49, Martin Vonwald wrote:
> No need to provide the address more than once: the address belongs to
> everything within the area tagged with amenity=fuel
In general it is not sustainable to place address tags on
area/building elements as there can be many addresses within s
On 5 December 2014 at 10:57, Martin Koppenhoefer wrote:
>
> 2014-12-05 10:50 GMT+01:00 Markus Lindholm :
>>
>> Also an address should be considered a feature in its own
>> right so it should also be a distinct element.
>
> an address can be seen as a feature on
On 5 December 2014 at 06:19, Hans De Kryger wrote:
> One reason we cant completely
> combine the gas station and convenience store tag is some gas stations have
> the convenience store run by separate companies. As is the case with a
> circle k down the street from me. The convenience store is a c
No, that's a bad idea. I believe there's a clear consensus that
payment:bitcoin=yes is not a proper tag for a shop that doesn't accept
bitcoin at its physical location.
/Markus
On 14 August 2014 12:53, Anita Andersson wrote:
> Since payment:bitcoin=yes is a de facto and used tag and since
> paym
On 12 August 2014 20:55, Anita Andersson wrote:
> In Sweden we got an electronics chain called Webhallen who accept Bitcoin as
> payment through their website and allows the customer to pick up the goods
> they purchase at any of the business's store locations. It does to my
> knowledge not accept
On 10 June 2014 12:51, Janko Mihelić wrote:
> Maybe we could use a broader term that includes ATMs, like financial_kiosk
> or money_kiosk. I'm not saying we should deprecate amenity=atm, I'm saying
> amenity=financial_kiosk could be an umbrella term.
>
To me those terms are too similar for it to
On 13 January 2014 07:16, Nirab Pudasaini wrote:
> Pashupatinath is a major place of worship for Hindus. It is also a place of
> worship for Buddhists. The tag amenity:place_of_worship has a key religion:*
> but how can we add place of worship which are for multiple religions, as in
> case of Pash
On 19 July 2013 18:42, Eugene Alvin Villar wrote:
> <>
>
> On Fri, Jul 19, 2013 at 5:13 PM, Pieren wrote:
>
>> Not for me. I think the address is a "feature" by ifself, not an
>> attribute of other features (like 'name').
>>
>
> I want to know what do people think about addresses.
>
> 1. Are add
On 8 April 2013 17:51, Dave Sutter wrote:
> I like the idea of increasing the level of detail of the streets, and
> I agree that this would best be done by separating the routing network
> from the visual presentation. I think this can, however, be done in
> the existing data model, which is very
On 7 April 2013 20:37, Martin Atkins wrote:
> How have others resolved this fundamental conflict? More detailed streets,
> or less-detailed everything else?
>
I'd say more detailed mapping. Looking at the picture I think it's obvious
that Duboce Avenue should be mapped as two separate highways,
On 15 December 2012 11:19, Erik Johansson wrote:
> On Sat, Dec 15, 2012 at 10:48 AM, Markus Lindholm
>> You mean that the role description could be left empty because it
>> could always be deduced from tags on the member? I guess it could be
>> possible, but I think it is muc
On 14 December 2012 18:41, Erik Johansson wrote:
> On Sun, Dec 9, 2012 at 2:17 PM, Markus Lindholm
> wrote:
>> Created a page on the wiki for this proposal
>> https://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature
>
> What purpose does the role=entrance h
Created a page on the wiki for this proposal
https://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature
/Markus
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
On 7 December 2012 11:05, Henning Scholland wrote:
> Am 06.12.2012 16:39, schrieb Markus Lindholm:
>>
>> Comments?
>
> Hi Markus,
>
> I think it's useful to have such a relation. But I would also include
> building-polygon, like:
>
> building
> entrance
On 7 December 2012 10:27, Pieren wrote:
> On Fri, Dec 7, 2012 at 8:33 AM, Markus Lindholm
> wrote:
>
>> Created first example of provides_feature
>> http://www.openstreetmap.org/browse/relation/2623059
>
> Your relation type name "provides_feature" is
On 6 December 2012 23:10, Martin Koppenhoefer wrote:
> 2012/12/6 Markus Lindholm :
>> Tags:
>> type=provides_feature
>>
>> Members roles:
>> target
>> address
>> entrance
>>
>> Comments?
>
>
> do you know the site relation? It mig
Few days ago there was a discussion on this list with the subject
"Door to door routing to buildings with multiple occupants". My
thoughts after the discussion was that with increasing micro-mapping
we need a relation to tie different objects together. So I thought I
would make a proposal for such
On 5 December 2012 14:23, Martin Koppenhoefer wrote:
> 2012/12/5 Markus Lindholm :
> >> 2012/12/5 Markus Lindholm :
> >> > I just pointed out two practical problems with overloading addresses
> >> > upon POIs. My main argument is that I see addresses as a se
On 5 December 2012 10:19, Martin Koppenhoefer wrote:
> 2012/12/5 Markus Lindholm :
> > I just pointed out two practical problems with overloading addresses upon
> > POIs. My main argument is that I see addresses as a separate map feature
> in
> > their own right.
>
>
On 5 December 2012 05:56, Peter Wendorff wrote:
>
> I don't see why that's more a problem in one node than in different ones -
> except that the current rendering rules don't fit here. In that your
> argumentation sounds much like a tagging-for-the-renderer-argumentation.
>
I just pointed out tw
On 4 December 2012 17:44, Martin Koppenhoefer wrote:
> 2012/12/4 Markus Lindholm :
> >> > it would make it impossible to render addresses and POIs at the same
> >> > time.
> >> this depends entirely on your rendering rules.
> > How would you devise a ren
On 4 December 2012 13:23, Martin Koppenhoefer wrote:
> 2012/12/4 Markus Lindholm :
> > In my book addresses are features in their own right and should not be
> mixed
> > in the same element as amenities or shops. The first problem would be
> that
> > it would m
On 4 December 2012 12:22, Martin Koppenhoefer wrote:
> Am 04/dic/2012 um 11:16 schrieb Pieren :
>
> > On Tue, Dec 4, 2012 at 5:49 AM, Friedrich Volkmann wrote:
> >
> >> The only use of separate address nodes by now is that they make Mapnik
> >> display a house number. But speaking of Mapnik... if
On 15 October 2012 20:08, Colin Smale wrote:
> I don't understand why emergency vehicles are so important in this
> discussion. In the first place they have wide-ranging exemptions from
> traffic rules, which (let's be honest) we are never going to tag in OSM.
> Secondly they are never going to be
On 15 October 2012 10:56, Martin Vonwald wrote:
> Hi!
>
> Some kind of short how-would-you-tag-this-survey. Have a look at part
> five of this motorway:
> http://wiki.openstreetmap.org/wiki/File:Lanes_Example_2.png
>
> Only part 5 is relevant. Assume there is no physical separation just a
> double
On 25 August 2012 01:25, Martin Koppenhoefer wrote:
> 2012/8/20 Markus Lindholm :
>> I've been mostly mapping in large cities, hardly anything in the
>> countryside. So I can only say that I've found it purposeful in the
>> city to map with two highways when legal
On 20 August 2012 16:50, Janko Mihelić wrote:
> 2012/8/20 Markus Lindholm
>>
>>
>> Yes, I understand why one would reassemble highway segments on a route
>> that only differ on the maxspeed tag or other such minor issue. But
>> why would one want to reassemb
On 20 August 2012 14:06, Frederik Ramm wrote:
> Hi,
>
>
> On 08/20/2012 12:57 PM, Markus Lindholm wrote:
>>>
>>> This doesn't correspond to reality: I believe that an emergency
>>> vehicle can cross a solid line, while of course they would
>&g
ur route.
/Markus
>
> Colin
>
>
> On 20/08/2012 13:10, Markus Lindholm wrote:
>>
>> On 20 August 2012 12:57, Markus Lindholm
>> wrote:
>>>
>>> On 20 August 2012 09:39, Elena ``of Valhalla''
>>> wrote:
>>>>
>&
On 20 August 2012 12:57, Markus Lindholm wrote:
> On 20 August 2012 09:39, Elena ``of Valhalla''
> wrote:
>> On 2012-08-19 at 14:09:18 +0200, Markus Lindholm wrote:
>>> In my opinion it's best to treat legal separation (i.e. solid_line)
>>> the sam
On 20 August 2012 09:39, Elena ``of Valhalla'' wrote:
> On 2012-08-19 at 14:09:18 +0200, Markus Lindholm wrote:
>> In my opinion it's best to treat legal separation (i.e. solid_line)
>> the same way as physical separation, i.e. create two separate
>> highw
On 20 August 2012 10:55, Gregory Williams wrote:
>> -Original Message-
>> From: Markus Lindholm [mailto:markus.lindh...@gmail.com]
>> Sent: 19 August 2012 19:26
>> To: Tag discussion, strategy and related tools
>> Subject: Re: [Tagging] Carriageway divider
On 19 August 2012 15:26, Philip Barnes wrote:
> On Sun, 2012-08-19 at 15:04 +0200, Tobias Knerr wrote:
>> On 19.08.2012 14:09, Markus Lindholm wrote:
>> > On 19 August 2012 11:44, Fabrizio Carrai wrote:
>> >>
>> >> Indeed a "Divider=solid
On 19 August 2012 18:23, Tobias Knerr wrote:
> On 19.08.2012 15:09, Markus Lindholm wrote:
>> On 19 August 2012 14:49, Fabrizio Carrai wrote:
>>> This could be a solution but it is against the reality: this kind of road
>>> are indeed a single entity. The "legal
On 19 August 2012 15:04, Tobias Knerr wrote:
> On 19.08.2012 14:09, Markus Lindholm wrote:
>> On 19 August 2012 11:44, Fabrizio Carrai wrote:
>>>
>>> Indeed a "Divider=solid_line" proposal [3] was already presented . I'm would
>>> revamp suc
On 19 August 2012 14:49, Fabrizio Carrai wrote:
> This could be a solution but it is against the reality: this kind of road
> are indeed a single entity. The "legal" division, i.e. the "solid_line" is
> just an attribute.
There's a multitude of cases where a single entity is represented by
multip
On 19 August 2012 11:44, Fabrizio Carrai wrote:
> After a short discussion on the italian talk, I would move the discussion in
> this list. After some tests with OSRM, I missed the availability of a tag
> to mark the continuos (or discontinued) line that divide the lanes in
> several single carri
On 3 July 2012 17:02, Janko Mihelić wrote:
> 2012/7/3 Markus Lindholm
>>
>>
>> I still think it's more straight forward to map as two separate ways
>> than to add tags to provide a logically consistent view about how to
>> drive from A to B in a legal w
On 3 July 2012 16:47, Eckhart Wörner wrote:
> Hi Markus,
>
> Am Dienstag, 3. Juli 2012, 15:38:57 schrieb Markus Lindholm:
>> Physical separation doesn't necessarily mean that it's impossible to
>> cross, it might be no more than a 20cm high curb that an emergency
&
On 3 July 2012 15:20, Martin Koppenhoefer wrote:
> 2012/7/3 Markus Lindholm :
>> In my opinion the most straight forward is to treat legal separation
>> (i.e. solid line) the same way as physical separation, that is to have
>> two ways, one in each direction.
>
>
>
On 3 July 2012 15:03, Martin Koppenhoefer wrote:
> 2012/7/3 Pieren :
>> On Tue, Jul 3, 2012 at 2:00 PM, Janko Mihelić wrote:
>>> Well, the router could take the overtake tag into consideration, and make
>>> you turn around there. They don't do this yet, but probably will.
>>
>> I discover the ove
On 15 April 2012 11:33, Toby Murray wrote:
> On Sun, Apr 15, 2012 at 4:08 AM, Martin Koppenhoefer
> wrote:
>>
>> That's always useful, but it doesn't solve the issue of getting the
>> data for a query like: give me all the hotels cheaper than 66 EUR for
>> a double room with bathroom in this boun
On 15 April 2012 15:15, Jaakko Helleranta.com wrote:
> I prefer tagging the addr:housenumber on building outline, landuse, parcel,
> etc, too. That's clearly the right place for it.
My personal mapping philosophy is to avoid overloading of information
on nodes and ways, so addr:housenumber alway
On 3 March 2012 10:07, Vincent Pottier wrote:
> Le 03/03/2012 08:49, Erik Johansson a écrit :
>
>> There is nothing separating this road yet it is mapped as two ways:
>>
>> http://osm.org/go/0bCzcBhNM--?m
>> http://goo.gl/KLTpu (Streetview)
>
> IMHO, it's a mistake.
>
>>
>> This is done for route
On 1 March 2011 21:47, Richard Mann wrote:
> You'all are welcome to:
>
> 1) Make another proposal
> 2) Vote yes or no to the proposal as it stands
>
> It's not appropriate to fine-tune the proposal during the voting stage
> - you either approve or oppose it as it stands.
>
> If there's an appropri
On 1 March 2011 20:51, Richard Fairhurst wrote:
> Markus Lindholm wrote:
>> If this tag designation is about formal status in the UK
>
> It isn't. It's about formal status, full stop. You could just as easily use
> it to record that a European waterway is UNECE Class V
On 1 March 2011 20:04, Richard Fairhurst wrote:
> Martin Koppenhoefer wrote:
>> There is already 2 alternative ways to tag these (path and
>> foot/cycle/bridleway), I feel we don't need a third one.
>
> Do try and keep up. This is not a third way of tagging. This is _additional_
> information that
On 14/02/2011, M∡rtin Koppenhoefer wrote:
> 2011/2/14 Tom Chance :
>> Hello,
>>
>> Please read and comment on my draft proposal to improve our tagging of
>> vegetarian and vegan food:
>>
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Vegetarian
>>
>> I want to use something more sophistic
On 28 August 2010 10:16, wrote:
>
>
> LeSve wrote, On 2010-08-28 09:46:
>> How should Postoffice be tagged in Sweden.
>>
>> The Postoffices has disapperared and is instead a small part of
>> another shop (or Petrol station etc).
>>
>> Should another node be created which said postoffice or
>> sho
On 18 April 2010 11:15, Ed Avis wrote:
> Did someone contact the person who added this 'patrizer2' stuff?
I did. The response was that she was doing some experimentation and
that I should mind my own business. I didn't pursue it any further as
OSM is as laissez-faire as it is.
Regards
Markus
__
On 6 April 2010 11:21, Tobias Knerr wrote:
> Markus Lindholm wrote:
>> A question, what's the story behind the game:patrizer2:* tags? I just
>> noticed that Stockholm got a bunch of these tags and I'm curious what
>> they are?
>
> "Patrizier 2" is a
Hi
A question, what's the story behind the game:patrizer2:* tags? I just
noticed that Stockholm got a bunch of these tags and I'm curious what
they are?
http://www.openstreetmap.org/browse/node/25929985
Regards
Markus
___
Tagging mailing list
Tagging@
2009/10/15 Peter Childs :
> 2009/10/15 Markus Lindholm :
>> Hi
>>
>> I'm wondering what is best practice regarding tagging addr:housenumber
>> and POIs, e.g. amenity=restaurant.
>> Let's assume that on Mainstreet 10 there's a restaurant named Thai
Hi
I'm wondering what is best practice regarding tagging addr:housenumber
and POIs, e.g. amenity=restaurant.
Let's assume that on Mainstreet 10 there's a restaurant named Thai
Wok. Should there be one node or two?
One single node with the tags addr:street, addr:housenumber,
amenity=restaurant and
76 matches
Mail list logo
