I have graphhopper locally installed and running using a pbf from geofabrik.de, with the default config.properties. Searching the following route locally at localhost:8989 returns completely different results than the exact same query to the demo map at graphhopper.com/maps:
source: 43.6516,-70.28188
destination: 43.7073,-70.2893
My local results are not the correct route I would take (its basically a straight line), but the result on graphhopper.com/maps is the correct, longer route.
What can I configure differently so that my local installation will return the correct route that the demo map on graphhopper.com does?
Here is the correct result graphhopper.com/maps returns:
And here is the local result I get for the exact same query:
It feels like the shortest route is calculated instead of fastest. To check this you can look at the log that local server writes into console and find more info about each request. There should be parameter weighting=fastest to get the same path as on graphhopper.com/maps.
weighting=fastest can’t be the cause of the issue. The query url for both localhost:8989 and graphhopper.com/maps are both identical and already include weighting=fastest. Here is the the url used for both:
?point=43.6516%2C-70.28188&point=43.7073%2C-70.2893&locale=en-US&vehicle=car&weighting=fastest&elevation=false&use_miles=false&layer=Omniscale
Hi @ronaldjeremy,
the travel time that your local returns for the almost-straight-line route (7 minutes) looks incorrect.
I add an intermediate point (43.661271,-70.284026) on graphhopper.com/maps to force it to take the almost-straight-line route and the travel time is 14 minutes.
https://graphhopper.com/maps/?point=43.6516%2C-70.28188&point=43.661271%2C-70.284026&point=43.7073%2C-70.2893&locale=en-US&vehicle=car&weighting=fastest&elevation=false&use_miles=false&layer=Omniscale
Best regards,
He
Thank you @jie31best, I agree it looks incorrect, but how do I correct it? My local graphhopper install and configuration is about as clean as you can get.
Can you or anyone here try a plain vanilla install of graphhopper, load a planet.pbf, and try the query to see if the local result you get is also incorrect? That would at least be a starting point to rule out something on my end.
We improved the ETA data with some other data, see Improved Feature: Better ETA values
To emulate similar behavior without data is to detect inner city better with various signals from OSM tags and decrease the speed appropriate
@karussell, can you give more details as to how I can configure graphhopper to “detect inner city better with various signals from OSM tags” so that the route given by localhost is correct?
I cannot give you any details as we use a different data set to detect this, but you could use street lamps or maxspeed tags or landusage.
Same here. Did you find the method that the ETA is enhanced easily?
I tried to modify some factors in https://github.com/graphhopper/graphhopper/blob/master/core/src/main/java/com/graphhopper/routing/util/CarFlagEncoder.java . But unfortunately it’s useless.
For example,
`
public CarFlagEncoder() {
this(5, 2, 0); // Changed from (5,5,0)
}
// linking bigger town
defaultSpeedMap.put(“primary”, 40); // from 65
defaultSpeedMap.put(“primary_link”, 40); // from 60
`
Could anybody give me some hints to solve it?
