Huge penalty for pedestrian highways in trekking profile

[Phyks]

trafficstars

Hi,

I was investigating this strange route provided by BRouter, making two crossings when one could simply follow the edge of the pedestrian area:

http://brouter.de/brouter-web/#map=19/48.81870/2.31914/standard&lonlats=2.319454,48.81857|2.319835,48.818984

It seems that highway=pedestrian (with bicycle=yes) is resulting in a much higher penalty than highway=footway (without any bicycle indication!). From the OSM wiki, my understanding is that a highway=footway without any bicycle indication should imply walking alongside your bike, whereas a highway=pedestrian with bicycle=yes is explicitly allowed for bikes. I would therefore tend to prefer the first one.

This seems to be coming from https://github.com/abrensch/brouter/blob/master/misc/profiles2/trekking.brf#L203-L222 and a footway is basically considered the same as a cycleway in terms of penalty apparently as long as it is paved.

For more background on this configuration here, the pedestrian area is indeed a pedestrian square in reality and in France they are legally authorized to bicycles as long as they do not excess walking speed (this should be reflected with the bicycle=yes tag, and their could / should be an extra maxspeed tag). The footways here on the other hand are sidewalks and are definitely not authorized to bikes.

Thanks,

[abrensch]

Hi Lucas,

I agree with your analysis. However, it should be fixed in the access-logic, niot in the highway penalties. If the bike-"defaultaccess" for footway would be false, then the fallback to footaccess with walking speed would work.

But I do not have the test-methodology to fiddle with the trekking-profile anymore, and I do not enough biking myself anymore, So there's not much I can do. Except accepting something else as a new standard-slow-bike profile if there's an international consensus...

regards, Arndt

[Phyks]

However, it should be fixed in the access-logic, niot in the highway penalties. If the bike-"defaultaccess" for footway would be false, then the fallback to footaccess with walking speed would work.

Indeed, thanks for the feedback!

But I do not have the test-methodology to fiddle with the trekking-profile anymore

I added this case to my sort of test suite for BRouter bicycle profiles (https://github.com/Phyks/BrouterTesting). I'd like to clean and rework #123 and #136 to write an improved and mergeable trekking profile (fixing such cases, while retaining the main features from the trekking profile).

[quaelnix]

From the OSM wiki, my understanding is that a highway=footway without any bicycle indication should imply walking alongside your bike, whereas a highway=pedestrian with bicycle=yes is explicitly allowed for bikes. I would therefore tend to prefer the first one.

Yes, but you also have to keep in mind that there are many highway=pedestrian ways where you are in fact allowed to ride a bicycle, although bicycle=yes is missing in OSM, and that there are many highway=pedestrian ways where it is not possible to drive much faster than walking speed, although you are allowed to ride a bicycle.

I'm pretty sure that lowering the costfactor of highway=pedestrian would do more harm than good.

[rkflx]

@quaelnix

So basically you are saying that in practice both highway=pedestrian and highway=footway might result in having to cycle slowly or to push the bike, as if one was an alias for the other¹.

Does this not imply the same² cost factor should get assigned to both scenarios? Then the shorter route (and with less crossings) along the pedestrian area in the test case would be taken as it should be, instead of the detour.

I'd say we still want what is requested here (i.e. no detour). How to get there without breaking other routes is another question, of course.

---

¹) probably not universally true, though ²) or nearly the same, to account for footways inside pedestrian areas

[quaelnix]

Does this not imply the same² cost factor should get assigned to both scenarios?

This mainly implies that highway=pedestrian; bicycle=yes should not be any cheaper than highway=footway.

I'd say we still want what is requested here (i.e. no detour).

Yes, but I would propose to accomplish this by adding a properly tuned penalty for highway=crossing and not by reducing the penalty for highway=pedestrian, as the penalty for highway=pedestrian seems to be well tuned.

Then the shorter route (and with less crossings) along the pedestrian area in the test case would be taken

Basically it is always possible to find an example where a profile fails, but in this case the real question is whether reducing the penalty for highway=pedestrian or highway=pedestrian; bicycle=yes improves the route quality of all possible route requests on average (or if it at least significantly lowers the proportion of route artefacts, like the one in above example).

[quaelnix]

@rkflx, replacing: https://github.com/abrensch/brouter/blob/38fc780055e789ee1beb85b5e4439be7a38d8adc/misc/profiles2/trekking.brf#L289 both with:

if      ( highway=pedestrian                ) then ( if bicycle=yes then 1.5 else 3 )

and

if      ( highway=pedestrian                ) then ( if bicycle=yes then 1.0 else 3 )

did not improve the average route quality in my tests, but maybe my tests were biased?

---

