MLD shortest direct path search #3788

oxidase · 2017-03-08T13:26:05Z

Issue

PR solves #3759 by adding MLD search and routeStep functions.

Some preliminary results for germany-latest:

CH contraction: 764.415 sec
CoreCH95%: 92.8731 sec
MLD customization for 128 max-cell size: 32.8147 seconds

Query times for bayern-latest München -> Würzburg :

CH 2-2.4ms
CoreCH95% 49-54ms
MLD 11-13ms
Here is the search space for MLD. GeoJSON annotations show level and number of visited/inserted nodes into heap, greenish is the forward heap, reddish is the reverse one.

There are some discussion points:

osrm::engine::routing_algorithms::unpackPath is hardcoded to CH unpacking and it is not so trivial to decouple unpacking procedure. Some possibilities:
- pass an unpacking function by reference (it will require complete function template arguments resolution on the caller side)
- create a new annotatePath function that will take a list of unpacked edges
different member names in EdgeData like QueryEdge::EdgeData::id, EdgeBasedEdge::EdgeData::edge_id -> it must be unified for duck-typing (turn_id ?)
atm routing_base.[ch]pp files are CH-aware, should it be split into algorithm-aware ch_routing_base.[ch]pp, mld_routing_base.[ch]pp and algorithm-insensitive routing_base.[ch]pp?
no tests: would it make sense to run cucumber tests in different jobs with -a CH and -a MLD or tests must be for both CH and MLD?

Tasklist

Requirements / Relations

MLD customization: fill weights in CellStorage #3738 is required
Write preprocessed edge-based graph in osrm-extract or osrm-partition #3783 must be merged before the PR
Replace BinaryHeap implementation #3764 would be nice to have it before merging

TheMarex · 2017-03-08T16:17:57Z

create a new annotatePath function that will take a list of unpacked edges

Yes please. I have been meaning to do this refactor for ages. ❤️

different member names in EdgeData like QueryEdge::EdgeData::id, EdgeBasedEdge::EdgeData::edge_id -> it must be unified for duck-typing (turn_id ?)

Yes, turn_id sounds good.

atm routing_base.[ch]pp files are CH-aware, should it be split into algorithm-aware ch_routing_base.[ch]pp, mld_routing_base.[ch]pp and algorithm-insensitive routing_base.[ch]pp

Yeah there are two options here:

Sub-folders with matching name-spaces routing_algorithms/ch/shortest_path.{c,h}pp and then alias headers in routing_algorithms/shortest_path.hpp which pull functions form routing_algorithms::ch in the routing_algorithms namespace so the function overloading in engine/routing_algorithms.hpp works.
Just post-fixes to the file names like you suggested. shortest_path_ch.{c,h}pp

no tests: would it make sense to run cucumber tests in different jobs with -a CH and -a MLD or tests must be for both CH and MLD?

Running the complete tool-chain two times on each job seems a little overkill. Maybe we can add an own travis job that runs the MLD toolchain with the tests? There are definitely some that won't work on MLD since we haven't implemented the algorithms yet. We could tag these with @todo_mld in cucumber to get the tests passing.

oxidase · 2017-03-12T13:09:17Z

Adjusted branch to comments and added mld cucumber profile that excludes tests with the tags @match, @alternative, @traffic, @matrix, @trip, @via.
Running 907 scenarios with -a MLD takes only 24 seconds for linux and 2 minutes for OSX builds. I would like to keep running osrm-extract, osrm-contract, osrm-partition and osrm-customize in all jobs to have regressions checks in the MLD toolchain.

TheMarex

There are some algorithmic adjustment that we need to do here. Otherwise this is a great first step. 👍

TheMarex · 2017-03-13T11:48:31Z

.travis.yml

@@ -207,6 +207,7 @@ script:
  - ./unit_tests/partition-tests
  - popd
  - npm test
+  - node ./node_modules/cucumber/bin/cucumber.js features/ -p mld


This should go into the test target of the package.json

TheMarex · 2017-03-13T11:49:51Z

features/lib/osrm_loader.js

