For example:
restriction:lanes:forward=no_stopping|no_stopping|no_stopping?
I’m bit aware of an existing tagging scheme for that but your suggestions sounds reasonable but probably won’t be utilized anytime soon.
Additionally you could add the crossed areas with the newly road_marking=restriction + pattern=crosshatch
Key:road_marking - OpenStreetMap Wiki
Looking at taginfo there are 1888 traffic_restricion=no_stopping and 1712 restriction=no_stopping
Since restriction is documented, I would use that one, even though it seems no one has used it for lanes yet.
To remind others, this is not =no_stopping , as you can’t stay inside even when traffic is stopped, I suggest =no_blocking to follow other =no_* restrictions, as =keep_clear will be misunderstood for informatory white “Keep clear” text at driveways (can’t be enforced, only courtesy), and =box_junction is too specific (are these “junctions”?).
There was a comprehensive discussion and analysis on this and double “parking” rules between two of us @mueschel User talk:Kovposch - OpenStreetMap Wiki
My motivation is from local rules allowing parking on spots/lanes/bays on =fire_lane , and restrictions with yellow lines painted outside allowed parking/stopping spots. I’m using parking:restriction:lanes= for now, as there doesn’t seem to be a better solution yet.
I’d consider it a box junction, but I don’t know if there is established tagging even for that.
=no_blocking seems like a misnomer since you aren’t blocking anyone most of the time. Maybe =no_waiting as a weaker form of no_stopping?
I don’t think there’s any method presently to map “keep clear” zones nor am I aware of any way to consume such data, so I’m just assuming there’s a pretty limited use case on this. However, I do see the emergency signal, so that’d be something to map on the stop bar.
No waiting means no parking, or standing, depending on country. “Blocking” means you should not the obstruct the junction, and must always keep it free.
I forgot to mention the reason of advocating for =no_blocking is then you can use *:advisory=no_blocking for those “keep clear” text. It would be confusing to use *:advisory=box_junction for something that’s not a “box junction”.
Further to being on one side only, the cross-hatch can be applied on some or only 1 lane. So it doesn’t have to be the entire junction.
there’s the just approved road markings proposal. Not sure if it covers this case but could be extended if not
I’d go with keep_clear=yes on the section or if only one direction keep_clear:forward=yes / keep_clear:backward=yes or if lane dependent keep_clear:lanes:forward=no|yes
I’d keep clear of the parking schema since this is an independent concept/topic from street parking, it’s about avoiding blocking other vehicles from accessing the road during heavy traffic.
recently the road marking scheme was approved (technically it is about marking the area and not a section of road though).
road_marking=restriction
pattern=crosshatch
Personally I’d map that road marking as a separate area covering the physical marking rather than tagging the roadway. As for the traffic rule that applies to the stretch of roadway, keep_clear=yes is reasonable, at least as a stopgap.
If it needs to be part of a broader tagging scheme, restriction=no_stopping would get the point across (as mentioned earlier). To elaborate, this tag comes from the street parking scheme, specifically for tagging a separately mapped parking lane area. For the roadway, the scheme defines a parking:both:restriction=no_stopping parking:both:restriction:reason=clearway combination that occurs over 250 times. Removing the parking:both: prefix makes it a restriction that would apply to the traffic lanes, not to the curbside as a clearway would.
Personally I’d map that road marking as a separate area covering the physical marking rather than tagging the roadway.
absolutely, this was what I meant to say, and while it is only spatially related to the highway it would still be possible to understand where it applies on the highway.