To repeat for others, I explained in Talk:Proposed features/street parking revision - OpenStreetMap Wiki that I tried and rejected parking:*:no_*= for reasons of double negation, inability to reuse access= val of =private etc, and the val length limit in *:conditional= (in this case it is related to the aforemented, requiring eg parking:*:no_parking=no @ (private) ) to be simple and understandable.
Depends on what is meant by “discussed”. In fact, I had initially suggested parking:*:parking= already, but backed down from worry it is too awkward. If it is agreeable, I’m somewhat glad (still unease for lack of better alternative) to see it used.
I’m not totally sure what options the authors of this one have considered, I will let them explain.
- Mail deposit similar to a “loading zone”. I don’t know how should an eg
*loading_zone=mailbe formulated yet. - I will be honest. I don’t like the never-ending list of new
access=modes. More criticallycar_sharing=is not the same as “ride-sharing” / “ride-hailing”. Ride-hailing waiting zones would be closer toamenity=taxistands. (and we do have more problems awaiting in line with motorcycle and different taxis) - Pregnancy is a user demographics, so probably a condition first for now. Reason is more of an additional context when the restrictions don’t explain themselves. It is further related to enforcement and punishments.
For fun and as a thought experiment, I scribbled Proposed features/parking space= cleanup - OpenStreetMap Wiki as a follow-up (depending on how it ends up) to see if any logic can be sorted out together. It is still unsatisfactory.
Yes. And why wouldn’t we want to tag these as a separate way, especially if it’s a common dropoff/pickup zone?
It seems counterintuitive, but especially airports have huge zones like these.
Well… we already have load-unload as a value for maxstay. Would adding “stop”, “wait” and “pickup-dropoff” really be a problem? Data consumers will have to understand these special cases one way, or the other.
The more I think of it, the more logic it seems to tag maxstay=stop instead of something like *=no_waiting.
I might have a biased attitude, but since we also want to be able to tag parking amenities, the parking=* key clearly cannot be used. Same for access=*. As stated several times, this is about the usage of a parking lane, but usually the usage also defines the allowed duration.
Again, just my thoughts. I really appreciate the conversation and ideas and especially your enduring time to answer to our proposals.
Just keep in mind that this is not covered by the initial proposal. I am also not sure if there can be situations with load-unload restriction and a signed maxstay for the loading and unloading.
The proposal for parking:lane explicitly mentions to use load-unload for loading zones.
The alternative would be to make that a special traffic type like “delivery” or “destination” and use it in conditions like maxstay:conditional=1 hour @ (loading-unloading), but let’s not drift off this far.
Thank you for your intensive participation in solving this problem! Even if we are not really closer to a solution at this point 
As we can see, it is complicated and there might be no “simple” solution. It rather needs a new, pragmatic approach, which must not be too complicated (in order to be usable for as many mappers as possible).
First of all, a few findings that have emerged so far:
-
parking:right:parking=noseems to be a bad idea because, as you have shown, on separately mapped parking spaces something likeparking=street_side+parking:conditional=no @ (Mo-Fr)can happen (the same key is used for different statements - a no go). There are no meaningful synonyms for “parking” and with any other term the advantage of “catchiness” is lost. - Physical and legal attributes are treated separately from each other, so
parking:right=no_parkingor similar isn’t working (that was the old, deprecated schema). -
maxstayis intended for time indications.load-unloadis a documented, but not accepted exception which might be unfavourable in general (might need to be discussed separately). It might be inaccurate to use it to distinguish different forms of short term parking restrictions defined mostly by actions, and that can occur together with time restrictions (e.g. max. 20 minutes loading). -
accessis used to describe legal restrictions for different user groups (public[yes], private, customers…) and vehicle types (motorcars, hgv…). Our “no parking gradual restrictions” aren’t fitting here - an other approach is needed.
So how could a pragmatic solution, as simple as possible, then look like… We need a new approach… So how about that:
There are different forms of parking restrictions:
- there can be a restriction on user group or vehicle type (
access) - there can be a time limit (
maxstay) - there can be a fee (
fee) - there can be a restriction on actions you are allowed to do - like stopping, waiting, loading or charging (currently among others covered by
parking:conditionvalues - so we just need a new tag for this!?)
This leads me to simply propose something like parking:right:restriction for rather “action-defined” restrictions. Let’s no longer use the former term “condition” to avoid the messy syntax “condition:conditional”. Values I have in mind:
-
no_parking|no_waiting|no_stopping|loading|charging
Are there more? The list can be continued if necessary. I can’t imagine a situation where more than one of these can occur at the same time for the same user group and the same type of vehicle. If there are possible cross-overs, one should be able to express them with conditional tagging.
Edit: restriction as a key is used in a similar way in (turn) restriction relations (e.g. no_right_turn, no_straight_on, only_left_turn…). Fitting well in my opinion, althought it’s a (unproblematic) homonymous use.
I like that approach. But for my ear restriction=charging is ambiguous (is charging restricted here?) So, the only thing I’d change is to use the same semantics as in turn restrictions, to only have values with “no” and “only”. So for our case:
no_parkingno_waitingno_stoppingloading_onlycharging_only
This would also more closely mirror what you can find on traffic signs.
This looks a lot better and I think I like the approach a lot. The only thing that feels wrong is mixing the no_-values with things like loading or charging. Can’t we just use parking, waiting, stopping, loading and charging?
Otherwise this seems to be superior in flexibility. It works also allow us to express something like parking:left:maxstay:waiting=3 minutes. With negated values, this would not make much sense.
I agree that positive values might be better than negative ones, but I think, we’d need to think about another key than restriction then. Because for my ear, “waiting” is not a restriction.
I think we should somehow try to avoid such deep nested keys. How am I supposed to know if it is maxstay:waiting or waiting:maxstay?
If I remember correctly, we already use maxstay:hgv and the likes and not hgv:maxstay. And if the goal is being able to use all these tags for amenity=parking, there will be some level of nesting anyway 
You don’t need the waiting suffix. If there is “waiting” allowed (in most countries, this legal category is not existing, by the way, so in this countries we are talking about “stopping”), you map this situation by just using
parking:left:restriction=no_parking
parking:left:maxstay=3 minutes
(Edit: no_parking implies that waiting/stopping are allowed. And usuallyno_parkingis the statement that is signposted in situations like this, because traffic signs stating “stopping allowed” are very rare.)
or
parking:left:restriction:conditional=no_parking @ (Mo-Fr)
parking:left:maxstay:conditional=3 minutes @ (Mo-Fr).
Ich muss jetzt leider Mal auf Deutsch antworten. Bei uns ist ja Halten definiert als: bis zu 3 Minuten im Auto mit laufendem Motor.
Ist es das, was Ihr hier stopping nennt, oder was? Ich hatte stopping eher als pickup/dropoff verstanden. Es ist schwierig mit verschiedenen Sprachen, denn bei uns ist stoppen ja das verkehrsbedingte, unabsichtlich Halten 
But this will then depend on the country? So in some countries, no_parking equals waiting and in some stopping?
Der Motor muss nicht laufen, aber grundsätzlich ja. Laut dieser Website bedeutet in den USA:
no_stopping: Man darf nicht anhalten, wenn man nicht verkehrsbedingt muss. Das entspricht unserem beschilderten absoluten Halteverbot (gilt zusätzlich z.B. auch auf Schutzstreifen).
no_standing: Man darf das Auto nicht verlassen, aber Passagiere ein- oder aussteigen lassen. Das entspricht ungefähr dem Parkverbot nach §12 StVO (an Kreuzungen, Ausfahrten etc.)
no_parking: Man darf das Auto zum Be- und Endlagen verlassen, muss aber in seiner Nähe bleiben. Das entspricht dem eingeschränkten Halteverbot.
I’ll provide a quick translation 
In this context, we are talking only about “intentional” actions/stopping. What exactly stopping, waiting or parking means in detail differs from country to country. In Germany, it is mainly regulated in §12 of the StVO/local traffic law. But this categories occur all over the world and are expressed almost everywhere with similar traffic signs. In Germany, for example, there is an “Absolutes Halteverbot” (“absolute no stopping” - meaning “no stopping” in the OSM sense, signposted with “X” in a circle) and a “Eingeschränktes Halteverbot” (“restricted no stopping” - meaning “no_parking”, signposted with “/” in a circle).
(But this categories are still in use with the former parking:condition schema, so thats nothing “new”.)
Edit: In my opinion, there is no need to tag “waiting” in Germany, since this kind of restriction is only implied by “small scaled” structural conditions like driveways or intersections and therefore can be derived from the corresponding OSM features. But there is no sign for that, in contrast e.g. to the US.
So to summarize this for me: parking, waiting and stopping are values you picked yourself, and their respective implications vary from country to country, which is why you cling to the negative form, so it reflects the signs on the road, not the actual legal implications (e.g. is leaving the car allowed, is loading allowed). I get that now and while it might seem logical, it feels like we’re tagging signs instead of what their implications are in detail. I can live with that, but it sure pushes a lot of work to the data consumers, while I’d prefer to be able to tag all legal implications somehow. But that might be too error prone, since a single sign would sometimes require a dozen of tag/values and no one tags them all correctly.
This is the norm in California; the time limit can vary from loading zone to loading zone. In other jurisdictions, the time limit may be defined by local ordinance but not signposted.
So far the page on homonymous keys doesn’t cover contradictions across different namespaces, so you’re good. 
The wiki also has a more nitpicky compilation of counterintuitive keys (that only barely scratches the surface). It is a worthy goal to strive for consistency when coining a new key or subkey, but your suggestion seems more intuitive to me than condition.
I’ve been following with interest, thanks for a great suggestion! With regard to “unsigned” legalities, in Queensland, Australia, you have:
https://www.qld.gov.au/__data/assets/image/0019/42922/r5-23l.png
"Loading zone signs
You must not stop in a loading zone unless you:
are dropping off or picking up passengers (stopping no more than 2 minutes)
are dropping off or picking up passengers with a disability (stopping
no more than 5 minutes)
are dropping off or picking up goods (stopping no more than 20 minutes)
have a commercial vehicle identification label (issued by the local government for that area)
are driving a bus, truck or commercial vehicle (stopping for no more than 30 minutes).
The sign may give a length of time for stopping. If so, you must follow the times displayed on the sign."
I can’t see any way that we’d be able to tag this on every Loading Zone sign, so just using parking:left=loading_only, & leaving it up to the driver to know the actual legal restrictions, seems a simple solution to me! 
parking:*:restriction= =no_* and =*_only would form another option, but doesn’t get around the length limit and other issues with multivalue. The difference with turn restriction is different directions are separate objects, while road-based parking restriction have to be tagged together.
On the contrary for simple cases, instead of a straightforward parking:right:*=private, this has to further override by parking:right:restriction=no_parking + parking:right:restriction:conditional=none @ (private). So I don’t find it more elegant.
Another problem is this again breaks the consistency with the status quo in the much more numerous amenity=parking. Instead of a common amenity=parking + access=private, I assume this has to do amenity=parking + parking:restriction=no_parking + parking:restriction:conditional=none @ (private) ???
But parking:right:access=private already has the same meaning as parking:right:restriction=no_parking (may depending on local laws) + parking:right:restriction:conditional=none @ private… So usually there is no need for tagging monsters in this simple cases.
I’ll update the proposal page today then we might discuss this using example cases.
P.S. To me, this seems comparable to expressing a time limit with restriction=no_parking @ (stay > 30 minutes) instead of maxstay=30 minutes…
As explained above I don’t think parking restrictions and parking access should be mixed. Your example should be parking:side:access=private in lane tagging.
But maybe I am missing something. It’s better to discuss this with real examples.