@@ -77,7 +77,9 @@ class OSRMDirectLoader extends OSRMBaseLoader {
    osrmUp (callback) {
        if (this.osrmIsRunning()) return callback(new Error("osrm-routed already running!"));

-        this.child = this.scope.runBin('osrm-routed', util.format("%s -p %d", this.inputFile, this.scope.OSRM_PORT), this.scope.environment, (err) => {
+        let command_arguments = util.format('%s -p %d', this.inputFile, this.scope.OSRM_PORT);
+        command_arguments += this.scope.ROUTING_ALGORITHM.length > 0 ? ' --algorithm ' + this.scope.ROUTING_ALGORITHM : '';


We should just set a default for ROUTING_ALGORITHM (e.g. CH) and remove these conditional checks.

TheMarex · 2017-03-13T11:50:06Z

features/lib/osrm_loader.js

@@ -115,7 +117,9 @@ class OSRMDatastoreLoader extends OSRMBaseLoader {
    osrmUp (callback) {
        if (this.osrmIsRunning()) return callback();

-        this.child = this.scope.runBin('osrm-routed', util.format('--shared-memory=1 -p %d', this.scope.OSRM_PORT), this.scope.environment, (err) => {
+        let command_arguments = util.format('--shared-memory=1 -p %d', this.scope.OSRM_PORT);
+        command_arguments += this.scope.ROUTING_ALGORITHM.length > 0 ? ' --algorithm ' + this.scope.ROUTING_ALGORITHM : '';


Same here, default instead of conditional.

TheMarex · 2017-03-13T12:29:06Z

include/engine/routing_algorithms/routing_base_ch.hpp

+}
+
+template <typename RandomIter, typename FacadeT>
+void unpackPath(const FacadeT &facade,


This function should be algorithm independent, right? That is why the facade was templated here.

unpackPath is only needed for CH and CoreCH. Same unpacking, but different facade types

TheMarex · 2017-03-13T13:31:12Z

include/engine/routing_algorithms/routing_base_mld.hpp

+    const auto weight = forward_heap.GetKey(node);
+
+    auto update_upper_bounds = [&](NodeID to, EdgeWeight forward_weight, EdgeWeight edge_weight) {
+        // Upper bound for the path source -> target with


We can guarantee that all heap weights will be bigger then 0 after the initial relaxation of all heap weights with negative weight.
This would require a "pre-query" before actually start the full bi-directional dijkstra:

Add nodes to heaps like now

Run routeStep<FOWARD_DIRECTION> unitl forward_heap.MinKey() > 0. Now the pre-condition for a correct bi-directional Dijkstra is fulfilled.

Run the fill bi-directional Dijkstra with termination criterion: forward_heap.MinKey() + reverse_heap.MinKey() > upper_bound

For correctness a few other kinks in the query code need to be changed, that I will outline below.

TheMarex · 2017-03-13T15:57:15Z

include/partition/edge_based_graph_reader.hpp

-        }
-        else
+        // // merge edges (s,t) and (t,s) into bidirectional edge
+        // if (forward_edge.data.weight == reverse_edge.data.weight)


Why is this commented out?

The problem is that some backward edges will be missing in GetAdjacentEdgeRange

TheMarex · 2017-03-13T15:58:19Z

include/partition/cell_storage.hpp

-            cells[cell_index], weights.data(), source_boundary.data(), destination_boundary.data()};
+        return ConstCell{cells[cell_index],
+                         weights.data(),
+                         source_boundary.empty() ? nullptr : source_boundary.data(),


In what case do we need the conditional here?

All tests that have two nodes like "a b" will have no source and boundary nodes on all levels. .data() or referencing &..[0] will an undefined behavior without explicit check for .empty()

TheMarex · 2017-03-13T16:00:28Z

include/engine/search_engine_data.hpp

    static SearchEngineHeapPtr forward_heap_1;
    static SearchEngineHeapPtr reverse_heap_1;
    static SearchEngineHeapPtr forward_heap_2;
    static SearchEngineHeapPtr reverse_heap_2;
    static SearchEngineHeapPtr forward_heap_3;
    static SearchEngineHeapPtr reverse_heap_3;
    static ManyToManyHeapPtr many_to_many_heap;
+    static MultiLayerDijkstraHeapPtr mld_forward_heap;


We should work towards making MLD use the same heaps that the CH variants use.

If this is generally not possible, we could also type-tag the SearchEngineData and use the CH heap data for SeachEngineData<CH> and the MLD versions for SearchEngineData<MLD>.

Only algorithm dependent part that I think would really be needed would be bool HeapData::from_clique_arc.

yes, HeapData::from_clique_arc is only needed, but it will be 4 bytes with alignment, so i placed complete edge ID to avoid calling FindEdge later. In CH the same flag is hidden in QueryEdge but i don't think it is good idea to cut one bit from node ID in `EdgeBasedEdge``

TheMarex · 2017-03-13T16:01:17Z

include/engine/search_engine_data.hpp

@@ -23,6 +24,21 @@ struct ManyToManyHeapData : HeapData
    ManyToManyHeapData(NodeID p, EdgeWeight duration) : HeapData(p), duration(duration) {}
 };

+struct MultiLayerDijkstraHeapData : HeapData


We can type-tag this if we need to have it algorithm dependent. (see below)

I have tested performance of creating a new heap and clearing, it is almost the same.
It should be changed in #3816

TheMarex · 2017-03-13T16:07:48Z

include/engine/routing_algorithms/routing_base_mld.hpp

+template <bool DIRECTION>
+void routingStep(const datafacade::ContiguousInternalMemoryDataFacade<algorithm::MLD> &facade,
+                 const partition::MultiLevelPartitionView &partition,
+                 const partition::CellStorageView &cells,


We can add an closure here that makes it easy to compute the query level for a node:

struct QueryLevel { const MultiLevelPartition &mlp; const PhantomNode &source; const PhantomNode &target; LevelID operator()(NodeID node) { auto forward_level = mlp.GetQueryLevel(source.foward_node, target.forward_node, node); auto backward_level = mlp.GetQueryLevel(source.backward_node, target.backward_node, node); return std::min(forward_level, backward_level); } };

If we can fix out partition to ensure that the level 1 cell for forward_node and backward_node is always the same, we can optimize to only compute one.

oxidase · 2017-03-14T23:32:21Z

I have adjusted the branch to review comments, but two points still can be discussed and i have no better ideas (i pushed two additional commits into a reference branch to mld/routing-reference):

upper bound in f8cb6ba is similar to CH one, but it is too pessimistic because of the problem sketched here for 1D graph when one point is close to a high level border

The highest difference level is 2, so forward and reverse heap will meet first at the left point, but the result will not be the shortest path from s to t. So the upper bound must be very pessimistic to find the correct middle point on the right side. Because of the different search levels the reverse heap will scan level 2 for nothing. In my original implementation 581c2a7 two upper bounds for the forward and reverse heaps are updated separately, so in the example the reverse heap will stop scanning and "wait" until the forward heap will get to the level 2 (it is not exactly the condition but the upper bound for the reverse heap can be shifted only when the forward heap will reach the second level).
Search spaces for both upper bounds

one upper bound f8cb6ba https://gist.github.com/oxidase/57b4c8a1dd7482a73a02d6d6f4a663a0
two separate upper bounds 581c2a7 https://gist.github.com/oxidase/b371c80479dc4598f399dddc6ef25d5b

keep the level value in the heap data f6ec5d2. I tried to remove the level field, but found that i can not compute the level of an overlay edge from the node ids, because GetHighestDifferentLevel(source, target) for any overlay edge source -> target is 0. This leads to a problem: after going on a boundary edge to the level 1 and taking a shortcut on the level 1, the next possible level will be again 0, so MLD just falls back to the Dijkstra algorithm on the base graph. Atm, i don't know how to avoid storing the level value in the node data.

@TheMarex please could you check these two points?

oxidase · 2017-03-15T00:42:18Z

Tested locally on german-latest: customization is ~33seconds

[info] Loading partition data took 8.30845 seconds
[info] Cells customization took 33.1257 seconds
[info] MLD customization writing took 0.070301 seconds
[info] Graph writing took 0.525101 seconds
[info] Cells statistics per level
[info] Level 1 #cells 70419 #nodes 13943644,   source nodes: average 755984 (5.42171%) invalid 35 (0.00025101%),   destination nodes: average 1073630 (7.69978%) invalid 71 (0.000509193%)
[info] Level 2 #cells 5131 #nodes 13943644,   source nodes: average 121072 (0.868295%) invalid 14 (0.000100404%),   destination nodes: average 164219 (1.17773%) invalid 9 (6.45455e-05%)
[info] Level 3 #cells 315 #nodes 13943644,   source nodes: average 21721 (0.155777%) invalid 0 (0%),   destination nodes: average 28961 (0.2077%) invalid 1 (7.17173e-06%)
[info] Level 4 #cells 10 #nodes 13943644,   source nodes: average 1853 (0.0132892%) invalid 0 (0%),   destination nodes: average 2428 (0.017413%) invalid 0 (0%)

route Munich->Hamburg ~30ms

[info] 15-03-2017 01:35:37 30.2905ms 127.0.0.1 - HTTPie/0.9.2 200 /route/v1/driving/11.578946,48.138177;9.981766,53.547244
[info] 15-03-2017 01:35:38 31.4429ms 127.0.0.1 - HTTPie/0.9.2 200 /route/v1/driving/11.578946,48.138177;9.981766,53.547244
[info] 15-03-2017 01:35:39 29.9721ms 127.0.0.1 - HTTPie/0.9.2 200 /route/v1/driving/11.578946,48.138177;9.981766,53.547244
[info] 15-03-2017 01:35:41 30.7037ms 127.0.0.1 - HTTPie/0.9.2 200 /route/v1/driving/11.578946,48.138177;9.981766,53.547244
[info] 15-03-2017 01:35:42 30.4965ms 127.0.0.1 - HTTPie/0.9.2 200 /route/v1/driving/11.578946,48.138177;9.981766,53.547244
[info] 15-03-2017 01:35:43 30.7287ms 127.0.0.1 - HTTPie/0.9.2 200 /route/v1/driving/11.578946,48.138177;9.981766,53.547244
[info] 15-03-2017 01:35:44 30.4513ms 127.0.0.1 - HTTPie/0.9.2 200 /route/v1/driving/11.578946,48.138177;9.981766,53.547244

Search space https://gist.github.com/oxidase/3015ec44f4570090a84790bba60a266d

TheMarex · 2017-03-15T14:34:45Z

Questions were resolved as per slack: Above example uses the wrong query level for the backward heap.

oxidase · 2017-03-15T14:48:24Z

@TheMarex i have pushed the current state:

removed level from the heap data and added get_query_heap closure
change to the proper upper bound. I could not use WasInserted(node) && WasRemoved(node) in the upper bound condition, because it changes snapping behavior of start points with negative weights.
This change should be also in CH-dependent functions, algorithm-independent function annotatePath and tests expectations.
removing edge_id in 223b65f requires to use FindEdge for every path edge, this adds a performance regression wrt to 7907cf3. Here is a query timing summary in milliseconds for the test path

`7907cf3`
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
  3.507   3.631   3.683   3.789   3.769   5.678

`223b65f`
   Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
  4.464   4.614   4.679   4.863   4.821   7.626

So i would keep edge_id in MLD heaps.

Still TODO: split MLD search function into unconstrained path search and path unpacking that is constrained by level and parent cell id.

/cc @TheMarex

TheMarex · 2017-03-15T20:57:07Z

So i would keep edge_id in MLD heaps.

👍 In that case a Algorithm-specific specialization of SearchEngineData would make sense.

change to the proper upper bound. I could not use WasInserted(node) && WasRemoved(node) in the upper bound condition, because it changes snapping behavior of start points with negative weights

Yes we need to initialize the forward_heap to have a non-zero forward_heap.MinKey(). The easiest way to do this consistently for MLD and CH is to do a few initialization rounds. Something like this:

// heap is not fully initialized yet we need to resolve negative
// initial offsets first for Dijkstra to work
while (!forward_heap.empty() && forward_heap.MinKey() < 0)
{
     routeStep<true>(forward_heap, ....)
}

// real query with termination start here:
while (!forward_heap.empty() && )
{
     routeStep<true>(forward_heap, ....)

     routeStep<false>(reverse_heap, ....)

     if (forward_heap.MinKey() + reverse_heap.MinKey() > 0)
       // terminate
}

oxidase · 2017-03-16T00:57:43Z

@TheMarex i think i addressed all open points. Just two notes:

I split unrestricted and restricted searches via argument packs https://github.com/Project-OSRM/osrm-backend/blob/mld/routing/include/engine/routing_algorithms/routing_base_mld.hpp#L24-L44
At first i tried to use closure [sublevel] (NodeID) { return sublevel; } for the fixed level restriction, but this introduces indirect function calls that can not be optimized out by compiler. With argument packs compiler uses a function pointer only for the unrestricted search, because the closure function should capture phantom nodes. For the restricted search a simple integer compare will be used. This gives improvement from 4ms to 3.6ms for the test path.
I was wrong calling "never-go-down" condition. Now it is simpler, but it is still needed to avoid going inside into cells on lower sublevels. Without this condition internal edges on the level 0 that can be ignored will be added into heap.

oxidase · 2017-03-16T09:43:45Z

@TheMarex negative values should not be inserted into heaps or weight values after delete must be increased from negative values to 0 for starting points otherwise .GetKey(start) will return negative values.
I think the first option is better - it will allow to change weights to unsigned values.
It should be like:

heap.Insert(start_forward, 0 {start_forward}); heap.DeleteMin();
heap.Insert(start_reverse, 0 {start_reverse}); heap.DeleteMin();
for (edge : GetAdjacentEdgeRange(start_forward)) {
    assert(edge_data.weight - GetForwardWeightPlusOffset() >= 0);
    heap.Insert(to, edge_data.weight - GetForwardWeightPlusOffset(), {start_forward});
}
for (edge : GetAdjacentEdgeRange(start_reverse)) {
    assert(edge_data.weight - GetReverseWeightPlusOffset() >= 0);
    heap.Insert(to, edge_data.weight - GetReverseWeightPlusOffset(), {start_reverse});
}

This must be fixed in algorithm-independent part. One problem that I have found: 144 scenarios fail because of different snapping in 5a4ceaf. I have impression that the current snapping behavior is used implicitly: at https://github.com/oxidase/osrm-backend/blob/5a4ceaff9a47c8422f2f0c11d9bdd215b17d26d5/include/engine/guidance/assemble_steps.hpp#L227-L228 it is possible to get negative weights and durations if the first edge is changed.

TheMarex · 2017-03-16T11:32:56Z

@oxidase yes good point, negative source key would still bite us. Your refactor will also allow use to address #3429 (comment) eventually I think. This would give us fixing two bugs with one fix. 😄

That code you linked only deals with the corner case of having two phantom nodes on the same segment. The routing should terminate immediately with an empty path (since source == target). Not sure how this could be influenced by these routing changes.

oxidase · 2017-03-16T15:45:44Z

Checked on Europe size:

partitioning

[info] Computing recursive bisection
[info] Loaded compressed node based graph: 101166490 edges, 215440564 nodes
[info]  running partition: 128 1.2 0.25 10 1000 # max_cell_size balance boundary cuts small_component_size
[info] large component [0]=40047027
[info] large component [1566047]=12077
[info] large component [8522990]=7732
[info] large component [10727121]=7385
[info] large component [12838659]=8000
[info] large component [13241465]=1277
[info] large component [19526101]=5302
[info] large component [22262219]=1619
[info] large component [29259452]=3320
[info] SCC run took: 14.1289s
[info] Full bisection done in 1472.02s
[info] Loaded node based graph to edge based graph mapping
[info] Loaded edge based graph for mapping partition ids: 358189760 edges, 94965162 nodes
[info] Edge-based-graph annotation:
[info]   level 1 #cells 477500 bit size 19
[info]   level 2 #cells 35067 bit size 16
[info]   level 3 #cells 2187 bit size 12
[info]   level 4 #cells 74 bit size 7
[info] MultiLevelPartition constructed in 84.7451 seconds
[warn] Node needs to either have incoming or outgoing edges in cell. Number of unconnected nodes is 236
[info] CellStorage constructed in 17.1767 seconds
[info] MLD data writing took 1.03853 seconds
[info] Bisection took 1760.56 seconds.
[info] RAM: peak bytes used: 40976625664

customization **~ 2 min** 🎉

[info] Opening europe-latest.osrm.ebg
[info] Reading 179249752 edges from the edge based graph
[info] In total loaded 0 file(s) with a total of 0 unique values
[info] In total loaded 0 file(s) with a total of 0 unique values
[info] Done reading edges
[info] Loaded edge based graph for mapping partition ids: 358189760 edges, 94965162 nodes
[info] Loading partition data took 64.6892 seconds
[info] Cells customization took 47.9601 seconds
[info] MLD customization writing took 3.95046 seconds
[info] Graph writing took 4.476 seconds
[info] Cells statistics per level
[info] Level 1 #cells 477500 #nodes 94965162,   source nodes: average 5479064 (5.76955%) invalid 150 (0.000157953%),   destination nodes: average 7869387 (8.2866%) invalid 431 (0.000453851%)
[info] Level 2 #cells 35067 #nodes 94965162,   source nodes: average 854503 (0.899807%) invalid 27 (2.84315e-05%),   destination nodes: average 1188264 (1.25126%) invalid 81 (8.52944e-05%)
[info] Level 3 #cells 2187 #nodes 94965162,   source nodes: average 136718 (0.143966%) invalid 5 (5.26509e-06%),   destination nodes: average 187010 (0.196925%) invalid 18 (1.89543e-05%)
[info] Level 4 #cells 74 #nodes 94965162,   source nodes: average 12111 (0.0127531%) invalid 0 (0%),   destination nodes: average 16461 (0.0173337%) invalid 2 (2.10604e-06%)
[info] RAM: peak bytes used: 17938042880

queries
Munich -> Hamburg

[info] 16-03-2017 15:33:45 40.7062ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/11.578946,48.138177;9.981766,53.547244
[info] 16-03-2017 15:33:47 39.0631ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/11.578946,48.138177;9.981766,53.547244

Lisbon -> Kiev

[info] 16-03-2017 15:38:24 162.832ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/-9.136506,38.707793;30.524050,50.450107
[info] 16-03-2017 15:38:27 160.95ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/-9.136506,38.707793;30.524050,50.450107

Athens -> London

[info] 16-03-2017 15:43:22 126.19ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/23.727984,37.984149;-0.127647,51.507322
[info] 16-03-2017 15:43:23 126.622ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/23.727984,37.984149;-0.127647,51.507322
[info] 16-03-2017 15:43:25 126.884ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/23.727984,37.984149;-0.127647,51.507322

oxidase · 2017-03-16T17:38:01Z

Full CH preprocessing takes 1415.92 seconds and query responses are

[info] 16-03-2017 17:31:21 6.67244ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/11.578946,48.138177;9.981766,53.547244
[info] 16-03-2017 17:31:23 5.79274ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/11.578946,48.138177;9.981766,53.547244
[info] 16-03-2017 17:31:24 5.73531ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/11.578946,48.138177;9.981766,53.547244
[info] 16-03-2017 17:31:28 7.30056ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/11.578946,48.138177;9.981766,53.547244

[info] 16-03-2017 17:31:47 34.731ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/-9.136506,38.707793;30.524050,50.450107
[info] 16-03-2017 17:31:49 31.7682ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/-9.136506,38.707793;30.524050,50.450107
[info] 16-03-2017 17:31:53 31.9014ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/-9.136506,38.707793;30.524050,50.450107
[info] 16-03-2017 17:31:54 46.9425ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/-9.136506,38.707793;30.524050,50.450107

[info] 16-03-2017 17:32:15 24.2817ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/23.727984,37.984149;-0.127647,51.507322
[info] 16-03-2017 17:32:16 24.5297ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/23.727984,37.984149;-0.127647,51.507322
[info] 16-03-2017 17:32:17 24.5493ms 127.0.0.1 - curl/7.35.0 200 /route/v1/driving/23.727984,37.984149;-0.127647,51.507322

So MLD ~ 5-6 times slower than full CH

TheMarex · 2017-03-16T22:04:26Z

@oxidase looks good to me know. Merge at will. 🎉

oxidase · 2017-03-17T10:30:27Z

Rebased onto refactor/split-updater. Must be merge after #3809

Leaving log files opened was intentional to avoid missing output that can appear `child.on('exit',...)`. With this approach cucumber tests hit locally maximum number of opened files, because node.js keeps all log files opened.

oxidase added MLD Work In Progress labels Mar 8, 2017

oxidase force-pushed the mld/routing branch from b49283e to 96c64ee Compare March 10, 2017 16:31

TheMarex mentioned this pull request Mar 11, 2017

Add speed update functionality to osrm-customize #3808

Merged

2 tasks

oxidase force-pushed the mld/routing branch 2 times, most recently from dc84bde to 2705911 Compare March 12, 2017 12:43

oxidase added Review and removed Work In Progress labels Mar 12, 2017

oxidase force-pushed the mld/routing branch from 2705911 to ce285b5 Compare March 12, 2017 20:49

TheMarex requested changes Mar 13, 2017

View reviewed changes

oxidase force-pushed the mld/routing branch 5 times, most recently from 8582c3d to 5dc6b7f Compare March 14, 2017 21:52

oxidase force-pushed the mld/routing branch 3 times, most recently from 01e949b to 5938435 Compare March 16, 2017 00:43

TheMarex added the Review - In feedback label Mar 16, 2017

TheMarex approved these changes Mar 16, 2017

View reviewed changes

TheMarex added Ready To Merge and removed Review - In feedback labels Mar 16, 2017

oxidase force-pushed the mld/routing branch from b8b58f6 to 6af63e4 Compare March 17, 2017 06:20

oxidase mentioned this pull request Mar 17, 2017

clang 4 sanitizer is not happy with TBB usage in updater #3831

Closed

oxidase force-pushed the mld/routing branch from 6af63e4 to 44de8a4 Compare March 17, 2017 10:29

oxidase added 7 commits March 17, 2017 12:27

Add routing algorithm option

c370ddd

Rename {id|edge_id} to turn_id

43a7e8e

Split routing_base into CH and non-CH parts

6829f46

MLD direct shortest path plugin

c648711

Fix cell storage for tiny maps

81771a3

Add MLD testing to cucumber tests

fe5d1a6

Fix weights and annotations for phantom points on one segment

6586737

oxidase force-pushed the mld/routing branch from 44de8a4 to 5e5ea4a Compare March 17, 2017 11:34

oxidase added 9 commits March 17, 2017 13:20

Prepare test data for both CH and MLD algorithms

97c4424

Leaving log files opened was intentional to avoid missing output that can appear `child.on('exit',...)`. With this approach cucumber tests hit locally maximum number of opened files, because node.js keeps all log files opened.

MLD regression tests

20c6b46

Added traffic tests to MLD testing

c396901

Remove level field from heap node data

152f77b

Use correct upper bound condition for MLD routing

a75fd56

Add data names to benchmark output

5e40b12

Implement MLD routingStep with cell restriction and without

0c6ce6c

Avoid dynamic binding in getNodeQureyLevel

f1b88ad

Change edge_id to from_clique_arc in MultiLayerDijkstraHeapData

79ef204

oxidase force-pushed the mld/routing branch from 5e5ea4a to 79ef204 Compare March 17, 2017 12:39

oxidase merged commit af65ccd into master Mar 17, 2017

TheMarex deleted the mld/routing branch March 17, 2017 14:49

oxidase mentioned this pull request Mar 17, 2017

Implement MLD path unpacking #3759

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MLD shortest direct path search #3788

MLD shortest direct path search #3788

oxidase commented Mar 8, 2017 •

edited

Loading

TheMarex commented Mar 8, 2017

oxidase commented Mar 12, 2017

TheMarex left a comment

TheMarex Mar 13, 2017

TheMarex Mar 13, 2017

TheMarex Mar 13, 2017

TheMarex Mar 13, 2017

oxidase Mar 14, 2017

TheMarex Mar 13, 2017

TheMarex Mar 13, 2017

oxidase Mar 14, 2017

TheMarex Mar 13, 2017

oxidase Mar 14, 2017

TheMarex Mar 13, 2017

oxidase Mar 14, 2017 •

edited

Loading

TheMarex Mar 13, 2017

oxidase Mar 14, 2017

TheMarex Mar 13, 2017

oxidase commented Mar 14, 2017

oxidase commented Mar 15, 2017 •

edited

Loading

TheMarex commented Mar 15, 2017

oxidase commented Mar 15, 2017

TheMarex commented Mar 15, 2017 •

edited

Loading

oxidase commented Mar 16, 2017

oxidase commented Mar 16, 2017

TheMarex commented Mar 16, 2017

oxidase commented Mar 16, 2017

oxidase commented Mar 16, 2017

TheMarex commented Mar 16, 2017

oxidase commented Mar 17, 2017

MLD shortest direct path search #3788

MLD shortest direct path search #3788

Conversation

oxidase commented Mar 8, 2017 • edited Loading

Issue

Tasklist

Requirements / Relations

TheMarex commented Mar 8, 2017

oxidase commented Mar 12, 2017

TheMarex left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oxidase Mar 14, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oxidase commented Mar 14, 2017

oxidase commented Mar 15, 2017 • edited Loading

TheMarex commented Mar 15, 2017

oxidase commented Mar 15, 2017

TheMarex commented Mar 15, 2017 • edited Loading

oxidase commented Mar 16, 2017

oxidase commented Mar 16, 2017

TheMarex commented Mar 16, 2017

oxidase commented Mar 16, 2017

oxidase commented Mar 16, 2017

TheMarex commented Mar 16, 2017

oxidase commented Mar 17, 2017

oxidase commented Mar 8, 2017 •

edited

Loading

oxidase Mar 14, 2017 •

edited

Loading

oxidase commented Mar 15, 2017 •

edited

Loading

TheMarex commented Mar 15, 2017 •

edited

Loading