I might have a very local view on this, that’s why I asked. Over here, there’s rarely a limitation depending on the time of day, so it’s either no parking, or no stopping, and that’s it. And it feels like this will now require an extra step, although I understand the rationale now.
What I cannot get behind, is arguing that it makes questions from street complete easier. The app can still ask questions in a wizard-like manner, without the tags being ordered that way.
To elaborate, the StreetComplete project has previously held back on supporting certain ideas for quests because they would require answering multiple questions at the same time, without the possibility of answering one but saying “don’t know” to the others. In this case, there needed to be a tagging combination that means there’s definitely a parking lane but whether you can park there is undetermined (unknown, unanswered, or too complex for the application). At the time of the refactor, parking:lane=no had already been deprecated in favor of no_parking and no_stopping, but it got undeprecated in order to capture that case.
In California, we have some additional purpose restrictions that are otherwise similar to a loading zone, such as “Mail Deposit Only” around drive-through postboxes and ballot dropboxes, plus “Car Share Parking Only” for ride-hailing drivers to wait to receive customers and some spaces at private lots for expectant mothers. Would it be better to represent these purposes as conditions, reasons, or subkeys?
More and more, I think we need parking:right:parking=no. It doesn’t look nice, but it fits well with the “graduation” logic and allows to map the grades of “no parking” in a more intuitive way:
parking:right:parking=no (implies waiting and stopping allowed) parking:right:waiting=no (implies no parking, but stopping allowed) parking:right:stopping=no (implies no parking and no waiting)
parking:right:access (or it’s traffic mode specific variants like parking:right:motorcar) or parking:right:access:conditional overwrites them, e.g.
parking:right:parking=no + parking:right:access:conditional=yes @ (Mo-Fr 08:00-18:00)
(there is no parking, except Mo-Fr 08:00-18:00. Stopping allowed anytime.)
parking:right:access=no is also possible, but means an “unspecified” no parking restriction. E.g. parking:right:access=no + parking:right:motorcar=designated means, parking only allowed for motorcars, but e.g. a bus might stop - but that isn’t specified.
With this, special “short term” situations like loading zones can be tagged without using improper access tags like access=yes or access=no.
Regarding loading zones:
parking:right:access=no (or more specific: parking:right:parking/stopping=no, depending on local situation) + parking:right:access:conditional=yes @ loading
also is a specific tagging, expressing the loading zone feature with access/conditional tags using a “user group” or “vehicle usage” condition. parking:right:access=no + parking:right:access:conditional=yes @ charging is still in the examples list and works similar. parking:right:*:reason=loading_zone is a good (actually implied) add-on for loading zones, but in my opinion it should not be the “main attribute” for a loading zone (as reason is always an optional, more descriptive tagging).
Some other examples:
parking:right:parking=no + parking:right:access:conditional=yes @ loading + parking:right:maxstay=10 minutes - loading zone with time limit (therefore using maxstay=load-unload isn’t a good idea).
parking:right:stopping=no + parking:right:access:conditional=yes @ loading + parking:right:access:reason=passanger_loading_zone - to specify something like a “kiss and ride” passenger drop of (still an approved value from the reason list).
parking:right:stopping=no + parking:right:access:conditional=yes @ (Mo-Fr 08:00-12:00 AND loading) - a loading zone at certain hours.
With good/clear documentation and showing examples, this will be easier to apply than it might seem at first glance.
Sounds very similar to a loading zone (“unload mails” ). Maybe use a specific reason for that?
Maybe parking:right:car_sharing=permit/private? (car_sharing is a documented value in the transportation mode list)
If its mapped as separately mapped parking space: parking_space=pregnant, otherwise parking:right:access[/parking/stopping]=no + parking:right:access:conditional=yes @ pregnant?
The idea of parking:right:parking/waiting/stopping is basically that they are only used with value no to enable the different gradations of access=no in an intuitive way. The access schema should be used as usual otherwise.
In principle, parking:right:parking=no is a simpler form of a notation like parking:right:access:no=no_parking (or former parking:condition:right=no_parking, that don’t fit the access/fee/maxstay conventions).
This should be clearly stated in the documentation/definition and illustrated by clear examples so that there is no confusion later.
As I already explained above, I don’t think access should be used for no_stopping/waiting/parking as these are about what you are allowed to do at a location, but access is about who is allowed to do something at a location.
parking:right needs to be understood as a prefix, refering to a parking feature, that is mapped as an attribute of a highway centerline. All tags must work in exactly the same way without this prefix when used on separately mapped parking areas mapped with amenity=parking.
True, but to me that is a benefit.
If one would want to check for parking spaces (along roads) in a certain area, they should only have to check what parking:side=* says.
Otherwise it would be a stepped approach: first, check if stopping is allowed, yes? → second, check if waiting is allowed, yes? → finally, check if parking is allowed.
I see @Discostu36 already replied to this point. But going from another angle, if the conditional is not added to parking but access, this means that different conditionals for parking and stopping are not possible. But it is possible that there are signs like that.
E.g. no stopping during workweek, no parking during weekend, or similar. I thought I’d even seen such a case in one of the examples presented in the proposal wiki page but I might misremember.
That is actually a point that speaks for @Herrieman’s suggestion, not against it.
Parking as highway tag
parking as separate area
parking:right:parking=no
amenity=parking parking=no
What you can see in the right column is a classic troll tag. If you can’t park there, it is not an amenity=parking. Therefore, it does not make sense to use the parking tagging scheme for non-parking. Instead, no standing and no stopping should be mapped with their own keys, independently of the parking namespace.
There’s a certain elegance to this approach, but I’m a little wary of condensing this complicated table down to one key. Also, the existing maxstay and parking:condition:maxstay keys are duration measurements, which would be incompatible with this “event range” syntax from a data consumer or editor standpoint. There would need to be an awkward special case.
parking=no would in this case only be set if there was an actual no parking sign there. Sounds to me like a “troll situation”. Which “parking lot” would have a “no parking” sign posted? I guess, either
parking lots where the sign is in the “private parking lot” sign (example)
street parking reserved for loading/unloading, for certain vehicle types etc. i.e. where the value would be parking:conditional=no + parking:conditional=yes @ (...)
So, that tag would be a troll-tag only in the regard that data consumers also need to look out for the value of parking to check for the parking availability. So, I get why the current version of @Supaplex030’s proposal uses access instead of parking, to not introduce another tag data consumers need to check.
However, don’t they need to do this anyway for stopping and waiting too? Unless those are defined in a way that if either of parking, stopping or waiting is set, access must be set, too?
parking is already an established key that describes the kind of physical infrastructure, similar to what parking:lane does currently or what parking:left/right would do under the proposal. It would be counterintuitive for tags like parking=lane and parking=surface to refer to what’s physically present but for parking=no to say that parking is disallowed. The more likely definition of parking=no is that there’s no parking infrastructure, which would contradict amenity=parking.
So, for this line of argument / proposed tagging discussed, no_parking=yes, no_stopping=yes etc. would not have this issue then.
But TBH I lost track of what alternatives were discussed, which were dismissed, which candidates are still in discussion and what each speaks for or against them. Maybe someone could summarize it?
). Maybe use a specific 
Sounds to me like a “troll situation”. Which “parking lot” would have a “no parking” sign posted? I guess, either
