Cycleway lanes on oneway streets

[hungerburg]

A recent ping reminded me to update my local A/B-Streets install. Browsing around my city in A/B-Street, which is always a pleasure, I got to see some bidirectional cycleways, which in fact are single direction only. Eg. https://www.openstreetmap.org/way/25745877 has a lane for cyclists contra-flow motorists. Its tagging looks like polished with StreetComplete, still I consider the tagging accurate and complete, if not over-complete.

In A/B-Street, the "opposite-lane" (an old-fashioned osm jargon) for cyclists renders as a bidirectional cycle-way, where in reality, it is just a narrow cycle-only-lane contra the one-way. Cyclists going the motorist-one-way direction are to use the carriageway just as usual.

The OSM-Wiki is silent about directionality in such cases. I asked on the new forum, but only got on response from somebody, sharing the same background that I operate on ;) Is this different in e.g. Seattle? Or, are there just no tiles/presets for that? Or …

[dabreegster]

Hi! This is indeed some kind of bug. We've actually been splitting out the OSM lane parsing logic into a dedicated project, https://github.com/a-b-street/osm2lanes, so I'm going to move the issue to that repo. A/B Street is just about to cutover to using this, so when we fix the issue in osm2lanes, it'll be reflected in A/B Street. (And in osm2lanes, we have much better structure for testing things like this.)

The interesting bit: osm2lanes also thinks the cycleway is bidirectional. If you go to https://a-b-street.github.io/osm2lanes/ and type in way ID 25745877, you'll see this:

If I'm reading the wiki correctly, I'm a bit confused about oneway:bicycle = no. I think maybe cycleway:left = opposite_lane is appropriate -- https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dopposite_lane. In fact, osm2lanes doesn't parse this yet; we have #150 open for it, and it's one of the things blocking A/B Street moving over to use osm2lanes, so I'll fix it soon.

So let's

1. Figure out the correct tagging here
2. Make sure there's a test in osm2lanes asserting what should happen
3. Finish moving A/B Street to using osm2lanes
   and then this'll be fixed up.

Also by the way, I live in London now, and we've got the contraflow cycle lanes everywhere! They can be confusing to use. Over here, they're getting mapped as separate objects entirely -- like https://www.openstreetmap.org/way/4975997 -- which makes it very hard to handle in software.

[westnordost]

cycleway=opposite_lane is old tagging, anything with opposite is. Of course, since it is not deprecated and still around, it must be supported by software. Anyway, I think this is not the topic for this bug report because the example given has been tagged with the "new style".

oneway:bicycle = no means that the road is not a oneway for cyclists. It is usually accompanied by a oneway=yes. I.e., it is a oneway road except for cyclists. This doesn't say anything about cycle tracks or cycle lanes.

cycleway:left:oneway = no means that cycle track/lane on the left side of the way is bi-directional. If the tag is missing, the default assumption for data consumers should be that it is not bi-directional.
If the road is a oneway, bi-directionality of a cycle track or lane on any side implies oneway:bicycle = no, but as far as I know, it is can usually be expected that it is tagged explicitly.

So, to summarize oneway:bicycle = no does not imply that if there is a cycle track on one side, that this cycle track is bi-directional. This is how it should look:

FYI the source in StreetComplete is here:

• parsing what cycleway a road has
• Tests for the same
• How StreetComplete tags different cycleways (might move the code to some other place in the code soon)

[hungerburg]

One cannot have a conversation on openstreetmap, so it seems, without competing ideas how to map the same stuff in different ways. Luckily, consumers need not take part in endless discussions. Unfortunately, consumers need to support different schemes.

The scheme applied on location indeed is very map-painter friendly. Just draw a blue casing on the side of the osm-way, that the cycle lane is said to be on and add a blue contra arrow to the one-way arrow of the base highway. It is also convenient to provide meaningful turn-by-turn instructions from a router.

Things get more complicated, when working on lane level, with lanes that always have a single direction. From what I can tell, cycleways in A/B-Street are of this kind.

Looking at the osm2lanes calculation, it seems to me, that it infers "cycleway:left:oneway=no" from "oneway:bicycle=no". I think, this step goes too far. I see a bit of head scratching ahead, to get the correct direction of cycle lanes tagged under this scheme. No idea, if this is even worth the effort. Though it is wrong, and so looks strange, for simulation purposes, it does not really matter much. I might spend a bit more thinking on how to solve this.

[hungerburg]

I see, that the text in the left-box on osm2lanes is editable. Shortened version of fetched tags gives me a bidirectional cycle lane:

