One server for fastest and shortest requests

Hi. I am deploying my own GH server and I would like it to answer both fastest and shortest route requests in speed mode. My understanding is that speed mode means that a contracted hierarchy graph must be build.

Currently I create a graph hopper object and call

hopper.getCHFactoryDecorator().addWeighting("fastest");
hopper.getCHFactoryDecorator().addWeighting("shortest");

which creates two sets of contracted hierarchies files:

shortcuts_fastest_bike
nodes_ch_fastest_bike
shortcuts_shortest_bike
nodes_ch_shortest_bike

in the graph data folder but only one set of the remaining files:

edges
geometry
location_index
names
nodes
properties

(1) Why aren’t there edges_ch_shortest and edges_ch_fastest and so on?
(2) is my understanding correct, that addWeighting(..) specifies which CH graphs to build and consequently which types of requests my graph hopper instance can handle?

I do not understand the first question. If you query with weighting=fastest or weighting=shortest - does it work?

(2) is my understanding correct, that addWeighting(..) specifies which CH graphs to build and consequently which types of requests my graph hopper instance can handle?

You can handle all weightings via none-CH requests even without CH preparation, but yes, addWeighting says which weightings you’ll be able to calculate via CH.

BTW: I highly recommend not to use shortest. Instead use ShortFastestWeighting

regardig (1): which files belong to the CH graph? It seems that they are only the shortcuts_<mode>_<vehicle> and nodes_<mode>_<vehicle> files. A CH graph doesn’t have its own edges file (other than shortcuts). My question just shows that I don’t have any deep understanding of what is going on. My current understanding is that graph hopper creates a routing graph, the edges and nodes files, from eg a osm file hopper.setDataReaderFile("<city>.osm.pbf"); The CH graph speeds up queries (hence enables the speed mode) by sorting nodes and adding shortcut edges. Is that correct? What are location_index and geometry about?

regarding (2): addWeighting(..) suggested to me that I could “merge” or “mix” weightings whereas my understanding now is that I simply tell hopper which CH graphs to build.

regarding ShortFastestWeighting: I am very curious to know why? I have found the routing/weighting directory and am looking at the different implementations of the calcWeight method. The ShortestWeighting uses only distance while in ShortFastestWeighting is a weighted sum of time and distance, right?

I have tested some (inner city) queries with fastest and shortest and the results suggested that often the same route is computed. This may of course be very different for queries between cities…

The CH graph speeds up queries (hence enables the speed mode ) by sorting nodes and adding shortcut edges. Is that correct?

It is a special routing algorithm and it “just” introduces edges, yes. See Contraction hierarchies - Wikipedia

What are location_index and geometry about?

The location index looks up the node IDs for any lat,lon pair. In the geometry we store the road geometry for every edge.

regarding ShortFastestWeighting : I am very curious to know why?

“shortest” without any time constraint can lead to arbitrary bad routes using roads with very low speed just because it is some minor meters shorter.

Hi @karussell

Would you still recommend not using weighting=shortest? I am testing weighting=fastest vs weighting=shortest vs weighting=short_fastest for routes in Africa.