Different settings for commercial Directions API compared to open soure version?

[Nakaner_Geofabrik]

Dear GraphHopper team,

I am currently investigating a complaint by one of our clients that the car routing in fastest mode prefers minor roads to much. It’s about this route:

https://graphhopper.com/maps/?point=48.820358%2C9.1747&point=48.807224%2C9.176749&locale=de-DE&vehicle=car&weighting=fastest&elevation=false&use_miles=false&layer=OpenStreetMap

The commercial GraphHopper Directions API returns a route via the so-called “Pragsattel”. That’s what I would expect from a “fastest” car route. However, my self-hosted v0.12 and v0.13.0-pre12 instance return the same route as the shortest weighting. The shortest route runs through the grounds of a car dealer (“Autohaus von der Weppen”, https://www.openstreetmap.org/way/685729687).

http://localhost:8989/maps/?point=48.820358%2C9.1747&point=48.807224%2C9.176749&locale=de-DE&vehicle=car&weighting=fastest&elevation=false&use_miles=false&layer=OpenStreetMap

If I force my own GraphHopper 0.12/0.13 with “fastest” weighting to route via Pragsattel, it returns a 6 seconds longer travel time. That is no surprise because all roads except the service road through “Autohaus von der Weppen” have maxspeed=50. And highway=service defaults to 20 kph in the GraphHopper source code.

Note: I am using the Baden-Württemberg OSM extract of my company from yesterday evening. According to the /info call, the commercial API uses data from 1 July 2019.

Does the commercial API run something different than a pre-release v0.13 (the /info API call says it runs 0.13)?

Does it have a modified CarFlagEncoder excluding highway=service + service=drive_through?

Or are there any other settings (I presume you are treating all barriers as passable by default) which could have an influence on routing results?

My configuration file for v0.12:

graphhopper:
  graph.flag_encoders: car|turn_costs=true,motorcycle|turn_costs=true
  prepare.ch.weightings: fastest
  prepare.min_network_size: 200
  prepare.min_one_way_network_size: 200
  routing.ch.disabling_allowed: true
  routing.non_ch.max_waypoint_distance: 1000000
  graph.dataaccess: RAM_STORE
server:
  applicationConnectors:
  - type: http
    port: 8989
    bindHost: localhost
  requestLog:
      appenders: []
  adminConnectors:
  - type: http
    port: 8990
    bindHost: localhost

For v0.13:

graphhopper:
  graph.flag_encoders: car|turn_costs=true,motorcycle|turn_costs=true
  graph.encoded_values: road_class,road_class_link,road_environment,max_speed,road_access
  graph.bytes_for_flags: 8
  prepare.ch.weightings: fastest
  prepare.ch.edge_based: off
  prepare.min_network_size: 200
  prepare.min_one_way_network_size: 200
  routing.ch.disabling_allowed: true
  routing.non_ch.max_waypoint_distance: 1000000
  graph.dataaccess: RAM_STORE
server:
  applicationConnectors:
  - type: http
    port: 8989
    # for security reasons bind to localhost
    bindHost: localhost
  requestLog:
      appenders: []
  adminConnectors:
  - type: http
    port: 8990
    bindHost: localhost

Best regards

Michael Reichert
Geofabrik GmbH

[karussell]

There were a couple of similar topics in the past.

The basic answer is that yes, the open source version is different, see the bottom of this site for all current differences. The problem is that OSM does not have enough information to improve the expected “average speed” and they don’t want this value in the data (understandably).

It would be really cool to have something like this for the open source version too, especially since maintaining this for the whole world does not really scale without a community effort. We are open for collaborations in this regard . A related project is our open traffic data repository.

According to the /info call, the commercial API uses data from 1 July 2019

The /info endpoint is a bit incorrect in our case as we have to collect the /info endpoint from dozens of servers. And so the data for the main vehicles should be younger (maximum 1 week old).