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

[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 are a number of stop
> positions, each of which are actually signed on the platform for the
> benefit of the drivers.  From memory I think that there's at least a
> 2-car stop, a 4 car stop and 6/8 and 10/12 car stops.  The problem is
> that the current node doesn't correspond to any of them.
>
> As I asked on the changeset that added the one above
> https://www.openstreetmap.org/changeset/40603523 , how should these be
> mapped and how should the PTv2 relations be set up for the different
> services that use them, given that different train services will use
> different stop locations here depending on train length?  Should each
> stop position be mapped and should there therefore be different copies
> of each relation for all the possible train lengths?  Should a "pretend"
> average stop position be added which is actually never correct but will
> at least look nice to data consumers that use PTv2 data?  Given that we
> don't know the actual stop position perhaps the railway=station object
> (in this case https://www.openstreetmap.org/node/7154300845 ) should be
> used instead?

Neither of these seem like great options. Personally: if the stopping
positions for trains of different lengths have actually been surveyed,
I don't have a problem with adding several stop_position nodes with a
note=* or description=* or even an invented
stop_position:train:cars=10;12. Don't put any other tags on them and
they won't render, and it's hardly the most cluttersome of our various
micromappings.

There is however a problem if the Midland Main Line trains come in
different lengths. I suppose you could create a separate route
relation for each set service (from, to, calling at, and train length)
and add the stop_positions to the appropriate relation, but that's
pretty extreme relationing.

(As a bit of background, I believe this is a German influence in the
original PTv2 proposal: a given train ref (e.g. "ICE 13") refers to a
single train that will have the same amount of carriages
(extraordinary circumstances excepted). That's more specific than a
"Midland Main Line: Sheffield => London St Pancras" relation.)

> Maybe the public_transport=stop position should be omitted entirely?
> This last option seems extreme, but one reading of
> https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position
> where it says "However, marking the stop position adds no information
> whatsoever when it is placed on the road at the point closest to
> highway=bus_stop or on the tram tracks closest to railway=tram_stop. In
> that case it can be abandoned. " might actually support that (and that
> seems to be the view of one side of the argument in the USA).

Note that this sentence was added in various edits in 2020, well after
the initial proposal was approved. "adds no information" might well be
true (given enough computing power), but "it can be abandoned" is
someone's opinion.

I'm personally fine with not having stop_position unless the actual
stopping position is ambiguous due to some very unusual geometry, but
to be clear, this is against the initially approved proposal.

> Maybe the "correct" answer is none of the above?  With a "local mapper"
> hat on I've managed to avoid PTv2 since it basically isn't relevant
> anywhere I normally map things, largely because I don't tend to do that
> near any actual public transport infrastructure, but with a DWG hat on I
> haven't been able to avoid the question, hence me asking here.

I hope the DWG hat is fireproof :) ptv2 is a topic that arouses passions.


