Fastest and shortest weightings have same result

Open Source Routing Engine
1

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

val hopper = GraphHopperOSM().forServer()
        .setDataReaderFile("input/data/san-francisco.osm.pbf")
        .setGraphHopperLocation("output/graph-cache")
        .setEncodingManager(EncodingManager("car"))
        hopper.chFactoryDecorator.setWeightingsAsStrings("fastest", "shortest")
        hopper.importOrLoad()

val request = GHRequest()
      locations.map { 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?

2

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)?

3

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?

4

Yes, plus the two log lines from

logger.info(request)

would help

5

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 com.graphhopper.storage.index.LocationIndexTree - 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 com.graphhopper.routing.ch.CHAlgoFactoryDecorator - 1/2 calling prepare.doWork for fastest|car ... (totalMB:817, usedMB:40)
[main] INFO com.graphhopper.routing.ch.CHAlgoFactoryDecorator - 2/2 calling prepare.doWork for shortest|car ... (totalMB:817, usedMB:40)
[fastest_car] INFO com.graphhopper.routing.ch.PrepareContractionHierarchies - 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 com.graphhopper.routing.ch.PrepareContractionHierarchies - 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 com.graphhopper.routing.ch.PrepareContractionHierarchies - 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 com.graphhopper.routing.ch.PrepareContractionHierarchies - 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 com.graphhopper.routing.ch.PrepareContractionHierarchies - 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 com.graphhopper.routing.ch.PrepareContractionHierarchies - 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 com.graphhopper.routing.ch.PrepareContractionHierarchies - 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 com.graphhopper.routing.ch.PrepareContractionHierarchies - 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 com.graphhopper.routing.ch.PrepareContractionHierarchies - 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 com.graphhopper.routing.ch.PrepareContractionHierarchies - 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 com.graphhopper.routing.ch.PrepareContractionHierarchies - 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 com.graphhopper.routing.ch.PrepareContractionHierarchies - 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 com.graphhopper.routing.ch.PrepareContractionHierarchies - 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 com.graphhopper.routing.ch.PrepareContractionHierarchies - 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
6

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)

to

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).

logger.info(request.toString) should then work or something

7

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()

8

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

9

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

10

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.

11

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