Turn lanes marked red in case of bicycle lanes

[Discostu36]

Vespucci Version

18.0.2 -->

Download source

Google Play

Device (Manufacturer and Model)

Fairphone 4

Android Version

Android 11

Behaviour/Symptoms

When mapping lanes, turn:lanes and cycleway:lanes like described on wiki, Vespucci marks turn:lanes red because lanes count and turn:lanes count don't match.

Expected Behaviour

This should not happen when cycleway:lanes with matching count are present.

[simonpoole]

The problem is that the issue of how to count lanes is really at least under specified if not unresolved.

Definitely in real life there are lots of use of bicycle:lanes without vehicle:lanes tags, some times there are motor_vehicle:lanes tags some times not. Definitely it needs a clear statement that if bicycle lanes are present the turn:lanes tags needs to include all lanes (and are bicycles the only exception, or are there others?).

Further note shouldn't turn:lanes:backward be through|no|right in this case (it it was fixing the issue would amount to counting the non-no lanes).

[Discostu36]

Further note shouldn't turn:lanes:backward be through|no|right in this case

I don't think so, because the bicycle lane has a through arrow, not allowing going left or right.

[simonpoole]

I don't think so, because the bicycle lane has a through arrow, not allowing going left or right.

But how would a car orientated router know that the middle lane is bicycle only without being aware/processing of the bicycle:lanes tag (and potentially others). Does any car router do that currently?

PS: I'm focusing on this because lane assist is mainly a motorized transport thing, and wondering if this is issue is the reason for a lot of lane routing breakage I've seen of late.

[Discostu36]

As not even Osmand supports this, I guess no navigation app does.

[Discostu36]

Just to be clear: I am not saying that lane tagging is not broken. I am only saying that Vespucci marks the documented way of tagging as a mistake.

[simonpoole]

Just to be clear: I am not saying that lane tagging is not broken. I am only saying that Vespucci marks the documented way of tagging as a mistake.

I'm just trying to investigate what the best way of validating the lane counts in a conformant fashion is. For example dedicated motorcycle lanes seem to be an issue too.

[simonpoole]

Note: the mechanism that tries to keep the lanes value and number of lines in the MultiText in sync is preset driven, so for now there is no way to fix this outside of bespoke code, or, preferable in the end, a tag that actually holds the number of lanes.

[Discostu36]

@mueschel "solved" the problem like this:

The number of lanes is determined by reading all tags of way containing a :lanes part and the lanes tag itself. For both forward and backward direction, the maximal number is used

https://github.com/mueschel/OsmLaneVisualizer#interpreted-tags

[simonpoole]

Thanks, note that as pointed about above, the short term fix is likely to be removing the linkage to the lanes tag in the preset.

[mueschel]

Hi, thanks for the ping.

I think the most sensible definition is the one that e.g. the JOSM validator implements: You can't directly compare lanes=* and XY:lanes=*, because of the different definition what a lane is. The only thing that needs to be true is that

• XY:lanes=* always needs to be greater or equal to the number in lanes=*
• all XY:lanes must have the identical number of lanes

For the data user: If a tool uses XY:lanes on a specific way it should rely on the information in these tags and ignore the information in lanes=*. If tagging is done properly, there is no additional information to be gained from reading lanes=*

[simonpoole]

For the data user: If a tool uses XY:lanes on a specific way it should rely on the information in these tags and ignore the information in lanes=*. If tagging is done properly, there is no additional information to be gained from reading lanes=*

As pointed about above there doesn't seem to be a data consumer (outside of validation tools) that does it 'properly', in particular with the current definitions turn:lanes is a dumpster fire.

[mueschel]

/offtopic/
... IMHO a dumpster fire that is worth to be kept burning until it is turned into a cozy little fireplace with a bit of effort. That shouldn't be too complicated to get right in the majority of cases where lanes != :lanes. The really complicated cases are just a few.
/offtopic/

[simonpoole]

/offtopic/ ... IMHO a dumpster fire that is worth to be kept burning until it is turned into a cozy little fireplace with a bit of effort. That shouldn't be too complicated to get right in the majority of cases where lanes != :lanes. The really complicated cases are just a few. /offtopic/

The issue is not the lanes count bit, that is done and dusted, aka the lanes tag is unusable, but the fact that the interpretation of turn:lanes depends on any number of other tags that might be known by the application or not.

[mueschel]

other tags that might be known by the application or not.

Actually it's not that bad. I'd argue that an app that shows routing information needs to be aware of access tags - and in case of a car router that would be motorcar, motor_vehicle, vehicle and access. And in case of lane-based turn information it needs to check these access tags on a per-lane basis. There can't be a forbidden lane without any of these tags, especially there is no need to check tags that only apply to different kinds of vehicles. And if there is such a tag, the corresponding arrow in the instructions should be not highlighted and slightly less prominent than other lanes.

