Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

2020-08-07 Thread Jarek Piórkowski
On Fri, 7 Aug 2020 at 20:54, Andy Townsend wrote: > https://www.openstreetmap.org/node/12004813 is a > "public_transport=stop_position" for a local station and is part of > https://www.openstreetmap.org/relation/6396491 among other relations. > The problem is that train lengths vary, and there

Re: [Tagging] Electric scooter parking

2020-08-07 Thread Graeme Fitzpatrick
Just to open a different semantic can of worms concerning the spots these hire "scooters" are left ... :-) Are they "parked"? To me, I "park" my car in a parking space, come back to it after shopping & drive home, or I "park" my bicycle in a rack at the beach, wrap a chain around the wheel, then

Re: [Tagging] Feature Proposal - RFC - Takeaway drinks shops

2020-08-07 Thread Jarek Piórkowski
On Fri, 7 Aug 2020 at 14:59, 德泉 談 via Tagging wrote: > Sorry for pause the bubble tea proposal for a month due to my personal reason. > > In the discussion in June and July some people think the tag for bubble tea > is too specific but there is a flaw in existing tags, so I made a new draft >

[Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

2020-08-07 Thread Andy Townsend
Hello, This is a question that actually arose out of a "how to tag" argument that's come to the attention of the DWG in the USA, but it's actually easy to describe in terms of data in the UK that I'm familiar with, so I'll do that. https://www.openstreetmap.org/node/12004813 is a

Re: [Tagging] Apparent conflicting/redundant access tags

2020-08-07 Thread Martin Koppenhoefer
sent from a phone > On 7. Aug 2020, at 15:51, Paul Johnson wrote: > > I don't see what's not clear about access=* overriding all access not > explicitly set. +1, and that‘s also the reason why it should not be used Cheers Martin ___ Tagging

Re: [Tagging] Feature Proposal - RFC - Takeaway drinks shops

2020-08-07 Thread Martin Koppenhoefer
I still believe shop=bubble_tea is suitable, as these are specific shops where you can get only bubble tea. Although bubble tea is something to drink, I would rather think of it as a specific kind of sweets, than as a shop where you can get a beverage. Amenity could also be suitable, if you

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Martin Koppenhoefer
sent from a phone > On 7. Aug 2020, at 15:47, Matthew Woehlke wrote: > > However, it sounds like you have this backwards; you are using > amenity=parking_space to map lots and amenity=parking to map individual > spaces. There appears to be a modest amount of such backwards mapping, and it

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Martin Koppenhoefer
sent from a phone > On 7. Aug 2020, at 14:51, Matthew Woehlke wrote: > >> that’s almost 22k uses, it is already established and voting yes or no will >> not change it > > Well, yes, voting "no" is probably not useful, but this is also the least > "interesting" bit of the proposal. The

Re: [Tagging] Electric scooter parking

2020-08-07 Thread Martin Koppenhoefer
sent from a phone > On 7. Aug 2020, at 20:14, Jan Michel wrote: > > It might be useful to have two different top-level amenity tags for parking > lots for large and small vehicles, but not one tag for every type of vehicle. I would say it depends on the kind of parkings that are to be

Re: [Tagging] Electric scooter parking

2020-08-07 Thread Martin Koppenhoefer
sent from a phone > On 7. Aug 2020, at 19:12, Paul Johnson wrote: > > I feel like a data consumer unable to deal with access tagging is already > broken in advance. although we already use access like tags for parkings it should be noted that being allowed to access is different to being

Re: [Tagging] Electric scooter parking

2020-08-07 Thread Martin Koppenhoefer
sent from a phone > On 7. Aug 2020, at 17:57, Jan Michel wrote: > > I propose to not introduce new top-level keys because they are not flexible > enough. I'm very well aware that we have parking, bicycle_parking and > motorcycle_parking already, but it just doesn't scale with the amount of

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Matthew Woehlke
On 07/08/2020 13.11, Tobias Knerr wrote: On 06.08.20 22:52, Matthew Woehlke wrote: https://wiki.openstreetmap.org/wiki/Proposed_features/more_parking I like it, thanks for working on this topic! Two suggestions: Could you add a short definition of "compact"? I can guess that it's supposed to

Re: [Tagging] me Di get y st, Vol 13 , Issue 49

2020-08-07 Thread Alan Grant
tf-8" > > On Fri, 2020-08-07 at 15:09 +0100, Jez Nicholson wrote: > > I saw parking_space=takeaway riding on the coattails of the original > > postis this not a waiting time restriction? Does it merit its own > > value? Perhaps I'm agai

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Matthew Woehlke
On 07/08/2020 14.39, Philip Barnes wrote: I am not 100% sure but McDonalds that have a drive through have special spaces where you are told to wait if your order is taking a long time to clear the queue. Is that what this means? "No", because those are not *parking* spaces as was previously

Re: [Tagging] Electric scooter parking

2020-08-07 Thread Matthew Woehlke
On 07/08/2020 11.55, Jan Michel wrote: Note that we also lack a proper way to tag parking lots for trucks. This sounds like a good candidate for expanding capacity:* / parking_space=*, at least in the case of mixed-use lots. In general, I agree it would be good to have a better way to tag

[Tagging] Feature Proposal - RFC - Takeaway drinks shops

2020-08-07 Thread 德泉 談 via Tagging
Hello Sorry for pause the bubble tea proposal for a month due to my personal reason. In the discussion in June and July some people think the tag for bubble tea is too specific but there is a flaw in existing tags, so I made a new draft for containing more type of takeaway beverages shops, and

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Philip Barnes
On Fri, 2020-08-07 at 15:09 +0100, Jez Nicholson wrote: > I saw parking_space=takeaway riding on the coattails of the original > postis this not a waiting time restriction? Does it merit its own > value? Perhaps I'm against it because we don't AFAIK have these in > the UK? I am not 100% sure

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Jan Michel
On 07.08.20 19:11, Tobias Knerr wrote: On 06.08.20 22:52, Matthew Woehlke wrote: https://wiki.openstreetmap.org/wiki/Proposed_features/more_parking I like it, thanks for working on this topic! Two suggestions: Could you add a short definition of "compact"? I can guess that it's supposed to

Re: [Tagging] Electric scooter parking

2020-08-07 Thread Jan Michel
On 07.08.20 19:09, Paul Johnson wrote: On Fri, Aug 7, 2020 at 12:00 PM Mateusz Konieczny via Tagging > wrote: Aug 7, 2020, 18:05 by ba...@ursamundi.org : On Fri, Aug 7, 2020 at 3:27 AM Mateusz Konieczny via Tagging

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Tobias Knerr
On 07.08.20 15:36, Matthew Woehlke wrote: > That said... now I'm on the fence. FWIW, the amenity=parking page > mentions parking_space=disabled as being supported by at least one > renderer, while one has to do quite some digging for how to use > access:*. Clearly we *do* need to improve the

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Tobias Knerr
On 06.08.20 22:52, Matthew Woehlke wrote: > https://wiki.openstreetmap.org/wiki/Proposed_features/more_parking I like it, thanks for working on this topic! Two suggestions: Could you add a short definition of "compact"? I can guess that it's supposed to mean parking spaces for compact cars, but

Re: [Tagging] Electric scooter parking

2020-08-07 Thread Paul Johnson
On Fri, Aug 7, 2020 at 12:00 PM Mateusz Konieczny via Tagging < tagging@openstreetmap.org> wrote: > Aug 7, 2020, 18:05 by ba...@ursamundi.org: > > On Fri, Aug 7, 2020 at 3:27 AM Mateusz Konieczny via Tagging < > tagging@openstreetmap.org> wrote: > > amenity=parking + vehicle=no +

Re: [Tagging] Electric scooter parking

2020-08-07 Thread Mateusz Konieczny via Tagging
TLDR: electric_kick_scooter seems best and I will probably use it if no better alternative will appear Aug 7, 2020, 17:55 by j...@mueschelsoft.de: > Hi, > I agree that we need some way to tag those parking spaces and in general > parking spaces for specific types of vehicles. > I have two

Re: [Tagging] Electric scooter parking

2020-08-07 Thread Mateusz Konieczny via Tagging
Aug 7, 2020, 18:05 by ba...@ursamundi.org: > > > On Fri, Aug 7, 2020 at 3:27 AM Mateusz Konieczny via Tagging <> > tagging@openstreetmap.org> > wrote: > >> amenity=parking + vehicle=no + electric_scooter=yes >> seems like a terrible idea to me >> > > Why?  That's actually pretty good. 

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Mateusz Konieczny via Tagging
Aug 7, 2020, 15:06 by pla16...@gmail.com: > Maybe we need > a different status to indicate "was not voted upon but is widely used and > most people are happy with it" but we don't have that.  > We have that, it is "de facto" status. ___ Tagging mailing

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Joseph Eisenberg
Re: status to indicate "was not voted upon but is widely used and most people are happy with it" That's the "de facto" status. -- Joseph Eisenberg On Fri, Aug 7, 2020 at 6:09 AM Paul Allen wrote: > On Fri, 7 Aug 2020 at 13:53, Matthew Woehlke > wrote: > >> >> Well, yes, voting "no" is

Re: [Tagging] Electric scooter parking

2020-08-07 Thread Paul Johnson
On Fri, Aug 7, 2020 at 3:27 AM Mateusz Konieczny via Tagging < tagging@openstreetmap.org> wrote: > amenity=parking + vehicle=no + electric_scooter=yes > seems like a terrible idea to me > Why? That's actually pretty good. amenity=parking is for motor vehicle parking, electric scooters are a

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Matthew Woehlke
On 07/08/2020 10.09, Jez Nicholson wrote: I saw parking_space=takeaway riding on the coattails of the original postis this not a waiting time restriction? Does it merit its own value? That's not how I would interpret it. Stuff like "15 minute parking" also exists; "takeaway" parking

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Jarek Piórkowski
On Fri, 7 Aug 2020 at 10:09, Jez Nicholson wrote: > I saw parking_space=takeaway riding on the coattails of the original > postis this not a waiting time restriction? Does it merit its own value? > Perhaps I'm against it because we don't AFAIK have these in the UK? How else would you tag

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Paul Allen
On Fri, 7 Aug 2020 at 14:40, Matthew Woehlke wrote: > Ahem: > Brain fart on my part. -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

2020-08-07 Thread Matthew Woehlke
On 07/08/2020 04.27, Mateusz Konieczny via Tagging wrote: Electric scooter parkings started to appear in Poland. https://commons.wikimedia.org/wiki/File:ParkingHulajn%C3%B3g.jpg https://commons.wikimedia.org/wiki/File:Parking_Hulajnogi.jpg (text on traffic sign is "electric scooters") How it

Re: [Tagging] Apparent conflicting/redundant access tags

2020-08-07 Thread Paul Johnson
On Fri, Aug 7, 2020 at 6:56 AM Simon Poole wrote: > This is why access=yes is useless on highway objects as it is not clear if > it overrides implicit access restrictions or not. > I don't see what's not clear about access=* overriding *all* access not explicitly set.

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Matthew Woehlke
On 06/08/2020 19.42, Martin Koppenhoefer wrote: amenity=parking is defined for single parking spaces, adding capacity to what seems to be a subtag, would create confusion Okay... yike. I think I see the problem here (after doing some digging into extant usage). The problem is *you have

Re: [Tagging] Rio de la Plata edit war

2020-08-07 Thread David Groom
-- Original Message -- From: "Christoph Hormann" To: "Tag discussion, strategy and related tools" Sent: 07/08/2020 08:27:23 Subject: Re: [Tagging] Rio de la Plata edit war I concur with a lot of your observations and like you i had essentially given up on the idea of the coastline

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Matthew Woehlke
On 07/08/2020 09.06, Paul Allen wrote: On Fri, 7 Aug 2020 at 13:53, Matthew Woehlke wrote: Well, yes, voting "no" is probably not useful, but this is also the least "interesting" bit of the proposal. The purpose here would be just to bless the tag with "status=approved" rather than

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Matthew Woehlke
On 07/08/2020 08.23, Alessandro Sarretta wrote: Dear Matthew, On 06/08/20 22:52, Matthew Woehlke wrote: Please see https://wiki.openstreetmap.org/wiki/Proposed_features/more_parking. To summarize: I am proposing the following: - To codify / make official the de-facto parking_space=disabled

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Paul Allen
On Fri, 7 Aug 2020 at 13:53, Matthew Woehlke wrote: > > Well, yes, voting "no" is probably not useful, but this is also the > least "interesting" bit of the proposal. The purpose here would be just > to bless the tag with "status=approved" rather than "status=de-facto". > But it wasn't approved

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Matthew Woehlke
On 06/08/2020 19.42, Martin Koppenhoefer wrote: On 6. Aug 2020, at 22:54, Matthew Woehlke wrote: - To codify / make official the de-facto parking_space=disabled that’s almost 22k uses, it is already established and voting yes or no will not change it Well, yes, voting "no" is probably not

Re: [Tagging] Feature Proposal - RFC - more parking types

2020-08-07 Thread Alessandro Sarretta
Dear Matthew, On 06/08/20 22:52, Matthew Woehlke wrote: Please see https://wiki.openstreetmap.org/wiki/Proposed_features/more_parking. To summarize: I am proposing the following: - To codify / make official the de-facto parking_space=disabled I've always had some doubts in using

Re: [Tagging] Apparent conflicting/redundant access tags

2020-08-07 Thread Alan Mackie
On Fri, 7 Aug 2020 at 07:36, Niels Elgaard Larsen wrote: > On Thu, 6 Aug 2020 17:12:48 +1000 > Graeme Fitzpatrick wrote: > > >OK, now you've all got me confused! > > > >I always thought that access=yes means that it is open to the general > >public, while access=no means that it's not open to

Re: [Tagging] Rio de la Plata edit war

2020-08-07 Thread Christoph Hormann
On Friday 07 August 2020, Colin Smale wrote: > > The word "ocean" is already subjective... [...] Oh please. Not again another attempt to deflect into a discussion of language semantics when i am clearly not talking about the word ocean but about the abstract physical and language independent

Re: [Tagging] Apparent conflicting/redundant access tags

2020-08-07 Thread Simon Poole
This is why access=yes is useless on highway objects as it is not clear if it overrides implicit access restrictions or not. If it did it would have to be accompanied by a comprehensive list of forbidden access modes (and similar arguments apply to all but the simplest use of access=no too).

Re: [Tagging] Rio de la Plata edit war

2020-08-07 Thread Colin Smale
On 2020-08-07 11:18, Christoph Hormann wrote: > On Friday 07 August 2020, Colin Smale wrote: > >> The word "ocean" is already subjective... [...] > > Oh please. Not again another attempt to deflect into a discussion of > language semantics Completely the other way around. I hope to remove

[Tagging] Electric scooter parking

2020-08-07 Thread Mateusz Konieczny via Tagging
Electric scooter parkings started to appear in Poland. https://commons.wikimedia.org/wiki/File:ParkingHulajn%C3%B3g.jpg https://commons.wikimedia.org/wiki/File:Parking_Hulajnogi.jpg (text on traffic sign is "electric scooters") How it should be tagged? amenity=small_electric_vehicle_parking ?

Re: [Tagging] Rio de la Plata edit war

2020-08-07 Thread Mateusz Konieczny via Tagging
Aug 7, 2020, 11:36 by colin.sm...@xs4all.nl: > > On 2020-08-07 11:18, Christoph Hormann wrote: > > >> That digital maps have - based on the precedent set by >> Google - almost universally ignored this fact does not change it. >>   >> > You say Google have "ignored" this. What makes you think

Re: [Tagging] Rio de la Plata edit war

2020-08-07 Thread Colin Smale
On 2020-08-07 12:04, Mateusz Konieczny via Tagging wrote: > Aug 7, 2020, 11:36 by colin.sm...@xs4all.nl: > > On 2020-08-07 11:18, Christoph Hormann wrote: > > That digital maps have - based on the precedent set by > Google - almost universally ignored this fact does not change it. > > You

Re: [Tagging] Rio de la Plata edit war

2020-08-07 Thread Colin Smale
On 2020-08-07 09:27, Christoph Hormann wrote: >> I concur with a lot of your observations and like you i had essentially >> given up on the idea of the coastline representing meaningful >> information in the long term. But considering this is a very sad >> conclusion which essentially means

Re: [Tagging] Rio de la Plata edit war

2020-08-07 Thread Yves
Would it be worth considering adding other tags with area limits to the water/land polygons computation? Yves ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

2020-08-07 Thread Christoph Hormann
I concur with a lot of your observations and like you i had essentially given up on the idea of the coastline representing meaningful information in the long term. But considering this is a very sad conclusion which essentially means OpenStreetMap failing in its primary goal in the single

Re: [Tagging] Apparent conflicting/redundant access tags

2020-08-07 Thread Niels Elgaard Larsen
On Thu, 6 Aug 2020 17:12:48 +1000 Graeme Fitzpatrick wrote: >OK, now you've all got me confused! > >I always thought that access=yes means that it is open to the general >public, while access=no means that it's not open to the public? The issue is that it becomes the default for all other