Differences in Route Generation Between Graphhopper Maps and Graphhopper Version 10 Installed on My Server

Hi, I am trying to understand the differences between the routes created on Graphhopper Maps

and those created by my Graphhopper service on my server, using the same payload in a POST request: { “points”: [ [ 9.372003, 45.536676 ], [ 9.104767781911379, 45.198305038675926 ] ], “profile”: “my_car”, “elevation”: true, “instructions”: true, “locale”: “it”, “points_encoded”: true, “points_encoded_multiplier”: 1000000, “details”: [ “road_class”, “road_environment”, “road_access”, “surface”, “max_speed”, “average_speed”, “toll”, “track_type”, “country” ] }

The response I get from my server presents a route choice that is almost always nonsensical, avoiding fast roads and generally taking much longer.

Why is there this difference? Perhaps the configuration I have adopted is not correct?

The only way to get better routes is to use a custom model like this:

“custom_model”: {
“distance_influence”: 15,
“priority”: [
{
“if”: “!car_access”,
“multiply_by”: “0”
}
],
“speed”: [
{
“if”: “road_class == UNCLASSIFIED”,
“multiply_by”: “0.4”
},
{
“if”: “road_class == RESIDENTIAL”,
“multiply_by”: “0.4”
},
{
“if”: “road_class == SECONDARY”,
“multiply_by”: “0.6”
},
{
“if”: “road_class == PRIMARY”,
“multiply_by”: “0.7”
},
{
“if”: “road_class == TERTIARY”,
“multiply_by”: “0.5”
},
{
“else”: “”,
“limit_to”: “car_average_speed”
}
]
}

However, doing this results in much longer response times, sometimes 30-40 seconds per request if the route is fairly long. How can I pre-generate the data so that I don’t have to use a custom model in the payload? Is it possible? Thank you in advance for any suggestion

Can you show your configuration?

I have tried different configurations, but the result does not change. I have tried both this one:
config-car-foot.txt (12.9 KB)

and this one
config-car-foot-custom.txt (12.9 KB)
, in which I inserted the custom model in the file /core/src/main/resources/com/graphhopper/custom_models/my_car.json
my-car.json (544 Bytes)

Did you try config-example.yml that comes with the release? Do you observe unexpected routes using it? And if no which changes did you make so you get the unexpected routes? Sorry I don’t feel like downloading three files and trying to figure out what you did.

@Andrea_Francesco_Can

I too have noticed that for some reason, the main graphhopper web server is not acting the same as 9.1, 10.0, or from master. Please see here:

@easbar Really appreciate your help here. Any chance you can tell us what version of of graphhopper and what file data file the main graphhopper server uses as when you query /info it does not work?

Please understand i do NOT want to try to write my own routing engine, because it would suck!! You are all doing great, but how can i debug this if i don’t know what version of graphhopper you use, and what feeds your data “osm”?

I would have no problem paying the 165 clams a month to graphhopper, but in here in the United States, your data (maybe OSM?) causes "please lookup “can opener bridge” on youtube when i set custom models to:


{“if”: “max_width < 2.6 || max_height < 4.2”, multiply_by": “0”…

just saying boss gets mad when his trucks get shredded… (see youtube above)

i can’t (difficult) debug this if i don’t know what version of graphhopper, or where you get your data…

ps. i am also working with US OSM to try to fix this, but…

@floormat For graphhopper.com we use the latest master branch most of the time. However, it is not the exact same as the open source engine (for various reasons that have been mentioned very often in this forum). Regarding the OSM data we usually use a very recent version of the planet file. We also offer routing with TomTom data. Your snapping issue might be related to the size of the map. I’ll have a look at this today. If you need us to modify the routing for you please do not hesitate to contact support@graphhopper.com

Regarding can opener bridge: it is tagged as maxheight 12’4" (=3.76m). Do you think it is lower than that? How high are your trucks (or common trucks in this area)?

@easbar

Thank you for the information!

There are two problems i was having. I should have been more clear.

First problem: Overpass heights, etc. (OSM data problem, NOT GrapHopper problem)

As for the bridge, here is good example. (This is a problem with the OSM, not graphhopper, as when i click on the OSM data here, it simply shows no restriction).

This overpass is actually labeled 13’9" in the KS bridge restriction map here:
https://www.ksdot.gov/Assets/wwwksdotorg/bureaus/burStructGeotech/pdfs/ksbridgerestrictionmap.pdf

and you can see there here too:

The route should force truck back onto highway to next overpass, then turn around, use offramp, etc… this is normal in the States.

As a side note, it WAS labeled 14’ at one time on the PDF, but in the MidWest here, asphalt roads when they get paved over (re-surfaced), they “grow” sometimes, so some signs will be 3 inches lower LOL

Again, this is NOT GraphHopper’s fault, as if you look at the data, the restriction is not there?

I am in contact with the US chapter of OSM, and there are couple of groups of people that are trying to get that data into the map, but each state can have different laws, etc. (They have been arguing in the groups on how to import each State’s restrictions, as some are PDFs, some are in Excel, etc. (I can send link to a group that tried to do it for one state Kentucky, but it was a mess)

Thank you for letting me know about the TomTom data, i will have to go read up on that and see if they have the correct data including weight limits, etc? (I’m just so impressed with OSM data in Europe as they even have trees marked at intersections sometimes!)

Second problem:

The “snapto” problem. You can see my previous post. The online version seems to be better about not snapping large distances shown in the previous post where the latest from master will snap past a “block” here and put them on a dirt road even though dirt road should be avoided as i use “surface == dirt”, multiply by zero. This works great on the online, but not local in the examples i give.

I just assumed in the beginning that the new snapto setting config.yml was the problem as it was a new feature in 10, but i was wrong. (Because the problem exists on 9.1 local too).

If you give me a hint about where in the code the distance “allowed” for the snapto is, i will just mess with it myself and fix it to the length i want. (I been meaning to load it up IntelliJ and start debugging, but just haven’t had the time just yet)

I hope that makes sense.

Thanks for letting me know about the TomTom data. If that data is correct, i will just use your server. I need to go read up on it and run some tests.

Again, just want to say GraphHopper is great, thanks for all your help.

This is caused by a random private road nearby the requested coordinate and the fact that private roads are open in the online version. The actual snapping algorithm is the same. See the other thread linked above.

There is no fixed distance, but the edges are traversed (more or less) by ascending distance from the query coordinate until a valid edge is found. Take a look at the lookup function in ViaRouting.java.

That’s great work is done to improve OSM. Also keep in mind GraphHopper is not necessarily restricted to only use OSM. If you know of higher quality bridge-height data for example it might still be interesting to integrate it into GraphHopper directly. Even though improving OSM is the even better solution in the long, run of course.

Thanks!

I will go look at the code. I appreciate you giving the hint so i don’t have to spend so long in debug mode LOL

I replied in other thread to, which you gave me some great options to try. Thank you.

In the long wrong, OSM for the States is difficult because of all the different state options, and everyone keeps failing updating OSM because they are trying to write one program to import data from 50 different states that have 50 different ways of doing it.

Thanks for all the help!