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

[Matthew Woehlke]

On 08/08/2020 19.12, Graeme Fitzpatrick wrote:

On Sun, 9 Aug 2020 at 03:39, Matthew Woehlke wrote:

We already have capacity and capacity=disabled, what's the problem with
adding more capacity:*?


But what number do we show for "capacity"?


IIUC, all of them. So...


I started wondering about this after one of the carparks you mentioned in
Quantico recently showed capacity 15, with 11 car spaces + 4 motorbike
spaces. Should that be =15, or =11 + 4?


...15. Rationale: existing capacity:* spaces are not usable unless you 
meet the criteria, but are (AFAIUI) included in capacity. The 
description in JOSM is explicitly "capacity (overall)". On the wiki, it 
is "the number of vehicles a facility holds". Both imply total capacity, 
including spots that aren't usable to many vehicles. It seems clear that 
the intent is that "general" capacity is the overall capacity less any 
capacity:*.


It's possible that some software will need to adapt (though I question 
how critical it is to know capacity, since no software can know how many 
spaces are already occupied), but it's also possible such software is 
already not honoring other, existing capacity:* tags.



So, do we have a shopping centre parking lot with capacity=100, or should
we have capacity:"vehicle"=60; capacity:motorbike=10; capacity:disabled=10;
capacity:prams***=6; capacity:ev_charging=4;
capacity:(temporary/short_term/click'n'collect)=5; capacity:loading=5


Hmm, "loading" would be good for curbside pick-up, though now we're into 
the discussion of whether a space for standing-only is actually a 
"parking" space :-). As for the main thrust of your question, see above.



***=prams - I'm not sure if they're yet a thing in OSM?, but that's
carparks marked as reserved for parents with prams eg
https://www.google.com.au/maps/@-28.0997524,153.4253639,3a,64.7y,77.23h,72.17t/data=!3m6!1e1!3m4!1s3e6IiMfvLC7DrZq1RA4TUA!2e0!7i16384!8i8192


Yeah, that might make sense. I'm not sure if it's better to go ahead and 
add that, or if we should treat each type as a separate proposal. (I'd 
almost be tempted to yank "compact" again and resubmit it as a follow-up.)


--
Matthew

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

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

[Alessandro Sarretta]

Hi Graeme,

On 09/08/20 01:12, Graeme Fitzpatrick wrote:
On Sun, 9 Aug 2020 at 03:39, Matthew Woehlke > wrote:


We already have capacity and capacity=disabled, what's the problem
with adding more
capacity:*?


But what number do we show for "capacity"?

I started wondering about this after one of the carparks you mentioned 
in Quantico recently showed capacity 15, with 11 car spaces + 4 
motorbike spaces. Should that be =15, or =11 + 4?


So, do we have a shopping centre parking lot with capacity=100, or 
should we have capacity:"vehicle"=60; capacity:motorbike=10; 
capacity:disabled=10; capacity:prams***=6; capacity:ev_charging=4; 
capacity:(temporary/short_term/click'n'collect)=5; capacity:loading=5


the wiki (https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking) 
seems to me quite clear about this, defining "capacity" as "The amount 
of available parking spaces, /including/ all special parking spaces 
(e.g., disabled). Read talk 
 page on 
this."


If one has all the available information, I think that the tag 
capacity=* and tags capacity:*=* can and should stay together.


Ale

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

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

[Graeme Fitzpatrick]

On Sun, 9 Aug 2020 at 03:39, Matthew Woehlke 
wrote:

> We already have capacity and capacity=disabled, what's the problem with
> adding more
> capacity:*?
>

But what number do we show for "capacity"?

I started wondering about this after one of the carparks you mentioned in
Quantico recently showed capacity 15, with 11 car spaces + 4 motorbike
spaces. Should that be =15, or =11 + 4?

So, do we have a shopping centre parking lot with capacity=100, or should
we have capacity:"vehicle"=60; capacity:motorbike=10; capacity:disabled=10;
capacity:prams***=6; capacity:ev_charging=4;
capacity:(temporary/short_term/click'n'collect)=5; capacity:loading=5

***=prams - I'm not sure if they're yet a thing in OSM?, but that's
carparks marked as reserved for parents with prams eg
https://www.google.com.au/maps/@-28.0997524,153.4253639,3a,64.7y,77.23h,72.17t/data=!3m6!1e1!3m4!1s3e6IiMfvLC7DrZq1RA4TUA!2e0!7i16384!8i8192

Thanks

Graeme
___
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 8. Aug 2020, at 19:37, Matthew Woehlke  wrote:
> 
> Well, perhaps it is clear to you and I, but I found a number of 
> amenity=parking_space with capacity > 1 and no associated amenity=parking. 
> *Someone* is using it wrong :-).


yes, what I intended was that amenity=parking_space implies capacity=1, and any 
other capacity are not defined. The current scheme says you can add capacities 
for amenity=parking (but it will not tell you where these specific parking 
types are located within the parking), and you can add single parking spaces, 
one by one.


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 18.08, Martin Koppenhoefer wrote:

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.


it was really just a slip


Okay, but then I don't understand the (original) objection? We already 
have capacity and capacity=disabled, what's the problem with adding more 
capacity:*? (Note that these apply to amenity=parking, *not* to 
amenity=parking_space. There is capacity, and *just* capacity — no 
capacity:*, and none is being proposed — on amenity=parking_space, 
although personally I question whether there should be...)


Is it just unclear that the proposed capacity:* apply to amenity=parking?


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.


Well, perhaps it is clear to you and I, but I found a number of 
amenity=parking_space with capacity > 1 and no associated 
amenity=parking. *Someone* is using it wrong :-).


There are also a bunch of parking_space=* on *buildings*, which 
similarly seems like poor tagging. (I guess the intent is to say "the 
parking *associated with* this facility is X, but I really don't care 
for that vs. actually mapping the parking.)


--
Matthew

___
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] 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] 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] 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] 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] 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] 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] 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] 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] Feature Proposal - RFC - more parking types

[Martin Koppenhoefer]

sent from a phone

> 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


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

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

[Tagging] Feature Proposal - RFC - more parking types

[Matthew Woehlke]

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
- To allow mapping motorcycle parking as part of a unified parking lot, 
by introducing parking_space=motorcycle and capacity:motorcycle

- To add the additional parking space types 'compact' and 'takeaway'

See https://www.openstreetmap.org/way/830096097 for an example of 
parking_space=motorcycle being used in anger. See also 
https://www.openstreetmap.org/?mlat=38.51676&mlon=-77.29554 (open in an 
editor and check the Mapbox imagery) for another, even better example of 
where splitting what most people would almost surely call a single lot 
into separate amenity=parking and amenity=motorcycle_parking would be 
silly. The same lot also has an example of a space that is obviously 
compact-cars-only (by virtue of being not quite 15' long, vs. a more 
typical 18'+).


See https://goo.gl/maps/ePTDv7U4LnieFoor7 for an example of takeaway 
parking.


Question: should we also overload parking_space=takeaway for "parking" 
spaces reserved for curbside pickup? Should we also add a different type 
for those? Or should we simply not map those, or map them in some manner 
totally different from how parking spaces are mapped?


--
Matthew

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