abrensch
Avoid highway=construction
highway=construction is already in your lookup file, but the trekking profile does not check for it Please add it, it is really unpleasant to end up on such way Thank you
Still not fixed - another Brouter user hit this, mentioning it on the forum.
@abrensch we all know you are doing amazing work in your free time, and can do whatever you want at any time schedule, but could you maybe mention if you have these kind of things on your radar, or expect pull requests from the community, so we know what the status is?
Thank you!
Until @abrensch fixes the standard profiles, you may as a workaround use custom profiles, e.g. from Github repositiories of utack or poutnikl.
Discussed in https://groups.google.com/d/msgid/osm-android-bikerouting/19b79f1b-fe71-4f07-bfc5-945323493b7b%40googlegroups.com as well.
From https://github.com/abrensch/brouter/issues/208
Maybe BRouter should take into acount the value of the construction= tag to decide whether to route on it or not. I would expect that pedestrian (and bicycles) can pass on a highway=construction + construction=primary|secondary|tertiary|residential (main traffic being cars, side traffic can be maintained) but I would not expect that they could pass on a highway=construction + construction=cycleway|footway|path (main traffic is pedestrian / cycles) for instance.
I don't agree with Phyks. The view of pedestrians and cyclists being just "side traffic" (even on "residential" roads(!)) is a distorted and devastating car-centric view that has plagued city planning for decades. Let's not repeat that in OSM please. Unless there is an explicit
I fell for this issue as well in the case of a highway=construction, construction=cycleway just yesterday. And even worse, I tried to mitigate it/refine the tagging by adding a conditional access tag for the expected duration of the construction works... and fell for the next issue: conditionals are not supported either (#193, #300).
I get that conditionals are not trivial to support (not even the syntax is completely specified in some corner cases :) but highway=construction would be easy to just ignore and while there are some regressions (for construction sites where some mode of transport actually can pass), I believe it is must more user friendly to send them on a detour unnecessarily from the beginning than to present them a bad surprise in the field.
This is easily accomplished by adding else if ( highway=construction ) then 10000 to the profile where motorways are excluded (but there might be better ways to do it to allow for highway=construction, …, bicycle=yes for example.
while there are some regressions (for construction sites where some mode of transport actually can pass), I believe it is much more user friendly to send them on a detour unnecessarily from the beginning than to present them a bad surprise in the field.
Because such a single argument is hard to defeat, I would like to remind many other sloppinesses that, together, make up the "optimistic approach" of the "trekking" profile:
- a way with a bike route relation is always passable (even with access=no)
- oneway are allowed in wrong direction
- foot-ways are allowed
- turn-restrictions are ignored
- highway=path/track with no other detail allowd
- access=agricultural allowed
I think, if you get too restrictive, there is a tipping point where the "backbone" of your network collapses. And that leads not just to detours, bad "bad detours with bad surprises"
Construction is just one of these sloppinesses. I agree excluding construction by default for ways not intended for 2-lane vehicles is a good idea. Furthermore, every mapper is free to use access tagging to provide further details.
lol, so even if i would have added a plain access=no in that case because conditionals are not understood, it would have failed me (I think), because in this case there was a route relation that was not changed (and it should not be anyway imho: if there are no official detour signposts for the respective route then it officially goes there but you can't use it). so in total three brouter exceptions worked against me - and i don't think the way in question is in any way special... just a cycleway that is closed for a while due to renovation. i dont even know how i could map this without brouter routing over it apart from removing the way altogether or destroying the relation.
i totally agree with the idea behind the other rules you mentioned: the related tags specify legal rules but in the case of a construction site, physics is most often your biggest problem, sometimes even (lack of) safety. i definitely don't see that in the same category as using an underspecified "path" or ignoring a oneway sign. the usefulness of the routing rules obviously depends on the quality of the data, but i think in the current implementation more detailed data means worse results and that's really bad for both projects imho (mappers who care about brouter would need to break or at least bend osm rules to make brouter work correctly and brouter users get worse routes in areas where this is not done).
This issue is still there. For example, https://brouter.de/brouter-web/#map=13/52.3857/4.9789/standard,Waymarked_Trails-Cycling&lonlats=4.93268,52.402524;5.028648,52.397519&profile=trekking-ignore-cr
It routes along Uitdammerdijk. It is frustrating that, only when I cycle there, do I see that the path is blocked.
