Improve bicycle routing on footways

[ratrun]

As a result of a discussion on the mailing list the following items should be checked and improved:

• Maybe we should increase the preference also in case of presence of the tag bicycle=yes. Currently this is done only for bicycle=designated
• The speed values with a present surface tag needs to be decreased for footways.
• highway=path and highway=footway should be treated the same way.
• Eventually we also could increase the assumed speed for footway from rather conservative 6km/h to 8km/h, but I would not like to increase this speed further because I fear that this would have noteable negative effects in big cities.
• We should influnce the assumed speed values based on the width tag: E.g. a 3 meters wide footway we could assume speed 16km/h, and fall back to the default value for a width<1.5 meters.

[karussell]

Maybe we should increase the preference also in case of
presence of the tag bicycle=yes. Currently this is done only for bicycle=designated

You mean for footpath? Then maybe, yes.

The speed values with a present surface tag needs to be decreased for footways.

What do you mean here?

highway=path and highway=footway should be treated the same way.

okay

Eventually we also could increase the assumed speed for footway from rather conservative 6km/h to 8km/h, but I would not like to increase this speed further
because I fear that this would have noteable negative effects in big cities.

We should avoid that.

E.g. a 3 meters wide footway we could assume speed 16km/h, and fall back to the default value for a width<1.5 meters.

Hmmh, but often if the path is big there is also a high frequency of pedestrians. If it is a footway, it is a footway :). Only if bicycle=yes or designated is tagged we should think about improving preference for bike or even increasing speed.

[ratrun]

Thank you. So I'll prepare a patch covering the following:

Change preference for bicycle=yes as we already do for bicycle=designated

The speed values with a present surface tag needs to be decreased for footways.

Currently a highway=footway is assumed to have speed 6km/h. In case that a tag surface=paved is set for a footway, the speed boosts to 18km/h, which is sub-optimal. The reason is because the code for the suface tag assumes highway track at least.

Additionally I'll try to handle highway=path and highway=footway pretty much the same for the common bike profile with an exception for mountainbike.

I won't add any change for evaluating the width tag.

[karussell]

is set for a footway, the speed boosts to 18km/h, which is sub-optimal.

Oh, that is not good. Important to fix & ensure via test.

The reason is because the code for the suface tag assumes highway=track at least.

So it only increases speed for highway=track and not for highway=footway?

Additionally I'll try to handle highway=path and highway=footway pretty much the same for the common bike profile

Why? 18km/h for path is indeed to high but only 6km/h?

[ratrun]

It is much easier to discuss code. The following tests currently pass. I plan to change the things marked with FIXME

    // Pushing section !! This is fine we obey the law!
    way.clearTags();
    way.setTag("highway", "footway");
    assertEquals(4, encoder.getSpeed(way));
    assertPriority(AVOID_IF_POSSIBLE.getValue(), way);

    // Pushing section irrespective of the pavement: This is fine!
    way.setTag("surface", "paved");
    assertEquals(4, encoder.getSpeed(way));
    assertPriority(AVOID_IF_POSSIBLE.getValue(), way);

    // No pushing section: OK. Low 6km/h speed also OK. 
    // FIXME wrong low priority --> Change it to at least UNCHANGED or even PREFER ?
    way.clearTags();
    way.setTag("highway", "footway");
    way.setTag("bicycle", "yes");        
    assertEquals(6, encoder.getSpeed(way));
    assertPriority(AVOID_IF_POSSIBLE.getValue(), way);

    // No pushing section: OK. See above: FIXME wrong low priority --> Change it! 
    // And FIXME: Boost in speed, here the speed should be lower
    way.clearTags();
    way.setTag("highway", "footway");
    way.setTag("surface", "paved");
    way.setTag("bicycle", "yes");
    assertEquals(18, encoder.getSpeed(way));
    assertPriority(AVOID_IF_POSSIBLE.getValue(), way);

If I understood you right you don't like to treat highway=footway and highway=path the same way. I fully agree for the mountainbike profile. But why do you declare paths to be so much faster? Just because we might assume that these are probably located in rural areas and consequently we assume that bikes won't need to slow down frequently because of lots of pedestrians?
Here is this test:

    // See above: FIXME wrong low priority --> Change it! 
    // FIXME: Here the speed difference compared to footway is a bit too big 
    // compared to highway=footway result with 6km/h:
    way.clearTags();
    way.setTag("highway", "path");
    way.setTag("bicycle", "yes");        
    assertEquals(18, encoder.getSpeed(way));
    assertPriority(AVOID_IF_POSSIBLE.getValue(), way);

[karussell]

FIXME wrong low priority --> Change it to at least UNCHANGED or even PREFER ?

ok, UNCHANGED should be fine here. Only because bike is okay we should not prefer it (except for designated).

And FIXME: Boost in speed, here the speed should be lower

ouch ;) nice catch !!

But why do you declare paths to be so much faster?

as I said 18km/h is too high and also priority should be better indeed! (maybe also unchanged)

[ratrun]

Closed

[karussell]

All other things are fixed via #421?

[ratrun]

Sorry I don't understand. What do you mean by "all"? The merged patch contained the modifications for which you agreed, so there is no width handling included.

[karussell]

With all I meant: there were several things marked with FIXME

[ratrun]

Those marked with FIXME are fixed.