> 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:
https://www.google.de/maps/@49.0056633,8.4349157,120m/data=!3m1!1e3
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
"half_on_kerb".
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.
Cheers
Tobias
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 [email protected]:
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
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