We should probably collect all the good ideas from closed problems (like this one) and pull requests (like: https://github.com/abrensch/brouter/pull/123, https://github.com/abrensch/brouter/pull/58, ...) somewhere and then discuss possible ways to implement them cleanly.

[rkflx]

@quaelnix

did not improve the average route quality in my tests, but maybe my tests were biased?

That's hard to comment on, since I do not know how you measured "average route quality" and what routes you chose to test. If nothing regressed, that's good, but did it also fix the issue at hand? (I tried to quickly find a similar test case based on current OSM data, but failed.)

reducing the penalty for highway=pedestrian

You might be reading too much into the title. Would you also close this issue as "not planned" if the title started with "Detour around" instead of "Huge penalty for"?

IMO it would be easier to just reopen this issue and change the title to better reflect the actual problem as experienced by a cyclist instead of assuming a yet-to-be-confirmed root cause or solution (i.e. nothing about pedestrian or crossing penalties).

We should probably collect all the good ideas from closed problems

Reopening seems less work and might cause less confusion than closing issues and then "collecting" them again in a different place. If you want to get fancy, apply labels and use tracker issues to link to individual issues. Issues are for recording problems – GH Kanban boards could be added for planning purposes and GH discussions for other talk and support.

Regarding the PRs you linked (if you actually plan to support authors in getting their changes reviewed and merged), my advice would be to not close them and instead ask to rebase on master and, if applicable, split the changes into one PR per problem for easier discussion. If an author lost interest (understandable if a PR did not get merged for years and then was simply closed without even consulting with them beforehand), it might make sense to open a new issue referencing the existing PR. I currently don't have resources to help with any of that, but I also was not the one who closed anything.

That being said, any profile change is inherently risky at this point. As mentioned above, investing time into better automated testing would be immensely helpful, if you have the means to do so (sadly I don't currently). Ideally we'd have a set of test cases per profile to specify characteristic properties, with more added over time for any later additions or fixes to prevent regressions.

---

it should be fixed in the access-logic

Did you try to look into that?

In addition, it might be interesting to create a table to compare costs between fixed-length segments for each combination of highway=pedestrian|footway and bicycle=yes|undefined|no and check if it matches with what would be expected intuitively in reality.

(Creating such a set of cost invariants and automatically validating profiles against them could be an additional approach for systematic testing, BTW.)

[quaelnix]

I do not know how you measured "average route quality" and what routes you chose to test.

I chose more or less random start and end points near highway=pedestrian segments in areas I've been to before, and then varied both the start and end points and the weights of the highway=pedestrian penalty logic until I got a good idea of what decisions the trekking profile was making. That's basically my standard procedure of how I try to optimize weights in profiles.

I tried to quickly find a similar test case based on current OSM data, but failed.

It took me 20 minutes to find an example (I guess that alone already says a lot about how side effect free a good a bugfix needs to be in order to improve the "average route quality"): http://brouter.de/brouter-web/#map=19/49.49642/8.47176/standard&lonlats=8.472339,49.497005;8.471783,49.496005

Would you also close this issue as "not planned" if the title started with "Detour around" instead of "Huge penalty for"?

Yes, because I genuinly believe that a proper fix for the "detour around" issue" does not involve modifying the penalty for highway=pedestrian.

if you actually plan to support authors in getting their changes reviewed and merged

I'm all for it, as long as we test things thoroughly before we even think about merging them.

That being said, any profile change is inherently risky at this point.

Yes, but I do believe there is some room for improvement in the default profiles.

Ideally we'd have a set of test cases per profile to specify characteristic properties, with more added over time for any later additions or fixes to prevent regressions.

Yes, but to be honest, I have my doubts whether it is even possible with reasonable effort to define test cases that fully characterize a profile. Plus the fact that we don't know who is currently using these profiles for which purpose.

[quaelnix]

Reopening seems less work and might cause less confusion than closing issues and then "collecting" them again in a different place.

Fair enough.

[rkflx]

http://brouter.de/brouter-web/#map=19/49.49642/8.47176/standard&lonlats=8.472339,49.497005;8.471783,49.496005

AFAICS for the most part that's bicycle=designated, segregated=yes and highway=path, i.e. not really comparable with "highway=footway (without any bicycle indication!)" as mentioned in the description.

[quaelnix]

Right, but the symptoms are the same and reducing the penalty for highway=pededstrian; bicycle=yes would fix it:

if      ( highway=pedestrian                ) then ( if bicycle=yes then 1.0 else 3 )

Here is another imperfect example: https://brouter.de/brouter-web/#map=19/50.93515/6.95932/... which is quite similar to the original example if you assume that the highway=pedestrian area is bicycle=yes.

---

Adding the following at line 400 would solve both issues and would presumably also have fixed the original issue:

add switch highway=crossing 60 0