[Tagging] tagging of one-way cycle lanes

[Paul Johnson]

OK, a little more thought on this.

On Wed, May 9, 2018 at 11:45 PM, <osm.tagging at thorsten.engler.id.au> wrote:

> If I may correct your suggestion, that’s not quite right.
>


> The lanes=* key should be used to specify the total number of *marked* [image:
> Wikipedia-16px.png] lanes <http://en.wikipedia.org/wiki/en:lanes>of a
> road.
>
> The following lanes should be *included*:
>
> ·         General purpose [image: [W]] traffic lanes
> <http://en.wikipedia.org/wiki/Lane> suitable for vehicles wider than a
> motorbike.
>
> ·         [image: [W]] Bus lanes <http://en.wikipedia.org/wiki/Bus_lane>,
> that are reserved for public service vehicles (PSV), for example buses and
> taxis. Additionally to the total number of lanes, consider to tag the
> number of lanes for PSV with lanes:psv=*, lanes:bus=* and lanes:taxi=*.
>
> ·         [image: [W]] High-occupancy vehicle lanes
> <http://en.wikipedia.org/wiki/High-occupancy_vehicle_lane> (sometimes
> also called carpool lanes, commuter lanes, express lanes, transit lanes).
> The number of such lanes could be tagged using lanes:hov=*.
>
> ·         Other lanes such as [image: Wikipedia-16px.png] spitsstroken
> <http://en.wikipedia.org/wiki/nl:Spitsstrook>(nl) in the Netherlands or [image:
> Wikipedia-16px.png] temporäre Standstreifen
> <http://en.wikipedia.org/wiki/de:Stra%C3%9Fenquerschnitt#Seitenstreifen>(de) in
> Austria, Germany and Switzerland which are available to traffic at certain
> restricted times, for example during the rush hour.
>
> ·         Longer slip-roads, for example on motorways and other fast
> major roads. Turning lanes for minor roads are not normally included. See
> turn <https://wiki.openstreetmap.org/wiki/Key:turn>=* for further details
> about tagging turning lanes.
>

I agree.  Because bus, HOV and taxi lanes are included because knowing
where they are and whether or not they can be used by a specific mode is
important, bicycle lanes should also be included.


> And the following lanes should be *excluded*:
>
> ·         Minor slip roads without a deceleration/acceleration lane, i.e.
> the main road is wider only because of the intersecting road.
>
> ·         Parking lanes. Consider using parking:lane
> <https://wiki.openstreetmap.org/wiki/Key:parking:lane>=* to provide
> further information.
>
> ·         Bicycle lanes. Use the tag cycleway
> <https://wiki.openstreetmap.org/wiki/Key:cycleway>=lane
> <https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dlane> for those.
>
> ·         Emergency [image: [W]] shoulder lanes
> <http://en.wikipedia.org/wiki/Shoulder_(road)>. See shoulder
> <https://wiki.openstreetmap.org/wiki/Key:shoulder>=* for further details.
>
>
I agree with this mostly, except for the bike lane situation.

And in a related note, it would be nice to have a method to deal with
parking lanes that are *not* curb lanes, as this is the most common method
used in the US to create Dutch-style segregated cycleways (the bike lane is
along the curb, then on the side of the bike lane that's not against the
curb, you have a white flush median (theoretical gores on freeways are a
kind of white flush median, you're supposed to treat it like a curb in the
roadway), and on the other side of the flush median, you have the parking
lane.  But that's another can of worms and the situation isn't so
widespread as to be a serious problem (yet), unlike the weird exclusion of
bike lanes from bike lane tagging.  Tagging as separate roads feels
incorrect in this case (as bollards or other physical barriers tend to be
absent).


> So a “normal” two way road with cycleways (in Australia, with left hand
> traffic) would be tagged as:
>
>
>
> cycleway=lane
>
> lanes=2
>
> vehicles:lanes:forward=no|yes
>
> vehicles:lanes:backward=no|yes
>
> bicycle:lanes:forward=designated|yes
>
> bicycle:lanes:backward=designated|yes
>

This breaks, because you're tagging for four lanes and setting your total
lanes to 2.


> When tagging to this level, I generally try to also add the width:
>
>
>
> width:lanes:forward=1|3
>
> width:lanes:backward=1|3
>

This is a good idea, as older bicycle lanes tend to be significantly more
narrow than general access lanes.


> in JOSM the “lane and road attributes” mapstyle will help visualizing
> these tagged lanes.
>
>
>
> Use vehicle instead of motor_vehicle (to keep carriages out of your cycle
> lanes…).
>

Right, I tend to use access:lanes as the basic rule since no other modes,
only bicycles, are allowed in bicycle lanes in Oklahoma (it's slightly more
lax in Oregon, where almost any nonmotorized mode is allowed, and in
California it's just a hot mess since bicycle lanes double as continuous
turn lanes for other modes).


> Important: Do NOT include the cycleway lanes in the lanes=x count! The
> lanes count (which only counts marked lanes for motorized traffic) and the
> number of entries in the :lanes prefix keys can and will be different!
>

I honestly can't fathom why you would tag more lanes than the lane count,
is there anything that can actually handle this without just going, "Whoa,
let's not use this data, it's obviously screwed?"


> (Which is maybe somewhat unfortunate, but the lanes=count tag predates the
> :lanes prefix tags by many years, and has been used that way all over the
> place. Mixing different definitions of the lanes key in different places,
> or even just different segments of the same road, is going to result in
> useless, unreliable data as a data consumer will have no way to
> differentiate what definition of lanes=count would apply.)
>

Right, I think excluding any lanes of travel (regardless of mode) is a
significant flaw in the tagging and it's just not something existing tools
can deal with, nor does it particularly mesh with how to treat other types
of lanes.  And not including bicycle lanes precludes lane guidance for
bicycles in any usable manner, especially as cycleways get larger and more
complex with time on the ground (the London cycle superhighways, and
Portland's "throw anything at the wall and see what sticks" ongoing
experiment with sometimes really bizarre stuff) does mean that not treating
these as lanes like other lanes on the ground is going to be a very big
shortcoming in our data model.

I'm not saying tag for the renderer, but I am saying Osmand did stumble
backwards into doing the right thing (well, almost, it doesn't understand
lane access *yet*), but it will provide lane guidance for bicycles and do
so accurately on cycleways (where lane access isn't a thing).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180510/cc5f4f1d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 701 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20180510/cc5f4f1d/attachment-0001.png>