[Tagging] lanes - is "parking allowed" a parking lane?

Tobias Zwick osm at westnordost.de
Sun Nov 22 00:47:11 UTC 2020

 > Alex noted that he found that the "lane" value might have a different
 > meaning already. I'll look into that and come up with an alternative.

I did this now, I looked for in which situations ...

parking:lane:*:parallel = lane
parking:lane:*:parallel = on_lane
parking:lane:*:parallel = in_lane

... were used. The tag (and the parking lane tag in general, anyway) is 
used only very few times in relation to the number of streets. It is 
still quite new. Together, less than 1% of all parallel parking lanes 
are tagged like that.
But for what it's worth, "on_lane" is the most popular of the above 
(probably because of its consistency with "on_street" and "on_kerb") and 
most of the times were used to describe situations like this:


So, parking is on the street itself (not on kerb, not street side) but 
has its own marked lane.

In any case, whatever if someone used "street_side" as a value for the 
parallel parking lane or "on_lane", "on_kerb", "lay_by" or 
"painted_area_only", its all the same as in that it does define an own 
dedicated space for parking cars as opposed to "on_street" and 

And in the end, what will give the most precision in measuring the 
drivable space (criteria #2) is to look at the width or est_width tag. 
No need to let the lanes tag duplicate this information but less precise.
If the lanes tag was used for that, then it would become eventually 
obsolete because it wouldn't carry any original information that cannot 
be recorded more precisely and less subjectively with another tag. On 
the other hand, data consumers attempting a visualization (criteria #1) 
need the information how many lanes are tagged.
So, I am going ahead an will add these two words to the documentation of 
the lanes key.


On 20/11/2020 14:03, Tobias Zwick wrote:
> You stated how you would tag that, which I'd summarize as
>  > Any parking on the street surface is subtracted from the lanes as the
>  > lanes-tag first and foremost indicates the number of usable lanes, not
>  > the number of marked lanes
> Ok, so apparently there is no consensus on that if there are marked 
> lanes, it's always the marked lanes that first and foremost should be 
> counted.
> But let's not fall in the trap that everybody states how he tags it and 
> in the end we can agree that we cannot agree. We have a problem to 
> solve, let's identify it and find a solution together. I'd say, the core 
> of it is:
> How to tag if usable lanes deviate from marked lanes?
> And the solution we are aiming at should fulfill at least these criteria:
> 1. that the street layout can be interpreted correctly and completely
>     (for data visualization, f.e. JOSM lanes plugin, abstreet, renderers
>      ...)
> 2. that the effective usable width of the street for car traffic can be
>     ascertained (for routers)
> ---
> The criteria above were already in my head when I wrote the second half 
> of my intial post: When do usable lanes deviate from marked lanes?
> -> When there are cars not parking in an own dedicated parking lane but 
> just at one side of the street. Hence, this example:
> https://westnordost.de/misc/parallel_parking_lane.png
> If these situations are tagged like this...
> (1)
> lanes = 2
> parking:lane:right = parallel
> parking:lane:right:parallel = lane
> (2)
> lanes = 2
> parking:lane:right = parallel
> parking:lane:right:parallel = on_street
> ..., both criteria are fulfilled, given the definition for lanes is:
> "if marked, number of marked lanes. Dedicated and marked parking lanes 
> don't count" (adding "dedicated and marked" to wiki definition).
> For visualization, the lanes tag can then be directly used. Routers will 
> want to additionally look at the parking lanes tag to see whether the 
> effectively usable road is being narrowed by parking lanes with 
> on_street or half_on_kerb and subtract that from the usable width.
> I further suggested this solution because of its separation of concerns: 
> Lanes is then just the marked lanes, no need to factor in possible 
> parking lanes into that one tag and estimate whether the parking cars 
> subtract enough of lane space to decrease it by one.
> So, the definition of parking lanes go into the parking:lane tag, 
> including where it is located. Well, and that's already how it is done, 
> so that's not a real change.
> The change here would be to find a tag the describes "parking lane is on 
> street surface but has its own space/lane". Alex noted that he found 
> that the "lane" value might have a different meaning already. I'll look 
> into that and come up with an alternative.
> Tobias
> On 20/11/2020 09:16, Mateusz Konieczny via Tagging wrote:
>> I would describe https://westnordost.de/misc/2or1lanes.jpg 
>> <https://westnordost.de/misc/2or1lanes.jpg> as road
>> with
>> - one lane driveable by full-size vehicles
>> - one parking lane
>> And tag it as:
>> lanes=1
>> parking:lane:both=parallel (judging from what is visible about left side)
>> Additional detail that I am generally not tagging may specify
>> for example:
>> parking:lane:right:parallel=on_street
>> parking:lane:left:parallel=on_kerb (judging from what is visible on 
>> photo)
>> Tagging whatever parking lane has just allowed parking that fully 
>> block it
>> or is it explicitly marked as parking lane can go into new tag (if not
>> covered by an existing tagging).
>> For example I would consider
>> https://wiki.openstreetmap.org/wiki/File:Barton_St_view_E_between_South_Park_Rd_and_Brown_St,_Macclesfield.jpg 
>> <https://wiki.openstreetmap.org/wiki/File:Barton_St_view_E_between_South_Park_Rd_and_Brown_St,_Macclesfield.jpg> 
>> as lanes=1, not lanes=3
>> -------------------------------------------------
>> This gets trickier with:
>> - illegal parking that nevertheless is accepted, widespread and 
>> typical, de facto changing
>> number of available lanes
>> For example street that in theory is lanes=2 but due to how people 
>> park and lack of need for two lanes,
>> it is de facto lanes=1 (cars driving over marked centerline as 
>> theoretical lanes are blocked
>> by cars)
>> - lane that switches between parking lane and driveable lane depending on
>> hour/day (lanes:conditional solves this)
>> - lane that switches between parking lane and driveable lane depending on
>> how many people park there
>> Nov 19, 2020, 15:17 by osm at westnordost.de:
>>     Hello all
>>     First of all, in the past, we have explored many edge cases for the
>>     lanes-tag in various discussions and I am happy that for the most
>>     part, it seems to be quite well defined by now. However, there is
>>     one edge case which is not uncommon at all but still unclear or
>>     awkward to tag. Look at this:
>>     https://westnordost.de/misc/2or1lanes.jpg
>>     It is a residential road marked clearly for 2 lanes, so it seems
>>     obvious to tag it with lanes=2. But on the other hand, you'll notice
>>     that there are parking cars on the right side that effectively
>>     render the right lane unusable. These parking cars would (currently)
>>     be tagged I believe as
>>     parking:lane:right=parallel
>>     parking:lane:right:parallel=on_street
>>     And the wiki states
>>         And the following lanes should be excluded:
>>         [...] Parking lanes [...]
>>     So here is an ambiguity in the documentation. On the one hand, if
>>     the road has marked lanes, the number of marked lanes should be
>>     tagged, on the other hand, there are these kind of "parking lanes"
>>     which do not have their own space marked as a parking lane but
>>     simply absorb the space assigned to normal car traffic. In OSM
>>     tagging, these are also "parking:lane"s as far as I know.
>>     We need to dissolve this ambiguity by defining a way how to
>>     distinguish between these two cases:
>>     https://westnordost.de/misc/parallel_parking_lane.png
>>     (1) a dedicated parallel parking lane. This lane should not count as
>>     a lane in the lanes-tag.
>>     (2) (parallel) parking is allowed (and used). This should be
>>     irrelevant for the lane count.
>>     My suggestion would be
>>     (1) parking:lane:*:parallel = lane
>>     (2) parking:lane:*:parallel = on_street
>>     Maybe especially those who recently involved themselves with parking
>>     lane tagging out and about and its documentation could also state
>>     their point of view here. According to the wiki edit history, looks
>>     like at least Mateusz Konieczny, Supaplex030 and Minh Nguyễn were
>>     active.
>>     What do you think?
>>     There is also at least one data consumer I know about that is using
>>     parking lane information and displays it visually,
>>     https://github.com/dabreegster/abstreet it would be good to know how
>>     they interpret and visualize the data.
>>     Cheers
>>     Tobias
>>     _______________________________________________
>>     Tagging mailing list
>>     Tagging at openstreetmap.org
>>     https://lists.openstreetmap.org/listinfo/tagging
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

More information about the Tagging mailing list