We recently upgraded from GH 7 to GH 9.1 in our Java project and I stumbled upon a car routing anomaly.
Tl;DR: Our GH7 setup essentially behaves like your hosted instance, while our GH9.1 setup produces problematic car routes on a particular group of OD relations, even though I tried to closely follow the available migration guides. Can you help me understand what I am observing and help me in fixing this probably incorrect behaviour?
Now in more detail.
Basic OD - Relation near Greifswald, Germany:
- Start: 54.044958,13.406233
- Goal: 54.091079,13.432414
Routing this on your hosted GH instance (which I assume runs a relatively recent version) returns this:
This is reasonable.
In our local setup with GH 7 I get the following (relevant config section under graphhopper key below), which looks essentially the same:
Config:
profiles:
- name: car
vehicle: car
weighting: fastest
turn_costs: true
profiles_ch:
- profile: car
prepare.min_network_size: 200
##### Network Details #####
graph.flag_encoders: car|turn_costs=true
##### Path Details ######
graph.encoded_values: surface
##### Storage #####
import.osm.ignored_highways: footway,cycleway,path,pedestrian,steps
graph.dataaccess: RAM_STORE
Now on GH 9.1 we get this (again config under graphhopper key below), which is problematic:
Config:
profiles:
- name: car
turn_costs:
vehicle_types: [ motorcar, motor_vehicle ]
u_turn_costs: 60
custom_model_files: [ car.json ]
profiles_ch:
- profile: car
prepare.min_network_size: 200
##### Encoded Values ######
graph.encoded_values: surface, car_access, car_average_speed
##### Storage #####
import.osm.ignored_highways: footway,cycleway,path,pedestrian,steps
graph.dataaccess: RAM_STORE
where car.json references the built-in custom model, namely
{
"distance_influence": 90,
"priority": [
{ "if": "!car_access", "multiply_by": "0" }
],
"speed": [
{ "if": "true", "limit_to": "car_average_speed" }
]
}
There are two issues with the new route.
- it is generally illegal, since the straight vertical section with the bridge crossing the B109 is only accessible to bikes and pedestrians. GH cannot do much about this, because the underlying OSM data simply misses the necessary annotations/barriers /tags, whatever …
- the straight stretch contains a relatively long section of a grade 2 gravel road, which is accurately mapped in the underlying OSM data. It is possible to force your hosted version to consider the illegal section by moving the start and goal markers very close to it.
These observations together suggest that your hosted GH instance and our GH 9.1 setup end up with noticeably different weights for the questionable route, in particular that your setup penalises the route (and in particular probably the grade 2 track) much more than we do (with presumably your defaults?), I had assumed that average_car_speed would be set appropriately based on highway grade without having to manually adjust for those.
Have we misconfigured anything on our end? I wanted to use the default upstream vehicle configurations unless I have a good reason to override them. I know how to run my own custom model, but before I start messing with the parameters I was wondering if I already took a wrong turn somewhere.
Just to be clear, I don’t really care about the problem with the inaccessibility that OSM doesn’t know about, but the fact that the gravel road appears too attractive in our GH9.1 setup.
For what its worth, google maps does not consider the illegal road at all as an option, as far as I could determine