Bike routing should avoid motorways, primary roads or roads with designated hgv access even if only parallel to them

[nemobis]

Same issue as #597 , please see for my test case.

30 km/h zones and speed limits are increasingly used to create ways that, while still allowed for motor vehicles and mixed usage, are recommended for bicycles:

• http://www.ecf.com/advocary/mobility/traffic-calming30-kh/
• http://www.copenhagenize.com/2010/01/30-kmh-zones-work.html
  A 15 km/h limit is more extreme and can be taken as a strong indication of a road being practically forbidden to cars, almost equivalent to a cycleway. (An even lower limit on an extended way would practically be like a pedestrian area, I guess; I'm not sure if that's in use.)

To the contrary, roads which lead to motorway junctions may theoretically have a 50 km/h speed limit, but, when the limit becomes (or was) 90 km/h at a few meters distance, drivers are unlikely to respect the lower limit.

Concretely, I think that in addition to setAvoidSpeedLimit()

graphhopper/core/src/main/java/com/graphhopper/routing/util/BikeCommonFlagEncoder.java

Line 201 in fed0354

setAvoidSpeedLimit(71);

there should be:

• a setPreferSpeedLimit() set at 15 for bike and MTB, perhaps 30 for racing bikes, so that via Idro in the example is chosen over normal roads (as long as the surface or type is reasonable);
• a setting to also avoid or discourage getting 50-100 m far or closer from a way whose speed limit is above the avoided one; or alternatively, to discourage going over ways which in 50-100 more meters turn into highway=motorway_junction, highway=primary, highway=motorway, highway=motorway_link or similar.

[ratrun]

First we need to fix the discovered maxspeed car specific code problems in #597, then we can have a look if further perference of low maxspeed limits is needed and usefull.

[nemobis]

Sure, thank you.

[karussell]

@ratrun is this here fixed due to your fix in #600 or will it need further changes?

[ratrun]

#600 is only one of three changes.

A second change is necessary to boost the influence of the internally assigned preference.

A third and most complex change is needed for this:

a setting to also avoid or discourage getting 50-100 m far or closer from a way whose speed limit is above the avoided one; or alternatively, to discourage going over ways which in 50-100 more meters turn into highway=motorway_junction, highway=primary, highway=motorway, highway=motorway_link or similar.

I already thought about that when the map-matching came out. What do you think about the following crazy idea:

We try to map-match every edge against another graphhopper instance for trucks (= another flag encoder). In case that a good match is found, we significantly decrease the preference for that edge.

[karussell]

We try to map-match every edge against another graphhopper instance for trucks (= another flag encoder). In case that a good match is found, we significantly decrease the preference for that edge

Preprocessing could increase the quality indeed but this does not belong to the core. We could create a new module which does certain kinds of time and resource consuming preprocessing. Also I don't think map matching is necessary here as we already have the internal edge IDs and can find out if it is a highway or converts soon into a highway. But still this would require preprocessing which we have to introduce at some point but probably as separate module.

[ratrun]

Performing of this task in a dedicated preprocessing step seems to be a good approach. Perfomance wise the good thing is that we probably don't need to run this for every edge. It should be sufficient for edges, which come from ways which are tagged with highway=cycleway, highway=track, highway=path, highway=footway. I don't think that it needs to be done for the "higher" classified road types such as highway=residential, highway=unclassified ..
The result the preprocessing could be a file, which gets read during graph creation, similar to what you did in the traffic data integration example.

Also I don't think map matching is necessary here as we already have the internal edge IDs and can find out if it is a highway or converts soon into a highway.

This I don't understand. The solution must work also in case that the cycleway edge does not have a close direct connection to the other edge, which is good for trucks. I'm thinking about a cycleway which runs in parallel to a primary road (or a motorway) for a longer distance. I don't understand how you could know the edge ID of the close parallel primary without a process similar to map matching.

[karussell]

I don't understand how you could know the edge ID of the close parallel primary without a process similar to map matching.

That is indeed a good example I didn't thought about. But e.g. via traversing the graph and finding close edges like we do in LocationIndexTree it is still possible without map matching which is rather resource intense.

[karussell]

It should be sufficient for edges,

That is indeed true and would reduce the preprocessing significantly. But as I don't think that these 'optimizations' are unique for the bike encoder we should create a framework first to do such things easier for all vehicles and then implement simple improvements there.

The result the preprocessing could be a file, which gets read during graph creation, similar to what you did in the traffic data integration example.

But then you would need to update this file and even smaller areas would read the world wide one? I do not think this is the best approach. I would like to keep the core really separated and instead introduce an algorithmic preprocessing which improves speed values, priorities and the like for other encoders too.

[ratrun]

This issue should be better closed and a new one created instead. The new one should continue the idea of calculating the route for a "truck"/"car" vehicle and down-prioritising those segments in case that the truck segments run close and "parallel" to the bicycle segment.

[karussell]

I tried to find a real world example where this would improve the bike routing but I failed to find one. For now I'm closing here as suggested by @ratrun.