Wrong detection of conflict on lanes number?

[SomeMichael]

trafficstars

This concerns (way Version 33)

osmose reports: (lanes(lanes:*:backward)=2) - (non fullwidth=0) != (lanes(access:lanes:backward)=2) - (non fullwidth=1)

But from my point of view that's wrong. I guess osmose just checks access:lanes:backward=no|yes. That would make the first lane non fullwidth. But thers's also a psv:lanes:backward=designated|yes. Therefore the lane should be fullwidth, isn't it?

Thanks for your help!

[frodrigo]

No, all lanes are taken in account.

[Strubbl]

lanes:psv* are not counted, another example is https://osmose.openstreetmap.fr/en/issue/de41c950-22f9-0078-a2bf-a378988438dd

[BalooUriza]

Kinda wondering if assuming "full width" is a bad guess. This check will always trigger on designated bike lanes that can be used by cars, too. I also question whether this is even a reasonable check, given that excluding narrow bicycle lanes from counts makes validating and consuming the data way more difficult than it needs to be versus just counting lanes as lanes.

[Famlam]

This issue was fixed with https://github.com/osm-fr/osmose-backend/commit/ec95a440122bf75235f40d791f83921951463672 last month.

Note that the other issue reported is correct, see for instance the wiki of lanes:psv . The psv lane should be part of the overall lanes count, so lanes:backward = 2 if there's a regular lane and a designated psv lane in the backward direction.