[Discostu36]

One could argue that, as access lanes and turn lanes both were introduced in the same proposal 10 years ago, it's the application's fault to only support half of the scheme and getting incorrect results because of that.

Edit: mueschel was faster and more verbose

[simonpoole]

other tags that might be known by the application or not.

Actually it's not that bad. I'd argue that an app that shows routing information needs to be aware of access tags - and in case of a car router that would be motorcar, motor_vehicle, vehicle and access.

motorcycle, bus, psv etc etc etc etc

(and that's without even contemplating stuff that breaks access tagging hierarchies like hgv only lanes).

[mueschel]

motorcycle, bus, psv etc etc etc etc

Only if the route is planned for motorcycle, bus, psv...
There's no need to check tags that don't apply to your current mode of transportation: We don't have access tags that exclude other traffic, like bus=only (luckily).

hgv only lanes

These need to have a vehicle=no or access=no tag as well.

[simonpoole]

Only if the route is planned for motorcycle, bus, psv...

Ehhh how do you propose to determine if a car is allowed to use a lane from

turn:lanes=through|through|right

without the detailed and complete per transportation mode information?

[Discostu36]

By additionaly looking at access:lanes, vehicle:lanes and motor_vehicle:lanes. All others can be ignored.

[mueschel]

It's sufficient to check the access tags that apply to your current vehicle:

in case of a car router that would be motorcar, motor_vehicle, vehicle and access.

No other transportation mode access tags need to be checked. Essentially those tags you already need for routing, just in the ":lanes" version. Compare to the initial example: There's a clear vehicle=no for one of the lanes, no need to be aware of bicycle tags in a car router.

[simonpoole]

It's sufficient to check the access tags that apply to your current vehicle:

in case of a car router that would be motorcar, motor_vehicle, vehicle and access.

No other transportation mode access tags need to be checked. Essentially those tags you already need for routing, just in the ":lanes" version. Compare to the initial example: There's a clear vehicle=no for one of the lanes, no need to be aware of bicycle tags in a car router.

Except that there are 1.4 million turn:lanes tags, and only roughly 1% of that for transportation mode specific tags, aka a dumpster fire QED.

PS: the fact that nobody supports the insanity should give you a hint regardless of my opinion.

[mueschel]

I'm very sure that 98% of these turn:lanes don't need any additional lane-dependent access tags. I.e. 98% are simple, 1% is properly tagged, 1% need additional tagging.
Unfortunately the more complicated cases are the ones where lane based turn information is really helpful. Nobody needs turn lane instructions to find the exit lane of a motorway. They are helpful in crowded cities, but there the chance to have bicycle or psv lanes is quite high.

[simonpoole]

I'm very sure that 98% of these turn:lanes don't need any additional lane-dependent access tags. I.e. 98% are simple, 1% is properly tagged, 1% need additional tagging.

But you can only know if the situation is one of the 1% or not, or put differently the current tagging is correct and will not lead to people crashing in to each other, if you check for the presence of other *:lanes tags. So you need to know about *:lanes tags other than the mode of transportation you are currently routing for.

[mueschel]

Could you give us an example? I don't see how this can happen apart from clear tagging mistakes - and these are an issue for QA tools but not for routing apps.

[simonpoole]

Could you give us an example? I don't see how this can happen apart from clear tagging mistakes - and these are an issue for

Random example (overpass turbo search for turn:lanes=" and bicycle:lanes=*) https://www.openstreetmap.org/way/43375230

Yes this actually has a tagging error (vehicle includes bicycle in DE) and indicating that all vehicles can use all lanes was likely not intended, but used this anyway so you can see I'm not cheating. Any car router would need to know about bicycle:lanes to use this properly.

[mueschel]

I don't see an error with this way. Using vehicle=no and bicycle=yes on this special lane is perfectly fine, the more specific tag wins.

The car router doesn't need to know about bicycle:lanes - it just needs to see the vehicle:lanes tag (which applies to cars). This gives the information that there is an additional lane that cars are not allowed to use, but it doesn't matter who might use it. It could even show a hazard warning because there's a left turn allowed from the rightmost lane which might lead to a conflict with cars turning right. It only needs to check other access tags if a specific warning should be shown - but in that case you would need to check every tag on the way to be sure to take every potential hazard into account.

[Discostu36]

I agree, vehicle:lanes=yes|yes|yes|no implies that only the first three turn:lanes should be used for car routing, which is correct for this street.

[simonpoole]

Other random example https://www.openstreetmap.org/way/127921384

[mueschel]

Tagging mistake, likely caused by the common misunderstanding that 'designated' excludes other traffic. The way needs a vehicle:lanes or motor_vehicle:lanes tag.
This should be flagged as likely error by a QA tool, but doesn't need to be solved by a router.