No_parking/no_stopping as access graduations on parking lanes

General talk Tagging general discussion
, , ,
1

While working on the street parking revision proposal, we are facing an issue that we have not been able to solve elegantly for a long time and which I would like to present here for wider discussion.

Describing the problem: There are different degrees of “no parking”. “No parking” usually means that you are still allowed to stop or wait. If you are not allowed to do so, there are “no stopping” rules. In some countries there is an extra grade of “no waiting/no standing”. In addition, there are loading zones where you are also not allowed to park, but loading and unloading is explicitly allowed.

The old street parking schema has many weaknesses, which we address with the proposal. But in this one point it had an advantage, because there was a simple tag to describe this condition (no_parking/no_standing/no_stopping/loading).

But in OSM we usually use the access schema to indicate legal restrictions on the accessibility of a feature. The old parking schema deviated from this, which we now want to change - because parking restrictions can be mapped very well with the common keys like access, fee or maxstay. Only in the described case it is a bit more complicated: because such parking restrictions are graduations of “no” or “restricted/limited” access.

Our current solution is to use access=no if you are not allowed to park (because then it is not a parking space). To be able to express the gradations, we have proposed waiting=no and stopping=no (see the proposal page for the details.) Each of these tags implies the others, so using one of these three tags is always sufficient. For loading zones, we use the documented in-use tag maxstay=load-unload.

This works, but it is not perfect. Because only one of these rules can be applicable at the same time, but they are expressed with four different tags. Inconsistencies are therefore possible. Moreover, it is not so intuitive to use access=no, although certain actions (e.g. stopping) are still possible.

A separate tag like condition=no_parking/no_stopping... we consider unfavourable, as we have the access/fee/maxstay schemes exactly for expressing such conditions. Instead, a simple alternative could be to propose separate access tags for use on parking spaces, i.e. access=no/no_parking/no_waiting/no_stopping as well as access=loading. These would extend the range of documented access tags and it should be clear that they are not intended for use on traffic routes and other objects. With access=variable, there is already such a documented value that is somewhat out of the ordinary.

What do you think? Is there anything against proposing new “single-purpose” access values of this kind? Or are there other elegant solutions?

1 Like
2

So parking:right:access=no would be used in case of parking lane not existing on the right side? For example with parking-free sidewalk?

Or would it be used in case of parking lane existing but not usable for parking/standing/stopping but accessible for other purposes (turned into restaurant seating? fire lane?)

3

That, to me, feels wrong. Using :access=no to say “you can wait and stop here, but not park” is not what I would expect this to say. I understand where you’re coming from, but I don’t think the access-tagging schema is suitable to express parking/waiting/stopping-allowance. Of course, we could add no_parking, no_waiting and so on to the access-schema, but they don’t contradict the already existing values, they express something completely different. So my gut-feeling is: needs a different approach. While the old one maybe wasn’t perfect, it was easy to use and understand.

The other thing that looks a bit weird is using :waiting and :stopping for a feature that’s either or and not “zero, one or more”. If stopping is forbidden, then waiting is forbidden as well. Automatically. But your schema makes it possible to map “stopping forbidden, but waiting allowed”. I prefer the old approach of having a single unambiguous value that doesn’t allow this to happen.

Don’t get me wrong: the proposal is already very solid and in many regards a lot better than the old one. But this particular part sticks out like a sore thumb.

Sign Tagging
parking:right:access=no (access in context of parking means, there is no parking . However, you may wait or stop here.)
1 Like
4

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

5

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.

6

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.

7

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
8

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.

9

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
10

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.

11

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.

12

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.

13

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.

14

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?

15

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
16

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
17

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?

18

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.

19

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.

Guadalupe River Park
Guadalupe River Park1920×1440 359 KB

1 Like
20

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.