cycleway:left=lane
cycleway:right=no
highway=residential
oneway=yes
oneway:bicycle=no
sidewalk=both

When I add the line below, I get an arrow on the cycle lane in direction of main traffic:

cycleway:left:oneway=yes

Tagging as observed in the wild though represents the cycle lane traffic going opposite the main traffic only. Some users therefore tag "cycleway:left=opposite_lane" (c.f. https://wiki.openstreetmap.org/wiki/Talk:Key:cycleway:left ) Following further reasoning down this talk page, perhaps I'd have to add this line instead:

cycleway:left:oneway=-1

HOORAY! This works out as intended. Problem solved? At least, in so far as osm2lanes is concerned, I'd think so.

Regarding OSM tagging, certainly not: Using opposite_lane to record that fact is truly worse than specifying directionality separately, it makes life harder for osm2lanes, as LHT / RHT and also directionality of the adjacent lane have to be considered.

Regarding sensible defaults: If osm2lanes defaulted to "cycleway:left:oneway=-1" instead of "cycleway:left:oneway=no"? That also would require to consider LHT/RHT, so a bit of a burden… And, to be honest, the fact that the road is not a one-way for bicycles, and that there is a cycle lane on its left side, says nothing about the one-way-ness of the cycle lane…

Update: I added cycleway:left:oneway=-1 to all the single-direction cycle lanes, cycle tracks and cycle share-busways that are on the left side of the carriageway in my home town. Felt quite a bit satisfied :) See my comment, on how this thread here may prove useful to solve #150 without having to consider much details, at least that is how I perceive of this now without much further thinking. Perhaps, the other even shorter shorthand cycleway=opposite_lane can be tackled by synthesizing the side from looking at driving handedness.

[hungerburg]

Update 2 in separate post: Looks like there actually is a default documented: According to https://wiki.openstreetmap.org/wiki/Key:cycleway:right:oneway the value defaults to the one of the "oneway" tag of the base highway.

One should be aware, that wiki documentation not always represents the will of the community or speaks for the popularity among mappers.

Yet, failing to come up with anything more sensible as a default, it might be enough to make oneway:bicycle=no not influence the value of cycleway:*:oneway, in order to close this issue here?

[droogmic]

I see, that the text in the left-box on osm2lanes is editable.

#176

[droogmic]

What do you think we should do with cycleway:left:oneway=yes in this example @westnordost ?

Should it be equivalent to cycleway:left:oneway=-1 as @hungerburg and emit a warning, or do something else?

[hungerburg]

As far as I am concerned, osm2lanes does now properly display the direction of the cycleway. Mind you, I changed the tagging there, 25745877. When I change the "-1" to "yes", the cycleway goes the same direction as the carriageway. Should be right so.

What remains, directionality of cycleways with unspecified direction. In a recent tagging-ML discussion, it was posted, that the cycleway inherits the direction from the carriageway then.

PS: osm2lanes should support passing way-id as a parameter, either in query-string or in hash.

[westnordost]

What do you think we should do with cycleway:left:oneway=yes in this example @westnordost ?

In which example? cycleway:left:oneway=yes means

cycleway:left:oneway=-1 means that the cyclists on the left side must go the opposite direction. In right-side-driving countries the former is very very rare but the OSM data model allows it.

[hungerburg]

In Austria, "-1" is the most often used value for "cycleway:left:oneway" key, c.f. https://overpass-turbo.eu/s/1ihb

Out of the 5 (out of 202) with "yes" (cycleway:left:oneway=yes in Austria from the wizard), I only looked at the one in the most western part of the country, it is certainly a tagging error; It is way id 620921694 - BTW: osm2lanes does not account for the left side cycle-track there.

Update: The left side cycleway is missing in the lanes plot, not the right side one. Add total number of oneway-cyleways.

[tordans]

JFYI, there are TagInfo instances per country/continent. They are a bit hidden, though…

• values for cycleway:left:oneway for Australia https://taginfo.geofabrik.de/australia-oceania/australia/keys/cycleway%3Aleft%3Aoneway#values
• values for cycleway:left:oneway for Germany https://taginfo.geofabrik.de/europe/germany/keys/cycleway%3Aleft%3Aoneway#values

A list of instances is hidden behind the <Logo> Database: <Name>-Link.

[westnordost]

So, cycleway:left:oneway=yes is certainly a tagging that should/would trigger a warning of a validator in right-side-driving countries, etc. but it is not necessarily wrong