Weight and Time when using GraphHopperOSM

[htmoia]

Hello!
first of all: thank you for this incredible project!

I am struggeling with understanding the Java-Client for routing. When using the GH Rest-API I receive different values for time and weight compared to my local setup.
The propossed time and weight of the (best) path is always lower compared to the routes produced by the GH Rest-API.
Here my cut-down code:

GraphHopper hopper = new GraphHopperOSM().forServer();
hopper.setGraphHopperLocation("andorra");
// downloaded from https://download.geofabrik.de/europe/andorra-latest.osm.pbf
hopper.setDataReaderFile("andorra/andorra-latest.osm.pbf");
hopper.setEncodingManager(EncodingManager.create("car"));
hopper.importOrLoad();

GHRequest ghRequest =
    new GHRequest(42.504482, 1.522286, 42.51295, 1.531134)
        .setWeighting("fastest")
        .setVehicle("car")
        .setLocale(Locale.GERMAN);
GHResponse route = hopper.route(ghRequest);
System.out.println("time: " + route.getBest().getTime());
System.out.println("weight: " + route.getBest().getRouteWeight());
// produces
// time: 180352
// weight: 180.3628508546962

// using GH API
// curl
// https://graphhopper.com/api/1/route?point=42.504482,1.522286&weighting=fastest&point=42.51295,1.531134&vehicle=car&locale=de&key=API_KEY
// produces
// time:198905
// weight:224.663948

I also tried to disable CH and use “shortest” weighting but this does not change the result much.

Can someone help with my setup?

[htmoia]

Especially when computing shorter routes (around 2km) the route-time computed by GraphHopperOSM is much shorter than the one returned by the GH Rest-API.
Another example:

From: 50.147426,11.071129
To: 50.13936,11.058769

The GH Rest-API returns 234934 millis whereas
GraphHopperOSM only returns 141829 millis

Is this an issue with my setup or could this be due to the downloaded pbf file (from Geofabrik)?

[karussell]

See Difference between open source car and graphhopper maps car for the explanation of this difference.

[htmoia]

Ok, that makes sense. Thanks for your reply!

[easbar]

One more thing you could do after trying the “fastest” and the “shortest” weighting is using the “short_fastest” weighting. It takes into account both the travel time and the distance of the route. There are parameters that control the contribution of time and distance to the overall weight: short_fastest.time_factor and short_fastest.distance_factor (but it only makes sense to change one of them unless you are interested in the absolute value of the weight). You can see the formula in ShortFastestWeighting.java.

[htmoia]

I’ll try that, thanks!