No_parking/no_stopping as access graduations on parking lanes

what about case where there is no sign and just sidewalk without space for parking? Or cliff making parking impossible?

Then, depending on your country, you would tag this as parking/waiting/stopping forbidden and then add a reason, e.g.

parking:right:stopping=no
parking:right:stopping:reason=narrow

Reason is anything from the approved list.
I’m sure we could add :reason=embankment or :reason=hazard if we really want to tag this.

The possibility of a nonsensical combination isn’t necessarily a showstopper if the scheme enables us to express something that we couldn’t easily express otherwise. One benefit of breaking out subkeys could be simplified conditions: in some cases, (momentarily) stopping is allowed but waiting is only allowed if you’re loading and unloading goods, or only during certain hours.

This is the case that the previous street parking refactor addressed by introducing parking:lane:right=no, decoupling the physical presence of a parking lane from any regulations that apply to its use. The current proposal would replace parking:lane:right=no with parking:right=no.

Instead of parking:<side>=<lane_type> and parking:<side>:access=<access>, I think it would be more intuitive to have parking:<side>=<access> and parking:lane:<side>=<lane_type>.

This seems more consistent with how we tag other access restrictions, and parking:<side>=<access> also allows variations like stopping:<side>=<access> and waiting:<side>=<access>. The side can be omitted entirely if the same restriction applies to both sides, e.g. resulting in a simple stopping=no on major roads (which makes much more sense then parking:stopping=no or parking:both:stopping=no).

1 Like

Why it needs a different approach? If there is a parking lane with access=no_parking or access=loading, then it’s clear, that you can’t park there, but you are allowed to stop/wait or load. This would keep the advantages of the previous schema by moving them into the access namespace.

Note that using access-like tag to note “physical availability” (instead of “legal restriction only”) seems likely to not be accepted by some parts of community…

1 Like

parking:*:waiting= and parking:*:stopping= are used akin to access= modes to override as needed. Different modes can have different restrictions. It is very difficult to express multiple restrictions with =no_*. It’s convoluted, and users have to think of how to handle all cases correctly. Even I felt tired working this out. Don’t want to imagine how when I actually use it.
Another more critical reason is minimize the length of *:conditional=. Mixing everything in one tag will easily exceed the val limit.

Whether it is negative =no_* or positive =*, I explicitly stopped doing this. Separating them clears up thinking, simplifies the syntax, and most critically avoids issues with the length limit in *:conditional=. You can’t express =private etc easily, requiring *:conditional=* @ (private), not to mention thinking about the whole set of cases. If someone sees no parking with other restrictions, this allows parking:*:access=no to be easily put down first. Other users can then freely add more to override this base val, without the need to think about how to “refactor” the whole set of restrictions.
I’m against adding more access=, let alone without a comprehensive review. Although namespacing parking:*:access= avoids issues superficially, this doesn’t match the awareness and understanding of the access= syntax. Asking for them to “learn” and work with long *:conditional= is unnecessary
access=variable is documented with discussion contested by me and others.

I agree with the users stating that access is not a suitable tag for this. Access restrictions are about who may use a certain feature. But this is about what you are allowed to do there.

So lets keep parking:side:stopping and parking:side:waiting since they seem to be a pragmatic (and understandable) solution that “overrides” common access tags. Inconsistencies are theoretically possible, but are practically made difficult by the recommendation that only one of the values should be used at a time and that they are usually “no”.

What about parking:side:access=no meaning “no parking”? I see that as a catchy definition, but indeed it’s a bit hacky. If there are concerns here, parking:side:parking=no doesn’t look beautiful, but is also possible.

What about the loading issue? parking:side:loading=yes could be used instead of maxstay=load-unload - implying no parking, but stopping for loading is allowed. In contrast to the other “no parking grades”, however, this key would have to be used with yes instead of no which somewhat increases the chance of tagging conflicts like stopping=no + loading=yes.

But as already mentioned - such conflicts are possible in different situations in OSM, their theoretical possibility cannot be avoided in a complex field like parking restrictions anyway and in the end they are simply tagging errors that need to be corrected.

parking:side:stopping=no + parking:side:loading=yes + parking:side:stopping:reason=loading_zone sounds like a reasonable way to tag the type of loading zones common here. Currently I omit the loading condition (as there is none in the current schema) and you have to derive from the reason that it functions as a loading zone.

The problem with adding :loading is that there are different kinds of loading. How do we differentiate passenger loading/unloading from goods loading/unloading? What about a designated loading zone only for emergency vehicles?

We already have that problem with the current schema. parking:right:loading should be used with common access values (yes/customers/private…), so it might need a subkey or a conditional restriction for that. parking:right:loading:conditional=yes @ passengers or parking:right:loading:conditional=yes @ (Mo-Fr 08:00-10:00 AND goods) seems working for me using a user group condition.

Sounds like parking:right:stopping=no + parking:right:loading:emergency=yes/designated (restrictions for specific vehicles overwrite general restrictions, like other conditional restrictions do).

1 Like

Personally, I’d prefer a shortcut like parking:side=forbidden for simplicity. Sadly, the proposal suggests that parking: side=no means that there is no parking lane, so we cannot use that. On a second thought, how can there be no parking lane if the street itself can be used? I’m failing to grasp the difference and rationale.

1 Like

Yes, I was asking myself the same question with the current schema a few weeks ago: Is a parking lane always present if no other parking infrastructure is, but often you are not allowed to park on it?

That was the deprecated approach, which has been replaced by the parking conditional proposal a year ago. Physical and legal attributes are separated since then and will continue to be. parking:right=no just means that parking is not done there. This may be because there is simply no space (narrow road, reason=narrow is approved) or because it is forbidden. If there is a legal restriction, we use the former parking:condition or now the access tags.

The main reason we previously decoupled the physical lane’s presence from its allowed usage is that the allowed usage is much more likely to depend on the time of day and other factors. Another reason is that it allows task-based editors like StreetComplete to ask about one thing at a time. If we cram orthogonal characteristics into a single key, it becomes impractical for the editor to ask simple questions about the feature.

The absence of a parking lane may mean either “no parking” or “no stopping”, depending on the jurisdiction, but other localized parking regulations are possible too. For example, in this Mapillary trace in San José, California, a “No Stopping” restriction gives way to “Park Ranger Parking Only” (private parking, essentially) and then to “No Parking” and finally back to “No Stopping”, all without a parking lane. The roadway has only a bike lane on the side.

1 Like

I would disagree with parking:*:loading=. This overlaps with parking:*:*:reason=loading_zone. Loading is a purpose. The allowed vehicle operation is already described by “stopping”, “waiting”, and “parking”. It doesn’t explain whether it is for short or extended use.
What about charging? Do you further add parking:*:charging=??? (how do you distinguish dedicated charging where you are supposed to leave after full charge, and parking spots with charging allowing normally long stay) Will there be more that has to be added? This is not scalable.

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.

But anyway, thanks for clarifying.

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?