--Jarek

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[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 come back later, unlock it & ride away ie I retrieve
my own "vehicle" at a later stage.

If you've used a hire "scooter" to get from A to B, do you "park" it at B,
or do you return it to a hire location / drop off spot? I think it's more
correct to say that you simply leave it in a spot where anybody else can
use it & when you come back later on, you hope there's one still there for
you to use!

Should we possibly be looking at something similar to
amentiy=bicycle_rental, ie amenity=scooter_rental?
https://wiki.openstreetmap.org/wiki/Tag:amenity=bicycle%20rental

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 
> for containing more type of takeaway beverages shops, and it's still unsure 
> whether use amenity=* or shop=*.
>
> Please comment and help me to complete the proposal, thanks.

I'm guessing the intended page is
https://wiki.openstreetmap.org/wiki/Proposed_features/Takeaway_drink_shops
?

I find the naming of the page kind of confusing if it suggests to add
the tag shop=bubble_tea. Under "takeway drink shops" I'd expect to
also see smoothie places, cold-pressed juice stands, and the like. I
realize Proposed_features/shop=bubble_tea is taken by the previous
proposal, so how about shop=bubble_tea_(2) or something for the new
proposal's wiki page?

--Jarek

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 
"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 are a number of stop 
positions, each of which are actually signed on the platform for the 
benefit of the drivers.  From memory I think that there's at least a 
2-car stop, a 4 car stop and 6/8 and 10/12 car stops.  The problem is 
that the current node doesn't correspond to any of them.


As I asked on the changeset that added the one above 
https://www.openstreetmap.org/changeset/40603523 , how should these be 
mapped and how should the PTv2 relations be set up for the different 
services that use them, given that different train services will use 
different stop locations here depending on train length?  Should each 
stop position be mapped and should there therefore be different copies 
of each relation for all the possible train lengths?  Should a "pretend" 
average stop position be added which is actually never correct but will 
at least look nice to data consumers that use PTv2 data?  Given that we 
don't know the actual stop position perhaps the railway=station object 
(in this case https://www.openstreetmap.org/node/7154300845 ) should be 
used instead?


Maybe the public_transport=stop position should be omitted entirely?  
This last option seems extreme, but one reading of 
https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position 
where it says "However, marking the stop position adds no information 
whatsoever when it is placed on the road at the point closest to 
highway=bus_stop or on the tram tracks closest to railway=tram_stop. In 
that case it can be abandoned. " might actually support that (and that 
seems to be the view of one side of the argument in the USA).


Maybe the "correct" answer is none of the above?  With a "local mapper" 
hat on I've managed to avoid PTv2 since it basically isn't relevant 
anywhere I normally map things, largely because I don't tend to do that 
near any actual public transport infrastructure, but with a DWG hat on I 
haven't been able to avoid the question, hence me asking here.


Best Regards,
Andy


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Apparent conflicting/redundant access tags

[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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 prefer this, especially if the shop is 
welcoming customers to sit down and consume on the premises.

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 
> isn't localized to one area.
> 
> Such tagging is, however (at least according to both the voted-upon usage and 
> AFAIK most if not all existing editors and renderers), wrong.


it was really just a slip, see for example here, I added in 2012 that this 
should not be alternative but additional tagging:

https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aamenity%3Dparking_space&type=revision&diff=759511&oldid=713785

It was always clear that parking_space was for a single parking space and the 
back then already well established “parking” was for a bigger site with 
multiple spaces.


Cheers Martin 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 purpose here would be just to bless 
> the tag with "status=approved" rather than "status=de-facto".


unless the vote fails of course, which would bring us from a fairly defined 
situation that we have now, to limbo.


> 
>>> - To allow mapping motorcycle parking as part of a unified parking
>>> lot, by introducing parking_space=motorcycle and
>>> capacity:motorcycle
>> amenity=parking  is defined for single parking spaces, adding capacity to 
>> what seems to be a subtag, would create confusion
> 
> Huh? There is clearly some miscommunication happening here.


sorry, I meant amenity=parking_space of course.

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[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 mapped. If there 
are mixed parking areas for different vehicle types, your approach is fine, but 
if there are mostly dedicated areas for just a specific vehicle type, it would 
seem unnecessarily complicated to have to use many tags just to say something 
is a bicycle parking, also because if you’re in an automobile you wouldn’t want 
to find them and when you’re with a bike you would not want to find the other, 
having them all mixed up in one or two tags, just to later having to filter 
through all those different kind of vehicle parkings, with probably also lots 
of additional tags missing, just to finally reduce it to the few specific 
parkings that you are interested in, makes life more complicated for everybody 
and will also lead to errors based on incomplete information, which could have 
been completely avoided by using a dedicated tag for a specific kind of thing.


Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[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 allowed to park, in general.

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[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 
> different vehicle types.


I don’t see why the tags should be flexible as the parkings aren’t. You cannot 
park a bicycle at a motorcycle parking nor the contrary. If we used the same 
top level tag for both we would only risk to create false expectations. 
Flexibility is fine if the details are just additional information, not if it’s 
the main information. E.g. it is logical that we did not create different top 
level tags for guarded parkings vs. unguarded parkings, or free parkings vs. 
paid parkings, because you can park your automobile in both. The situation is 
different for bicycle parking vs. automobile parking.

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 mean parking spaces for compact cars, but the first Google
result for me is some parking system for trucks at motorways. Better to
avoid the ambiguity.


Done; thanks! (BTW, "compact cars" probably gives better results. I used 
https://www.google.com/search?q=parking+for+compact+cars&tbm=isch as an 
"example" on the proposal page.)


To Jan's point, that sounds like a documentation issue, or possibly a 
need for parking_space=oversized. I think "normal" should mean "normal 
*for that region*", and similarly, "compact" should means *for that 
region*. Of course, the real rule of thumb is whether the space is 
marked "compact only" (and/or is clearly smaller than its neighbors).


Is it worth essentially writing the wiki page for parking_space=compact 
so that it's clear *exactly* what we're voting on, or can we vote on the 
general idea and hash out the precise wording after?



Also, I guess we need to decide if we need to be able to map something
that fits more than one class, like a takeaway parking spot reserved for
users with disabilities.


Although I have yet to see such a thing, that doesn't make your point 
invalid.



If so, we could consider a solution something like
parking_space:takeaway=yes, or a clearly defined meaning for 
semicolon-separated values.
I would normally assume that semicolon-separated values are union ("or") 
rather than intersection ("and"). Maybe your example should be 
parking_space=takeway+disabled (note the '+' rather than ';')? Given I 
don't know of extant examples, however, I'm just as happy to punt on it 
for now.


--
Matthew

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Alan Grant]

 to deal with access tagging is
> > already broken in advance.
>
> +1 from my side.
>
> 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.
>
> Any new tagging scheme must be able to support parking lots that are
> dedicated to several types of vehicles - at least those of similar size.
> We must be able to tag a shared motorcycle/moped/electric scooter
> parking area.
>
> If we really need a new top-level tag, it has to be something like
> *amenity=small_vehicle_parking* and comprise all of motorcycles, moped,
> mofa, speed_pedelec, scooters (of any kind) and so on. Further details
> could then be given by access tags to specify which kind of vehicles can
> be parked there.
>
>
>
>
>
> --
>
> Message: 4
> Date: Fri, 7 Aug 2020 20:17:12 +0200
> From: Jan Michel 
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Feature Proposal - RFC - more parking types
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> 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 mean parking spaces for compact cars,
>
> You also have to keep in mind that what a 'compact car' is strongly
> depends on the region. What counts as 'compact' in the US is a 'regular
> sized' car in Europe and is a 'large' car in densly populated areas like
> Tokyo.
>
>
>
>
> --
>
> Message: 5
> Date: Fri, 07 Aug 2020 19:39:37 +0100
> From: Philip Barnes 
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Feature Proposal - RFC - more parking types
> Message-ID:
> <561c594960bd61730e14575e258ac2b094a86823.ca...@trigpoint.me.uk>
> Content-Type: text/plain; charset="utf-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 against it because we don't AFAIK have these in
> > the UK?
>
> 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?
>
> We also have loading bays where you can stop for a few minutes to
> collect things you have bought and cannot carry to the car park, there
> is no specific time limit here but you are expected to not be far away.
> Again is that what this means.
>
> Phil (trigpoint)
>
>
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstreetmap.org/pipermail/tagging/attachments/20200807/ff4082d4/attachment-0001.htm
> >
>
> --
>
> Message: 6
> Date: Fri, 7 Aug 2020 18:59:04 + (UTC)
> From: 德泉 談 
> To: "tagging@openstreetmap.org" 
> Subject: [Tagging] Feature Proposal - RFC - Takeaway drinks shops
> Message-ID: <2094538961.1013874.1596826744...@mail.yahoo.com>
> Content-Type: text/plain; charset=UTF-8
>
> 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 it's still
> unsure whether use amenity=* or shop=*.
>
> Please comment and help me to complete the proposal, thanks.
>
> Tan
>
>
>
> --
>
> Message: 7
> Date: Fri, 7 Aug 2020 15:47:37 -0400
> From: Matthew Woehlke 
> To: "Tag discussion, strategy and related tools"
> ,  Jan Michel 
> Subject: Re: [Tagging] Electric scooter parking
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> 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 parking areas for
> specific vehicle types.
>
> BTW, how are hitching rails (i.e. "hors

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

[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 
discussed. (Um... not sure where, possibly in one of the threads linked 
in the proposal.) OTOH *I* wouldn't be adverse to overloading it with 
that meaning, but technically speaking such spaces are not *parking* 
spaces, because you are not supposed to park in them. (Note the 
difference between "parking", "standing" and "stopping". You are 
supposed to *stop* in them, but not *park*.)



We also have loading bays where you can stop for a few minutes to
collect things you have bought and cannot carry to the car park, there
is no specific time limit here but you are expected to not be far away.
Again is that what this means.


That is explicitly "standing". Previous comments apply.

Again, the *intended* use is for *parking* spaces (park, go inside, 
collect a to-go order, possibly *order* a to-go order and wait for it to 
be made... but don't sit down and eat at the restaurant). However *I* 
would not object to using it for any sort of parking/standing/stopping 
space where you are expected to not be long (and the space is 
specifically signed with something like "loading only") but there is not 
a specific time limit. Others might object, however. (Probably on the 
basis that this is not "parking", on which point they *are* technically 
correct.)


--
Matthew

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[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 parking areas for 
specific vehicle types.


BTW, how are hitching rails (i.e. "horse parking") mapped? ;-)

--
Matthew

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Takeaway drinks shops

[德泉 談 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 it's still unsure whether 
use amenity=* or shop=*.

Please comment and help me to complete the proposal, thanks.

Tan

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 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?

We also have loading bays where you can stop for a few minutes to
collect things you have bought and cannot carry to the car park, there
is no specific time limit here but you are expected to not be far away.
Again is that what this means.

Phil (trigpoint)



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 mean parking spaces for compact cars,


You also have to keep in mind that what a 'compact car' is strongly 
depends on the region. What counts as 'compact' in the US is a 'regular 
sized' car in Europe and is a 'large' car in densly populated areas like 
Tokyo.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[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
mailto: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 part of that.
Mostly because it will break all current users of amenity=parking
and at least for me place to place
electric scooter is not the same object as a car parking (in the
same way as bicycle parking
is not the same object as a car parking).
I feel like a data consumer unable to deal with access tagging is 
already broken in advance.


+1 from my side.

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.


Any new tagging scheme must be able to support parking lots that are 
dedicated to several types of vehicles - at least those of similar size.
We must be able to tag a shared motorcycle/moped/electric scooter 
parking area.


If we really need a new top-level tag, it has to be something like
*amenity=small_vehicle_parking* and comprise all of motorcycles, moped, 
mofa, speed_pedelec, scooters (of any kind) and so on. Further details 
could then be given by access tags to specify which kind of vehicles can 
be parked there.




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 documentation here! Also,
> it's less obvious how one would apply access restrictions for e.g.
> charging, compact.

I've always felt that using "disabled" as an access _key_ (i.e.
disabled=* or access:disabled=*) was somewhat at odds with the usual
logic of putting groups of users in the _value_ of access tags.

I like that parking_space=disabled sidesteps this issue.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 the first Google
result for me is some parking system for trucks at motorways. Better to
avoid the ambiguity.

Also, I guess we need to decide if we need to be able to map something
that fits more than one class, like a takeaway parking spot reserved for
users with disabilities. If so, we could consider a solution something
like parking_space:takeaway=yes, or a clearly defined meaning for
semicolon-separated values.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[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 + 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 part of that.
>
> Mostly because it will break all current users of amenity=parking and at
> least for me place to place
> electric scooter is not the same object as a car parking (in the same way
> as bicycle parking
> is not the same object as a car parking).
>

I feel like a data consumer unable to deal with access tagging is already
broken in advance.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[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 major comments here:
>
> - a top level tag like amenity=small_electric_vehicle_parking does not allow 
> for any kind of parking that allows different kinds of vehicles in the same 
> place. E.g. if also mopeds are allowed somewhere, it's impossible to tag the 
> area.
> 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 
> different vehicle types. Note that we also lack a proper way to tag parking 
> lots for trucks.
>
What would be alternative? I see that is some (hopefully rare) cases it would 
be problematic
and I see no better alternative.

> - Please don't use the word 'scooter'. It's completely ambiguous because 
> several languages use the same word for kick-scooters (electric or not) and 
> mofa/moped like vehicles.
>
Is there any viable alternative? electric_motorized_scooter? 
electric_kick_scooter?

Because nothing in 
https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicyclesAndScooters#Tag_Summary
is better than electric_scooter

electric_kick_scooter seems best and I will probably use it if no better 
alternative will appear

> There was some discussion here on the mailing list about the proposal for 
> tags for small electric vehicles a while ago and we did not manage to get to 
> a conclusion about proper names of the vehicles yet.
> https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicyclesAndScooters
> We should try to get these names sorted first and then use the same names for 
> parking spaces.
>
Well, I will select one of worst names soon and start using it, because bicycle 
sharing in my city
collapsed and all bicycle rental locations got reused as  parking places.

So comments are welcome (and it is always possible to retag), but *something* 
will be
used soon.


> On 07.08.20 10: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 should be tagged?
>>
>> amenity=small_electric_vehicle_parking ?
>>
>> amenity=electric_scooter_parking ?
>>
>> amenity=parking + vehicle=no + small_electric_vehicle=yes
>> or
>> amenity=parking + vehic le=no + electric_scooter=yes
>> seems like a terrible idea to me
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[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.  amenity=parking is for motor vehicle 
> parking, electric scooters are a part of that. 
>
Mostly because it will break all current users of amenity=parking and at least 
for me place to place
electric scooter is not the same object as a car parking (in the same way as 
bicycle parking
is not the same object as a car parking).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 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 by a formal vote.  If you mark it status=approved
> then
> it ought to be possible to find the vote that approved it.  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.  Please don't
> misuse "approved" to mean that.
>
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[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 part of that.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Electric scooter parking

[Jan Michel]

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 major comments here:

- a top level tag like amenity=small_electric_vehicle_parking does not 
allow for any kind of parking that allows different kinds of vehicles in 
the same place. E.g. if also mopeds are allowed somewhere, it's 
impossible to tag the area.
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 different vehicle types. Note that we also lack 
a proper way to tag parking lots for trucks.


- Please don't use the word 'scooter'. It's completely ambiguous because 
several languages use the same word for kick-scooters (electric or not) 
and mofa/moped like vehicles.
There was some discussion here on the mailing list about the proposal 
for tags for small electric vehicles a while ago and we did not manage 
to get to a conclusion about proper names of the vehicles yet.

https://wiki.openstreetmap.org/wiki/Proposed_features/ElectricBicyclesAndScooters
We should try to get these names sorted first and then use the same 
names for parking spaces.




Jan



On 07.08.20 10: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 should be tagged?

amenity=small_electric_vehicle_parking ?

amenity=electric_scooter_parking ?

amenity=parking + vehicle=no + small_electric_vehicle=yes
or
amenity=parking + vehic le=no + electric_scooter=yes
seems like a terrible idea to me

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging





___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 (which would usually be called "carry-out" in 
the US) is a *purpose* restriction, and there is not *technically* a 
time restriction attached. (I'm pretty sure that if your order took an 
unusually long time for some reason, you would not get towed, as you 
might in a "15 minute" space.)


My main argument (well, aside from "they're a thing") is that if I can't 
map them, how am I supposed to map a lot that has such spaces? They 
aren't normal spaces and definitely shouldn't be mapped that way, but 
then, am I supposed to subtract them from 'capacity'? How do I map them 
so that armchair mappers don't see my "error" and "correct" it?



Perhaps I'm against it because we don't AFAIK have these in the UK?


I can't speak to that :-). They are assuredly real in the US; several 
restaurants in my area have parking/standing spaces that are either 
carry-out only or pickup only. (Almost all Red Robin's AFAIK have some, 
I suspect many/all Chili's have some, and pretty sure I've seen them 
associated with other restaurants as well.)


--
Matthew

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 it though? The places often don't have an
explicit time limit posted. maxstay=takeway?

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Jez Nicholson]

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?

On Fri, 7 Aug 2020, 15:02 Paul Allen,  wrote:

> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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

[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 should be tagged?

amenity=small_electric_vehicle_parking ?

amenity=electric_scooter_parking ?


IMHO, something along those lines. Your examples appear to be very much 
in line with amenity=motorcycle_parking or amenity=bicycle_parking.



amenity=parking + vehicle=no + small_electric_vehicle=yes
or
amenity=parking + vehicle=no + electric_scooter=yes
seems like a terrible idea to me


To the extent these are not part of a parking lot that includes parking 
for other vehicles, I would agree.


--
Matthew

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Apparent conflicting/redundant access tags

[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.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 this backwards*, and possibly (I didn't dig 
into authorship to be able to say for certain) aren't the only one.


To quote the *approved* documentation:

"Use amenity=parking_space to map a single parking space on a parking 
lot. Mapping parking spaces is an addition, not a replacement, to 
mapping a whole parking lot with amenity=parking."


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 isn't localized to one area.


Such tagging is, however (at least according to both the voted-upon 
usage and AFAIK most if not all existing editors and renderers), wrong.


If I reread your message with that context, however, then your objection 
makes sense *in that context*. If, however, you alter your understanding 
to reflect the *prescribed* usage of amenity=parking and 
amenity=parking_space, I think you will find your objection disappears.


Hope that helps!

--
Matthew

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[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 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 most fundamental mapping task of the planet, namely
the distinction between ocean and land, i am trying my best here to
work towards a consensus - no matter how slim the chances are from my
perspective.

I agree




 1) We should establish an agreed "OSM Coastline position", which I
 suggest would approximate to the position of the coastline on 1
 January 2020.

 2) Any edit which moved the position of the coastline by more than
 20Km from the established position should be classed as vandalism,
 unless such movement had previously been agreed by the community.


That is a practically feasible approach but it would form a major
beachhead in abolishing the principle of verifiablility in
OpenStreetMap in favor of adopting the major consensus narrative of the
OSM community as the reality to map rather than the intersubjectively
verifiable reality.

To put it bluntly:  In your scenario if the OSM community agreed on
ignoring the physical reality mapping of the coastline could depart
arbitrarily far from said physical reality.
But we are only having this discussion because there are places where 
the coastline boundary has no "physical reality".


We de facto already have the situation that if edits are contested the
status quo is the fallback.  And more strongly formalizing that in case
of the coastline could be a good idea.  But to forgo having a
verifiable definition of the coastline tag supported by consensus is
not a good idea IMO.
I am quite happy for my proposal to be an interim solution until there 
is a "verifiable definition of the coastline tag supported by consensus"


I would however modify my last point (2) to be

(2) In the case of disagreement, any edit which moved the position of the 
coastline by more than 20Km from the established position should prima facie be 
classed as vandalism, unless such movement had previously been agreed by the 
OSM community.

This modification primarily allows for the continuing improvement of the PGS 
import without needlessly seeking prior approval in each instance

David



Christoph Hormann
http://www.imagico.de/
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 "status=de-facto".


But it wasn't approved by a formal vote.  If you mark it status=approved
then it ought to be possible to find the vote that approved it.


Ahem:

"The purpose [of including parking_space=disabled as an element of the 
proposal] would be [so that, if the proposal passes, we can] bless the 
tag with 'status=approved' rather than 'status=de-facto'."


Was some part of that unclear?

The proposal under discussion in this thread *would be* the 
aforementioned approval vote.


--
Matthew

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 


I've always had some doubts in using parking_space=disabled.

When I had to map parking spaces specifically designed for disabled 
people (i.e. only disabled people can park there), I've used 
disabled=designated, because it defines (or that is my interpretation) 
an access condition and it applies it to disabled people.


While parking_space=disabled seems to be more generic.

But if the default use of parking_space=disables means exactly that only 
disabled people can park there, I'm ok to use it (and change my edits), 
but in this case an explicit description in this sense is required in 
the wiki page.


See? This is *why* we need a page! Thank you for bringing up this 
excellent point!


For me, I always look at parking_space=X and capacity:X as being 
related. I didn't also propose e.g. parking_space=parent because I can't 
recall ever encountering such a thing, but arguably that should be added 
also.


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 documentation here! Also, 
it's less obvious how one would apply access restrictions for e.g. 
charging, compact.


(If I'm using overpass correctly, it looks like there are ~1k instances 
of amenity=parking_space *also* tagged with access:disabled. That's 
clearly much less popular than parking_space=disabled. Do you know if 
any renderers use access:disabled to affect the rendering of 
amenity=parking_space?)


--
Matthew

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 by a formal vote.  If you mark it status=approved
then
it ought to be possible to find the vote that approved it.  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.  Please don't
misuse "approved" to mean that.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 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".



- To allow mapping motorcycle parking as part of a unified parking
lot, by introducing parking_space=motorcycle and
capacity:motorcycle


amenity=parking  is defined for single parking spaces, adding capacity to what 
seems to be a subtag, would create confusion


Huh? There is clearly some miscommunication happening here.

The capacity and capacity:* tags apply to amenity=parking, which is used 
to map entire *lots*. Capacity is clearly meaningful in this context.


Individual parking *spaces* are not supposed to be tagged 
amenity=parking, they are supposed to be tagged amenity=parking_space.


I fail to see the confusion. Maybe you were misreading the proposal? (I 
am not at this time proposing capacity or capacity:* tags for 
amenity=parking_space. That tag *can* have a capacity¹, but it's 
arguable whether it *should*, or whether it's preferable to not map 
multi-capacity spaces.)


(¹ ...and iD thinks it should have capacity=1, while JOSM disagrees. 
I've been tagging them thusly, but that's arguably an iD bug that should 
be fixed, in which case I'd happily go back and nuke all my capacity=1.)


--
Matthew

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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 parking_space=disabled.

When I had to map parking spaces specifically designed for disabled 
people (i.e. only disabled people can park there), I've used 
disabled=designated, because it defines (or that is my interpretation) 
an access condition and it applies it to disabled people.


While parking_space=disabled seems to be more generic.

But if the default use of parking_space=disables means exactly that only 
disabled people can park there, I'm ok to use it (and change my edits), 
but in this case an explicit description in this sense is required in 
the wiki page.


Best,

Ale


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Apparent conflicting/redundant access tags

[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 the public?
>
>
> The issue is that it becomes the default for all other transport mode
> access.
>
> I once had OsmAnd direct me to turn my car right on a very tiny path.
>
> It was tagged as highway=foot,access=yes
>
This sounds like an OsmAnd bug. Paths should not be routable for cars
unless they specifically say car=yes, and maybe not even then.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[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 concept of the 
world ocean as the main reservoir of the global water cycle.

The distinction between a river and the world ocean is real and a 
fundamental aspect of our scientific understanding of the geography of 
this planet.  That digital maps have - based on the precedent set by 
Google - almost universally ignored this fact does not change it.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Apparent conflicting/redundant access tags

[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).

Am 7. August 2020 08:34:33 MESZ schrieb 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 transport mode
>access.
>
>I once had OsmAnd direct me to turn my car right on a very tiny path.
>
>It was tagged as highway=foot,access=yes
>
>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[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 the dependence on
terms subject to interpretation in favour of relatively
non-controversial terms such as "water," "foreshore" and "land." 

> The distinction between a river and the world ocean is real and a 
> fundamental aspect of our scientific understanding of the geography of 
> this planet.

But the big "grey area" where a given point could be considered either
or both (or something else entirely like "estuary", "salt marsh" or
"mangrove") is what we are discussing here. A taxonomy requiring that
each point is in exactly one of {land,river,ocean} is not viable for OSM
because (around the edges) it requires specialist knowledge to
determine, it depends on which "specialist" you take as a reference and
is not verifiable by the average mapper. 

> 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 that we can
find a solution where Google haven't?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Electric scooter parking

[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 ?

amenity=electric_scooter_parking ?

amenity=parking + vehicle=no + small_electric_vehicle=yes
or
amenity=parking + vehicle=no + electric_scooter=yes
seems like a terrible idea to me
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[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 that we can find a 
> solution where Google haven't?
>
This is an absurd argument, we did plenty of things where Google and Google 
Maps failed.

Also, it is entirely possible that ad/car centric Google Maps simply have not 
attempted this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[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 say Google have "ignored" this. What makes you think that we can find a 
> solution where Google haven't?

This is an absurd argument, we did plenty of things where Google and
Google Maps failed. 

This is not an argument at all, it's a question. Empirical evidence
would suggest we have also not yet found a solution, so we are in no
position to gloat about this. 

Currently we are still in the dick-waving stage and not converging on a
consensus that will be usable by most mappers and data consumers. 

Let's start with a hypothesis - a certain tagging model which we expect
will be good enough (to start with). Then check how that fits against
real-world situations, make incremental refinements to the model, and
iterate. Perfection is the enemy of the good! If the result of this
discussion is to be of any value at all, it must fit with most of the
world, both the geographical realities and the human/cultural aspects.
Getting too deep into the details too early is bound to fail.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[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 OpenStreetMap failing in its primary 
>> goal in the single most fundamental mapping task of the planet, namely 
>> the distinction between ocean and land, i am trying my best here to 
>> work towards a consensus - no matter how slim the chances are from my 
>> perspective.

The word "ocean" is already subjective... We need fundamentally to
distinguish between land, foreshore and water. These are objective there
should be not much argument, except for maybe which low/high water line
to use (mean springs or whatever). What the various areas are CALLED is
the subject here, and clearly one man's coastline is another man's
riverbank. But the fundamental pair of lines, creating the three zones
(land, foreshore and water) are required in any case. 

By including a definition in OSM of the transition from river to
estuary, or from estuary to sea, we are actually "tagging for the
renderer" because we are removing the choice from the data consumer and
forcing a particular paradigm on the (OSM)-world. We have proven time
and time again that it is impossible to synthesise a compromise that
suits everyone - it just ends up suiting no-one.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[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

[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 most fundamental mapping task of the planet, namely 
the distinction between ocean and land, i am trying my best here to 
work towards a consensus - no matter how slim the chances are from my 
perspective.

> 1) We should establish an agreed "OSM Coastline position", which I
> suggest would approximate to the position of the coastline on 1
> January 2020.
>
> 2) Any edit which moved the position of the coastline by more than
> 20Km from the established position should be classed as vandalism,
> unless such movement had previously been agreed by the community.

That is a practically feasible approach but it would form a major 
beachhead in abolishing the principle of verifiablility in 
OpenStreetMap in favor of adopting the major consensus narrative of the 
OSM community as the reality to map rather than the intersubjectively 
verifiable reality.

To put it bluntly:  In your scenario if the OSM community agreed on 
ignoring the physical reality mapping of the coastline could depart 
arbitrarily far from said physical reality.

We de facto already have the situation that if edits are contested the 
status quo is the fallback.  And more strongly formalizing that in case 
of the coastline could be a good idea.  But to forgo having a 
verifiable definition of the coastline tag supported by consensus is 
not a good idea IMO.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging