Fastest and shortest weightings have same result

I have a graphhopper instance loaded with the following code for fastest and shortest weightings (sorry about Kotlin)

val hopper = GraphHopperOSM().forServer()
        hopper.chFactoryDecorator.setWeightingsAsStrings("fastest", "shortest")

val request = GHRequest() { location -> GHPoint(location.latitude, location.longitude) }
        .forEach { point -> request.addPoint(point) }
      request.hints.put("calcPoints", false)
      request.hints.put("instructions", false)
      request.weighting = "fastest"
val response = hopper.route(request)

On setting the weighting, whether I have fastest or shortest route it gives me the same route. Am I approaching incorrectly as to how activate the shortest mode?

This looks correct. If you add a hopper.flush at the end you can make sure you are not doing work twice. What are you getting as log output when you redo the code above? (make sure you execute hopper.clean before importOrLoad)

Do you see two phases for contraction hierarchies (CH)?

Hi, and yes. I did flush and clean the hopper instance to test if I was doing something wrong or the like. I can paste the log if it would help. Would it?

Yes, plus the two log lines from

would help

I tried using a logger but it did not accept request as a valid parameter. Any in particular, I’m using sl4j. I’m sorry for the delay btw.

[main] INFO com.graphhopper.reader.osm.GraphHopperOSM - version 0.8.2|2016-10-19T17:38:28Z (5,14,4,3,3,2)
[main] INFO com.graphhopper.reader.osm.GraphHopperOSM - graph CH|car|RAM_STORE|2D|NoExt|,,,,, details:edges:0(0MB), nodes:0(0MB), name:(0MB), geo:0(0MB), bounds:1.7976931348623157E308,-1.7976931348623157E308,1.7976931348623157E308,-1.7976931348623157E308, CHGraph|fastest|car, shortcuts:0, nodesCH:(0MB), CHGraph|shortest|car, shortcuts:0, nodesCH:(0MB)
[main] INFO com.graphhopper.reader.osm.GraphHopperOSM - start creating graph from data/planet.osm.pbf
[main] INFO com.graphhopper.reader.osm.GraphHopperOSM - using CH|car|RAM_STORE|2D|NoExt|,,,,, memory:totalMB:123, usedMB:14
[main] INFO com.graphhopper.reader.osm.OSMReader - creating graph. Found nodes (pillar+tower):129 854, totalMB:1187, usedMB:660
[main] INFO com.graphhopper.reader.osm.OSMReader - 2 733 329, now parsing ways
[main] INFO com.graphhopper.reader.osm.OSMReader - 3 037 128, now parsing relations
[main] INFO com.graphhopper.reader.osm.OSMReader - finished way processing. nodes: 33212, osmIdMap.size:130018, osmIdMap:1MB, nodeFlagsMap.size:164, relFlagsMap.size:0, zeroCounter:164 totalMB:817, usedMB:20
[main] INFO com.graphhopper.reader.osm.OSMReader - time pass1:8s, pass2:5s, total:14s
[main] INFO com.graphhopper.reader.osm.GraphHopperOSM - start finding subnetworks, totalMB:817, usedMB:20
[main] INFO com.graphhopper.routing.subnetwork.PrepareRoutingSubnetworks - 204 subnetworks found for car, totalMB:817, usedMB:22
[main] INFO com.graphhopper.routing.subnetwork.PrepareRoutingSubnetworks - optimize to remove subnetworks (204), unvisited-dead-end-nodes (0), maxEdges/node (7)
[main] INFO com.graphhopper.reader.osm.GraphHopperOSM - edges: 46969, nodes 32523, there were 204 subnetworks. removed them => 689 less nodes
[main] INFO - location index created in 0.103919744s, size:46 151, leafs:6 388, precision:300, depth:3, checksum:32523, entries:[64, 64, 4], entriesPerLeaf:7.22464
[main] INFO - 1/2 calling prepare.doWork for fastest|car ... (totalMB:817, usedMB:40)
[main] INFO - 2/2 calling prepare.doWork for shortest|car ... (totalMB:817, usedMB:40)
[fastest_car] INFO - 0, updates:0, nodes: 32 523, shortcuts:0, dijkstras:156 911, t(dijk):0.08, t(period):0.0, t(lazy):0.0, t(neighbor):0.0, meanDegree:1, algo:0MB, totalMB:817, usedMB:43
[fastest_car] INFO - 6 500, updates:0, nodes: 26 023, shortcuts:2 047, dijkstras:163 835, t(dijk):0.13, t(period):0.0, t(lazy):0.0, t(neighbor):0.05, meanDegree:1, algo:0MB, totalMB:817, usedMB:44
[fastest_car] INFO - 13 000, updates:1, nodes: 19 523, shortcuts:9 434, dijkstras:332 745, t(dijk):0.73, t(period):0.56, t(lazy):0.0, t(neighbor):0.14, meanDegree:1, algo:0MB, totalMB:817, usedMB:48
[fastest_car] INFO - 19 500, updates:2, nodes: 13 023, shortcuts:16 231, dijkstras:472 110, t(dijk):1.13, t(period):0.91, t(lazy):0.0, t(neighbor):0.2, meanDegree:2, algo:0MB, totalMB:817, usedMB:52
[fastest_car] INFO - 26 000, updates:3, nodes: 6 523, shortcuts:28 078, dijkstras:630 805, t(dijk):1.69, t(period):1.21, t(lazy):0.0, t(neighbor):0.38, meanDegree:2, algo:0MB, totalMB:817, usedMB:55
[fastest_car] INFO - 32 500, updates:4, nodes: 975, shortcuts:41 526, dijkstras:866 234, t(dijk):2.95, t(period):1.54, t(lazy):0.27, t(neighbor):0.86, meanDegree:3, algo:0MB, totalMB:817, usedMB:61
[fastest_car] INFO - took:4, new shortcuts: 45 859, prepare|fastest, dijkstras:992391, t(dijk):3.76, t(period):1.67, t(lazy):0.46, t(neighbor):1.25, meanDegree:1, initSize:32523, periodic:20, lazy:10, neighbor:20, totalMB:817, usedMB:63
[shortest_car] INFO - 0, updates:0, nodes: 32 523, shortcuts:0, dijkstras:156 911, t(dijk):0.08, t(period):0.0, t(lazy):0.0, t(neighbor):0.0, meanDegree:1, algo:0MB, totalMB:817, usedMB:64
[shortest_car] INFO - 6 500, updates:0, nodes: 26 023, shortcuts:2 067, dijkstras:163 782, t(dijk):0.09, t(period):0.0, t(lazy):0.0, t(neighbor):0.03, meanDegree:1, algo:0MB, totalMB:817, usedMB:66
[shortest_car] INFO - 13 000, updates:1, nodes: 19 523, shortcuts:10 043, dijkstras:331 519, t(dijk):0.41, t(period):0.26, t(lazy):0.0, t(neighbor):0.09, meanDegree:2, algo:0MB, totalMB:817, usedMB:69
[shortest_car] INFO - 19 500, updates:2, nodes: 13 023, shortcuts:18 001, dijkstras:483 176, t(dijk):0.79, t(period):0.57, t(lazy):0.0, t(neighbor):0.17, meanDegree:2, algo:0MB, totalMB:817, usedMB:72
[shortest_car] INFO - 26 000, updates:3, nodes: 6 523, shortcuts:31 267, dijkstras:664 917, t(dijk):1.39, t(period):0.9, t(lazy):0.0, t(neighbor):0.38, meanDegree:3, algo:0MB, totalMB:817, usedMB:77
[shortest_car] INFO - 32 500, updates:4, nodes: 1 462, shortcuts:50 032, dijkstras:1 071 404, t(dijk):3.64, t(period):1.3, t(lazy):0.48, t(neighbor):1.48, meanDegree:5, algo:0MB, totalMB:817, usedMB:83
[shortest_car] INFO - took:9, new shortcuts: 59 197, prepare|shortest, dijkstras:1585409, t(dijk):8.39, t(period):1.91, t(lazy):1.52, t(neighbor):4.04, meanDegree:1, initSize:32523, periodic:20, lazy:10, neighbor:20, totalMB:817, usedMB:86

No need to sorry and it looks like you have a working system with fastest and shortest shortcuts for CH.

Just to be sure, when you query the routing engine you change

request.weighting = "fastest"
val response = hopper.route(request)


request.weighting = "shortest"
val response = hopper.route(request)

And as I do not know kotlin: the code request.weighting=xy calls request.setWeighting(xy)? Because this is not just a simple setter (see the code). should then work or something

Yes, underlying is the same setWeighting. Well that’s a relief then, I did try multiple different routes and got same result. Maybe I had to be more extreme in the scenarios.

The lines from the logger on both requests are the same after setting the weighting btw.

[main] INFO Engine - 37.777973,-122.415746; 37.77964296,-122.44549306()

BTW: often shortest is not really desired and some (configured) ShortFastestWeighting is wanted

I don’t understand the difference of what you said.

The ‘shortest’ implies the shortest distance always even where it makes no sense (it will make shortcuts with more turns or use small roads which are very slow etc). And so our experience was that often the FastestWeighting with less used distance is wanted and you can do so via configuring a ShortFastestWeighting.

I was actually not aware that I could create custom weightings, thanks. I’ll check that out.