search

osm-fr / osmose-backend

Part of osmose that runs the analysis, and send the results to the frontend.
GNU General Public License v3.0
94 stars 115 forks source link

Wrong detection of conflict on lanes number? #1309

Closed SomeMichael closed 1 year ago

SomeMichael commented 3 years ago

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 commented 3 years ago

No, all lanes are taken in account.

Strubbl commented 2 years ago

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

BalooUriza commented 2 years ago

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 commented 1 year ago

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.