Support paths with segregated cycleways

[flyingOwl]

For a better bicycle routing, I would like to distinguish between "bad" paths that are also used by pedestrians and "good" paths, that have separate lanes.

A bad path might have the following tags:

highway=path
bicycle=designated
foot=designated
lit=no
segregated=no

See: https://www.openstreetmap.org/way/791351847

A good path might have the following tags:

highway=path
bicycle=designated
foot=designated
segregated=yes
oneway:bicycle=yes
sidewalk:surface=paving_stones
cycleway:surface=asphalt
traffic_sign=DE:237

See: https://www.openstreetmap.org/way/894661677

Currently they both translate to the following tags in brouter (at least that's what the brouter-web display in the table):

highway=path
foot=designated
bicycle=designated

They only differ in oneway:bicycle=yes, which is only relevant for avoiding one-way streets.

There are already a lot of paths which use segregated, for example in Berlin: https://overpass-turbo.eu/s/155l

It would be great if brouter would support this tag for routing (profiles). Having the surface tags available would also be nice :smiley:

[mjaschen]

I recently had to deal with a similar problem (still unsolved for me).

A road[1] with very poor pavement has a lane for bicycles on one side, which is well passable even with thin tires. The “fastbike” profiles all route around the way, partly with very large detours[2], although the parameters are in themselves quite suitable:

cycleway:right:smoothness=good
cycleway:right:surface=paving_stones
cycleway:right=lane
highway=residential
maxspeed=30
name=Hauptstraße
smoothness=bad
surface=sett

I verified the tagging and it seems to comply with DE:Key:cycleway.

I think for fixing this one would have to change BRouter's lookups.dat, but I have not found any documentation for this.

[1] https://www.openstreetmap.org/way/342143217#map=17/52.26256/13.60512 [2] https://brouter.m11n.de/#map=14/52.2594/13.6067/standard&lonlats=13.60322,52.257307;13.602577,52.269813&profile=fastbike

[polyscias]

For the current list of supported tags, see https://github.com/abrensch/brouter/blob/master/misc/profiles2/lookups.dat

surface is supported, but the default Trekking profile does not use it. Look for an alternative profile like one from https://github.com/poutnikl/Brouter-profiles/wiki

The segregated key is supported but also that is not used in the default Trekking profile, you could try adding it yourself.

[flyingOwl]

Oh damn it!

I thought, the "WayTags" on brouter-web are a complete list of all available tags. I added some ifs to check for "segregated" ways to my routing profile and it worked and showed up in the WayTags list.

Thanks for the lookups.dat @polyscias!

Closing issue because support is already there!

[nrenner]

I thought, the "WayTags" on brouter-web are a complete list of all available tags.

By default, only tags used in the profile are shown, setting the profile option processUnusedTags=true shows all, e.g. in trekking.brf.

[laem]

I must admit that I don't understand why this instance returns all the tags, including segregated, whereas the official one does not.

[nrenner]

It seems like the other instance has the above mentioned processUnusedTags flag active by default for some reason.

[mjaschen]

processUnusedTags flag active by default for some reason.

The track analysis is incomplete in many cases if processUnusedTags isn't enabled. Enabling that flag for all profiles is the easiest workaround.

[poutnikl]

processUnusedTags flag active by default for some reason.

The track analysis is incomplete in many cases if processUnusedTags isn't enabled. Enabling that flag for all profiles is the easiest workaround.

I assume you mean it in context of webclient - server backend. For android client - Brouter app backend it would lead to slowing down routing.

[mjaschen]

I assume you mean it in context of webclient - server backend.

Yes, of course. Sorry for not mentioning this.