Distances in matrix - CH #4990

ghoshkaj · 2018-04-02T04:39:32Z

Issue

This PR implements distances in the matrix as in this issue: #1353

Tasklist

Requirements / Relations

~~The unpacking cache in #4876 needs to be merged in to master first.~~ This is currently shipping without the cache.

Current speeds are described here.

However, @chaupow and @danpat are cooking up faster distance calculations using cheap-ruler over in #5041!

ghoshkaj · 2018-04-02T05:22:36Z

Context: Within many_to_many_ch.cpp after finding the packed_path after the forward and backward routing steps are complete, I unpack the path and calculate the annotations (durations or distance).

To calculate the distance, I'm trying to use HaversineDistance to calculate the distances between two NodeIDs here in this computeEdgeDistance function. I'm calling the function while unpacking the packed_path from the calculateEBGNodeAnnotations function.

Question: the difficulty I'm having is in supplying the second Node ID (the third argument to computeEdgeDistance(const FacadeT &facade, NodeID node_id_1, NodeID node_id_2)). How do I get the correct second NodeID to get the coordinate and perform the HaversineDistance on the pair of coodinates?

What I've tried: If I pass in the second NodeID available to me within the calculateEBGNodeAnnotations function, while the first node is fine, the second node never exists in the coordinates list possible. Here's the output from the cucumber test: cucumber --name "Testbot - Travel time matrix of minimal network with different exclude". The output has been cleaned up a little:

m_coordinate_list: 1000000;1000000, 1000899;1000000, 1000000;999101, 1000899;999101, 
node_id_1: 1
node_id_2: 5
node_id_1 as coordinate: 1000899;1000000 // while this node exists in the coordinate list in the facade
node_id_2 as coordinate: 0;0 // the second coordinate never does
node_id_1 as osm_id: 2
node_id_2 as osm_id: 0

m_coordinate_list: 1000000;1000000, 1000899;1000000, 1000000;999101, 1000899;999101, 
node_id_1: 5
node_id_2: 6
node_id_1 as coordinate: 0;0
node_id_2 as coordinate: 0;0
node_id_1 as osm_id: 0
node_id_2 as osm_id: 0

m_coordinate_list: 1000000;1000000, 1000899;1000000, 1000000;999101, 1000899;999101, 
node_id_1: 3
node_id_2: 7
node_id_1 as coordinate: 1000899;999101
node_id_2 as coordinate: 0;1297240911
node_id_1 as osm_id: 4
node_id_2 as osm_id: 0

m_coordinate_list: 1000000;1000000, 1000899;1000000, 1000000;999101, 1000899;999101, 
node_id_1: 7
node_id_2: 4
node_id_1 as coordinate: 0;1297240911
node_id_2 as coordinate: 1297240911;0
node_id_1 as osm_id: 0
node_id_2 as osm_id: 0

From the output above, it looks like we want the OSRM node id that matches the node ids in the m_coordinate_list.

However, if the start of the edge or the end of the edge is the turn.id, it doesn't match any of the coordinates on the m_coordinates_list.

Is turn.id some other kind of id?
How can we get the OSRM node id that matches the node id's in m_coordinate_list?
Overall, how can I get access to a valid second node id to pass to HaversineDistance?
Or is this completely on the wrong track?

cc/ @oxidase @TheMarex @danpat

TheMarex · 2018-04-03T07:59:35Z

the difficulty I'm having is in supplying the second Node ID (the third argument to computeEdgeDistance(const FacadeT &facade, NodeID node_id_1, NodeID node_id_2)). How do I get the correct second NodeID to get the coordinate and perform the HaversineDistance on the pair of coodinates?

We need to do the following things:

Call GetUncompressedForwardGeometry using the ID value that you would also call GetUncompressedForwardDurations with.
Iterate over every pair of adjacent nodes and call GetCoordinateOfNode o/contiguous_internalmem_datafacade.hpp#L560) of for both nodes to obtain their coordinate.
The calculate the distance between them using HaversineDistance.

ghoshkaj · 2018-04-03T13:18:48Z

Call GetUncompressedForwardGeometry using the ID value that you would also call GetUncompressedForwardDurations with.

Iterate over every pair of adjacent nodes and call GetCoordinateOfNode o/contiguous_internalmem_datafacade.hpp#L560) of for both nodes to obtain their coordinate.

The calculate the distance between them using HaversineDistance.

I did this and it's working these are the results I have so far:

distance table:
       a        b         c        d
a      0,       199.97,   99.9924, 199.97
b      99.9924, 0,        99.9924, 0
c      0,       99.9772,  0,       99.9772
d      99.9924, 0,        99.9924, 0

for this scenario:

 Scenario: Testbot - Travel time matrix of minimal network with different exclude
        Given the query options
            | exclude  | motorway  |

        Given the node map
            """
            a b
            c d
            """

        And the ways
            | nodes | highway  | toll | #                                        |
            | ab    | motorway |      | not drivable for exclude=motorway        |
            | cd    | primary  |      | always drivable                          |
            | ac    | highway  | yes  | not drivable for exclude=motorway exclude=toll and exclude=motorway,toll |
            | bd    | highway  | yes  | not drivable for exclude=motorway exclude=toll |


        When I request a travel time matrix I should get
            |   | a  | b  | c  | d  |
            | a | 0  | 40 | 15 | 25 |
            | b | 40 | 0  | 25 | 15 |
            | c | 15 | 25 | 0  | 10 |
            | d | 25 | 15 | 10 | 0  |

@TheMarex so I think what's left now is the offset calculations. I looked at this a bit, and I see that we use source_phantom.GetForwardDuration() but there is no analogous function or member functions for distance_offset already in the PhantomNode class. I followed the path to see where the duration_offsets are calculated and they are calculated here in geospatial_query.hpp. It calls on the forward_duration_vector and following this back further the dataface which gets this information from segment_data which is ultimately populated by the extractor.

So to get the distance offsets, is the extractor code next in line to be augmented? Maybe in the segment_data_container?

Or is this the wrong track? 😄

TheMarex · 2018-04-03T13:56:32Z

So to get the distance offsets, is the extractor code next in line to be augmented? Maybe in the segment_data_container?

We can replicate this logic and loop over all node ids up until the phantom node segment and then do a similar calculation as the one you implemented for the annotations to sum up the distances.

One particular snag is that we need to add the distance to the phantom node location. Suppose we have a phantom node that is snapped to an edge-based-node that consists of four segments:

ForwardDistance
  |
  | offset
/  \/\
      x              <-- this is PhantomNode.location
0---1----2----3----4 <-- this is what GetUncompressedForwardGeometries() returns

The whole distance of the edge-based-node would be the haversine distance of the node-based-nodes 0 -> 1 -> 2 -> 3 -> 4. To account for the fact that the phantom node (x) actually snapped to somewhere between 1 and 2 we need to subtract the distance 0 -> 1 -> x from the whole distance value. Similar for the backwards offset we need to calculate x -> 2 -> 3 -> 4.

danpat · 2018-04-03T14:56:25Z

Another thought - we need to ensure the phantom node portions don't get cached :-/

ghoshkaj · 2018-04-03T15:50:25Z

@danpat we don't put that part of the calculation in the cache. Instead we do those offset calculations in the main body of the many_to_many function. For instance, for durations, those calculations happen here: https://github.com/Project-OSRM/osrm-backend/pull/4876/files#diff-81e2dc0f0a96c3d1a3fd7e43ee98a7f3R328

All the cache stuff happens 7 lines above, over here: https://github.com/Project-OSRM/osrm-backend/pull/4876/files#diff-81e2dc0f0a96c3d1a3fd7e43ee98a7f3R321

ghoshkaj · 2018-04-04T10:34:24Z

Okay so with the latest commit: ea8cdc7 I'm running into this compile error that I suspect comes from packing problems.

In file included from /Users/kajari/Mapbox/osrm-backend/include/engine/hint.hpp:31:
/Users/kajari/Mapbox/osrm-backend/include/engine/phantom_node.hpp:53:75: error: field 'bearing' will be initialized after field 'forward_distance' [-Werror,-Wreorder]
          is_valid_reverse_source{false}, is_valid_reverse_target{false}, bearing(0),
                                                                          ^
/Users/kajari/Mapbox/osrm-backend/include/engine/phantom_node.hpp:177:61: error: field 'bearing' will be initialized after field 'forward_distance' [-Werror,-Wreorder]
          is_valid_reverse_target{is_valid_reverse_target}, bearing{bearing},
                                                            ^
/Users/kajari/Mapbox/osrm-backend/include/engine/phantom_node.hpp:212:1: error: static_assert failed "PhantomNode has more padding then expected"
static_assert(sizeof(PhantomNode) == 128, "PhantomNode has more padding then expected");
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /Users/kajari/Mapbox/osrm-backend/src/server/service/match_service.cpp:3:
In file included from /Users/kajari/Mapbox/osrm-backend/include/server/api/parameters_parser.hpp:4:
In file included from /Users/kajari/Mapbox/osrm-backend/include/engine/api/base_parameters.hpp:33:
/Users/kajari/Mapbox/osrm-backend/include/engine/hint.hpp:66:1: error: static_assert failed "Hint is bigger than expected"
static_assert(sizeof(Hint) == 128 + 4, "Hint is bigger than expected");
^             ~~~~~~~~~~~~~~~~~~~~~~~
/Users/kajari/Mapbox/osrm-backend/include/engine/hint.hpp:68:1: error: static_assert failed "ENCODED_HINT_SIZE does not match size of Hint"
static_assert(ENCODED_HINT_SIZE / 4 * 3 >= sizeof(Hint),
^             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5 errors generated.

The datatype that I've added EdgeDistance is a double, which is 8 bytes, and I've added 4 new members of this type, so the size of PhantomNode should have increased by 64 bytes.
So on this line I changed it to 128, but as you can see, the compiler is not too happy about that either!

Questions:

Is that number not in bytes?
What does ENCODED_HINT_SIZE in constexpr std::size_t ENCODED_HINT_SIZE = 92; mean?

The other problem is that no matter where in the PhantomNode constructor, I place the new data members, the compiler keeps warning me about the order in which the data members will be initialized in.

I'm pretty sure that I need to take packing into consideration, but not sure how?

ghoshkaj · 2018-04-04T12:14:55Z

Oookay, got the answers:

I was doing the maths wrong. It's actually 4 * 8 = 32 btes extra, so it should have been 64 + 32 = 96 bytes.
I got the advice to change EdgeDistance from a double to a float as it suffices for the distances we'll encounter (which is about half the world's circumference which is 25763.7 km so using a single precision value that encodes 2^24=16777216 ~ 16km is enough. cc @oxidase ). So I've changed EdgeDistance to a float and adjust the padding accordingly.
The order of the class members not being in the same order as in the constructor causes the compiler to throw up warnings, and the current compiler settings are set to Error on Warnings.

All these problems are fixed for now!

ghoshkaj · 2018-04-05T19:03:40Z

Okay, so here's the latest, now that I've added put the offset functions into use:
For this scenario:

Scenario: Testbot - Travel time matrix of minimal network with different exclude
        Given the query options
            | exclude  | motorway  |

        Given the node map
            """
            a b
            c d
            """

        And the ways
            | nodes | highway  | toll | #                                        |
            | ab    | motorway |      | not drivable for exclude=motorway        |
            | cd    | primary  |      | always drivable                          |
            | ac    | highway  | yes  | not drivable for exclude=motorway exclude=toll and exclude=motorway,toll |
            | bd    | highway  | yes  | not drivable for exclude=motorway exclude=toll |


        When I request a travel time matrix I should get
            |   | a  | b  | c  | d  |
            | a | 0  | 40 | 15 | 25 |
            | b | 40 | 0  | 25 | 15 |
            | c | 15 | 25 | 0  | 10 |
            | d | 25 | 15 | 10 | 0  |

I get this table:

distance table:
  a 		b 		c 		d
a 0 		199.97 		99.9924		299.962 
b 199.97 	0 		99.9924 	99.9924 
c 99.9772 	99.9772 	0 		199.97 
d 99.9772 	-99.9924 	0 		0

I have not yet debugged these results other than a check to make sure that the distance offsets exactly matches all the offsetting behaviour for durations. This may be a wrong assumption, but I will tune that assumption later when I debug.

ghoshkaj · 2018-04-09T01:48:44Z

Distances on CH works! I've built out the pipeline through to the node bindings and have added cucumber and table tests. Here are a few:

  ✔ Given the profile "testbot"
  ✔ And the partition extra arguments "--small-component-size 1 --max-cell-sizes 2,4,8,16"
  ✔ Given the node map
      """
      a b
      """
  ✔ And the ways
      | nodes |
      | ab    |
  ✔ When I request a travel time matrix I should get
      |   | a  | b  |
      | a | 0  | 10 |
      | b | 10 | 0  |
  ✔ When I request a travel distance matrix I should get
      |   | a        | b        |
      | a | 0        | 9.997721 |
      | b | 9.997721 | 0        |

  ✔ Given the profile "testbot"
  ✔ And the partition extra arguments "--small-component-size 1 --max-cell-sizes 2,4,8,16"
  ✔ Given the node map
      """
      a b c d
      """
  ✔ And the ways
      | nodes | highway   |
      | ab    | primary   |
      | bc    | secondary |
      | cd    | tertiary  |
  ✔ When I request a travel time matrix I should get
      |   | a  | b  | c  | d  |
      | a | 0  | 10 | 30 | 60 |
      | b | 10 | 0  | 20 | 50 |
      | c | 30 | 20 | 0  | 30 |
      | d | 60 | 50 | 30 | 0  |
  ✔ When I request a travel distance matrix I should get
      |   | a         | b         | c         | d         |
      | a | 0         | 9.997721  | 19.995442 | 29.993164 |
      | b | 0         | 0         | 9.997721  | 19.995442 |
      | c | 9.997721  | 9.997721  | 0         | 9.997721  |
      | d | 29.993164 | 29.993164 | 19.995442 | 0         |
  ✔ When I request a travel time matrix I should get
      |   | a | b  | c  | d  |
      | a | 0 | 10 | 30 | 60 |
  ✔ When I request a travel distance matrix I should get
      |   | a | b        | c         | d         |
      | a | 0 | 9.997721 | 19.995442 | 29.993164 |
  ✔ When I request a travel time matrix I should get
      |   | a  |
      | a | 0  |
      | b | 10 |
      | c | 30 |
      | d | 60 |
  ✔ When I request a travel distance matrix I should get
      |   | a         |
      | a | 0         |
      | b | 0         |
      | c | 9.997721  |
      | d | 29.993164 |

@TheMarex if you'd give this a review that would be good.

chaupow · 2018-04-19T10:59:15Z

Ok. Trying again.

Ran 5000 100x100 duration matrix requests in us-west using osrm-runner:

node scripts/osrm-runner.js -b -124.94,33.01,-108.95,47.5 -p "/table/v1/driving/{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{}" -f "$.durations[0]" -n 1000

Average time on current `master`:

95.16ms

Average time on current `PR`:

98.97ms

I then ran the first 200 requests on current PR requesting duration and distance tables:

Average time on current `PR` with `annotations=distance`:

11.73s

chaupow · 2018-04-19T14:27:36Z

More numbers on matrices requests with `annotations=distance`

400ms for 10x10 with distances
1.6s for 20x20 with distances
3.8s for 30x30 with distances
11.73s for 100x100 with distances

chaupow · 2018-04-19T20:39:33Z

More numbers on matrices requests with `annotations=distance`

I ran more 100x100 matrix requests but limited the max-distance between coordinates to 20km and ran 1000 queries on LA and 1000 queries on Phoenix:

node scripts/osrm-runner-distancer.js -b -118.3859252,33.770015,-116.90002,34.229970 -p "/table/v1/driving/{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{}?annotations=distance" -f "$.durations[0]" -n 1000 -d 20000 > la-d20000-n1000.out &&  aws s3 cp la-d20000-n1000.out s3://mapbox-eu-west-1/playground/chaupow/

node scripts/osrm-runner-distancer.js -b -118.385925,33.770015,-116.9000,34.22997 -p "/table/v1/driving/{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{};{}?annotations=distance" -f "$.durations[0]" -n 1000 -d 20000 > phoenix-d20000-n1000.out &&  aws s3 cp phoenix-d20000-n1000.out s3://mapbox-eu-west-1/playground/chaupow/

Average query times:

3.73s in LA, 100x100, max distance 20km
3.74s in Phoenix, 100x100, max distance 20km

chaupow · 2018-04-20T08:32:57Z

README.md

@@ -9,7 +9,7 @@ High performance routing engine written in C++14 designed to run on OpenStreetMa
 The following services are available via HTTP API, C++ library interface and NodeJs wrapper:
 - Nearest - Snaps coordinates to the street network and returns the nearest matches
 - Route - Finds the fastest route between coordinates
- Table - Computes the duration of the fastest route between all pairs of supplied coordinates
+- Table - Computes the duration of the fastest route between all pairs of supplied coordinates, and optionally returns distances of these routes.


Maybe just shorten this to
- Table - Computes the duration or distances of the fastest route between all pairs of supplied coordinates

The other services don't list all their options either.

chaupow · 2018-04-20T08:33:20Z

docs/http.md

@@ -222,20 +222,21 @@ curl 'http://router.project-osrm.org/route/v1/driving/13.388860,52.517037;13.397

 ### Table service

-Computes the duration of the fastest route between all pairs of supplied coordinates. Also returns the distances between the coordinate pairs. Note that the distances are not the shortest distance between two coordinates, but rather the distances of the fastest routes.
+Computes the duration of the fastest route between all pairs of supplied coordinates. Optinally, also returns the distances between the coordinate pairs. Note that the distances are not the shortest distance between two coordinates, but rather the distances of the fastest routes.


Typo Optionally

chaupow · 2018-04-20T08:34:17Z

docs/http.md


 In addition to the [general options](#general-options) the following options are supported for this service:

 |Option      |Values                                            |Description                                  |
 |------------|--------------------------------------------------|---------------------------------------------|
 |sources     |`{index};{index}[;{index} ...]` or `all` (default)|Use location with given index as source.     |
 |destinations|`{index};{index}[;{index} ...]` or `all` (default)|Use location with given index as destination.|
+|annotations |`duration` (default), `distance`                  |Return additional table with distances to the response. Whether requested or not, the duration table is always returned.|


duration (default), distance or duration,distance maybe?

chaupow · 2018-04-20T08:36:55Z

docs/http.md

+
+# Returns a 3x3 duration matrix and a 3x3 distance matrix:
+curl 'http://router.project-osrm.org/table/v1/driving/13.388860,52.517037;13.397634,52.529407;13.428555,52.523219&annotations=distance'
+


Ok wait. no. This is confusing. so

annotation=distance and annotation=duration,distance will return the same response?

If yes, and this is intended we should make it clearer. this is confusing.
If yes, and this is not 100% thought through can we discuss?

Hrm - I think the expected thing is that there would only be a distances field for passing annotations=distance and both for annotations=duration,distance, no?

@TheMarex actually maybe you can clarify this. In the comment here: #4990 (comment) I took this to mean that we should always return duration table whether it was asked for or not in the response. That's what I've implemented and what I've documented here.

chaupow · 2018-04-20T10:02:51Z

I ran measurements on @danpat's improvement and compared them 🎉
#5041

What	`distances` PR	`faster-distances` PR
100x100 in `us-west`	`12s`	`5.6s`
100x100 in la max dist 20km	`3.7s`	`800ms`

TheMarex

This looks almost perfect to me. 💯 There are only a few nitpicks we could fix, and some questions. Good work. 👍

TheMarex · 2018-04-20T16:45:20Z

CHANGELOG.md

@@ -1,3 +1,8 @@
+# UNRELEASED
+ - Features:
+    - ADDED: `table` plugin now optionally returns `distance` matrix as part of response [#4990](https://github.com/Project-OSRM/osrm-backend/pull/4990)


distance -> distances (the analog property is also called durations)

TheMarex · 2018-04-20T16:48:02Z

docs/http.md

+
+# Returns a 3x3 duration matrix and a 3x3 distance matrix:
+curl 'http://router.project-osrm.org/table/v1/driving/13.388860,52.517037;13.397634,52.529407;13.428555,52.523219&annotations=distance'
+


Hrm - I think the expected thing is that there would only be a distances field for passing annotations=distance and both for annotations=duration,distance, no?

TheMarex · 2018-04-20T17:12:35Z

features/testbot/duration_matrix.feature

@@ -0,0 +1,492 @@
+@matrix @testbot


Love the renaming, good by "distance" table. 😹

TheMarex · 2018-04-20T17:13:32Z

features/testbot/duration_matrix.feature

+            | a | 0  | 10 |
+            | b | 10 | 0  |
+
+    @ch


Hrm do you know why this is marked CH only?

These tests fail on the mld profile 😬 . Going to ticket out as a bug!

TheMarex · 2018-04-20T17:13:39Z

features/testbot/duration_matrix.feature

+            | c |    |    | 0  | 10 |
+            | d |    |    | 10 | 0  |
+
+    @ch


TheMarex · 2018-04-20T17:27:45Z

src/engine/routing_algorithms/many_to_many_ch.cpp


    relaxOutgoingEdges<REVERSE_DIRECTION>(
        facade, node, target_weight, target_duration, query_heap, phantom_node);
 }

 } // namespace ch

+void retrievePackedPathFromSearchSpace(NodeID middle_node_id,


Nitpick: middle_node_id can be const.

TheMarex · 2018-04-20T17:29:44Z

src/engine/routing_algorithms/many_to_many_ch.cpp

+                        const DataFacade<ch::Algorithm> &facade,
+                        const std::vector<PhantomNode> &phantom_nodes,
+                        const std::vector<std::size_t> &target_indices,
+                        const unsigned row_idx,


Nitpick: We try to avoid abbreviations like idx and prefer index.

TheMarex · 2018-04-20T17:30:57Z

src/engine/routing_algorithms/many_to_many_ch.cpp

+                        const unsigned row_idx,
+                        const std::size_t source_index,
+                        const PhantomNode &source_phantom,
+                        const unsigned number_of_targets,


We can make number_of_targets and row_index a std::size_t for consistency (no real impact on performance or anything just a style thing).

TheMarex · 2018-04-20T17:53:47Z

src/engine/routing_algorithms/many_to_many_ch.cpp

+{
+    std::vector<NodeID> packed_leg;
+
+    for (unsigned column_idx = 0; column_idx < number_of_targets; ++column_idx)


Could be simplified to for (auto column_index : util::irange<std::size_t>(0, number_of_targets))

TheMarex · 2018-04-20T18:38:16Z

test/nodejs/table.js

+            coordinates: [three_test_coordinates[0], three_test_coordinates[1]],
+            sources: [0],
+            destinations: [0,1],
+            annotations: [annotation.slice(0,-1)]


The fact that our annotations parameters uses singular over plural is one of my biggest API regrets. 🙈

Release OSRM 5.18.0 Changes from 5.17.0: - Features: - ADDED: `table` plugin now optionally returns `distance` matrix as part of response [Project-OSRM#4990](Project-OSRM#4990) - ADDED: New optional parameter `annotations` for `table` that accepts `distance`, `duration`, or both `distance,duration` as values [Project-OSRM#4990](Project-OSRM#4990) - Infrastructure: - ADDED: Updated libosmium and added protozero and vtzero libraries [Project-OSRM#5037](Project-OSRM#5037) - CHANGED: Use vtzero library in tile plugin [Project-OSRM#4686](Project-OSRM#4686) - Profile: - ADDED: Bicycle profile now returns classes for ferry and tunnel routes. [Project-OSRM#5054](Project-OSRM#5054) - ADDED: Bicycle profile allows to exclude ferry routes (default to not enabled) [Project-OSRM#5054](Project-OSRM#5054)

ghoshkaj added the Work In Progress label Apr 2, 2018

ghoshkaj self-assigned this Apr 2, 2018

ghoshkaj force-pushed the distances branch from b4750b1 to 514d546 Compare April 2, 2018 04:41

danpat mentioned this pull request Apr 4, 2018

Return distance for table queries #1353

Closed

ghoshkaj force-pushed the distances branch 2 times, most recently from 770e531 to f4ebd2d Compare April 5, 2018 12:39

danpat mentioned this pull request Apr 5, 2018

Distance support for table service #2764

Closed

ghoshkaj force-pushed the distances branch from d04b9cb to fec6b08 Compare April 6, 2018 14:00

ghoshkaj changed the base branch from master to implement-cache April 6, 2018 14:09

ghoshkaj force-pushed the distances branch 3 times, most recently from fb7f3bb to 40736a5 Compare April 6, 2018 20:08

ghoshkaj force-pushed the implement-cache branch 5 times, most recently from 3bfdaf3 to 729a399 Compare April 8, 2018 23:40

ghoshkaj requested a review from TheMarex April 9, 2018 01:48

ghoshkaj force-pushed the distances branch 2 times, most recently from e3106c9 to 582ed3b Compare April 9, 2018 01:54

ghoshkaj force-pushed the distances branch from 82251dd to 00582cf Compare April 19, 2018 15:35

ghoshkaj force-pushed the distances branch from 5705f95 to 81b0756 Compare April 20, 2018 02:47

chaupow reviewed Apr 20, 2018

View reviewed changes

miccolis added Review and removed Work In Progress labels Apr 20, 2018

TheMarex approved these changes Apr 20, 2018

View reviewed changes

TheMarex added Review - In feedback and removed Review labels Apr 20, 2018

ghoshkaj force-pushed the distances branch 3 times, most recently from ca07b47 to 649e0af Compare April 20, 2018 21:06

Unpack paths and return total distance in matrix plugin for CH

5ebc145

ghoshkaj force-pushed the distances branch from 649e0af to 5ebc145 Compare April 20, 2018 21:21

ghoshkaj added Ready To Merge and removed Review - In feedback labels Apr 20, 2018

ghoshkaj merged commit 14860b6 into master Apr 20, 2018

ghoshkaj removed the Ready To Merge label Apr 23, 2018

ghoshkaj mentioned this pull request Apr 23, 2018

Parse table annotations param correctly #5050

Merged

9 tasks

TheMarex added this to the distance-matrix milestone Apr 24, 2018

TheCoolRob mentioned this pull request Apr 24, 2018

Distance matrix API google/or-tools#665

Closed

ghoshkaj mentioned this pull request Apr 25, 2018

Fix/ch distance offsets #5057

Merged

4 tasks

ssuluh mentioned this pull request May 20, 2018

Upgrade to latest OSRM 15.8 osrmnet/osrmnet#47

Closed

4 tasks

danpat mentioned this pull request Sep 5, 2018

Optionally cache CH/MLD edge distances #5197

Closed

6 tasks

danpat mentioned this pull request Oct 29, 2018

Pre-calculate distance values #5251

Merged

6 tasks

DennisOSRM deleted the distances branch November 6, 2022 14:13

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Distances in matrix - CH #4990

Distances in matrix - CH #4990

ghoshkaj commented Apr 2, 2018 •

edited

Loading

ghoshkaj commented Apr 2, 2018 •

edited

Loading

TheMarex commented Apr 3, 2018

ghoshkaj commented Apr 3, 2018

TheMarex commented Apr 3, 2018 •

edited by ghoshkaj

Loading

danpat commented Apr 3, 2018

ghoshkaj commented Apr 3, 2018

ghoshkaj commented Apr 4, 2018

ghoshkaj commented Apr 4, 2018

ghoshkaj commented Apr 5, 2018 •

edited

Loading

ghoshkaj commented Apr 9, 2018

chaupow commented Apr 19, 2018 •

edited by ghoshkaj

Loading

chaupow commented Apr 19, 2018

chaupow commented Apr 19, 2018

chaupow Apr 20, 2018

chaupow Apr 20, 2018

chaupow Apr 20, 2018

chaupow Apr 20, 2018

TheMarex Apr 20, 2018

ghoshkaj Apr 20, 2018

chaupow commented Apr 20, 2018

TheMarex left a comment

TheMarex Apr 20, 2018

TheMarex Apr 20, 2018

TheMarex Apr 20, 2018

ghoshkaj Apr 20, 2018

TheMarex Apr 20, 2018

ghoshkaj Apr 20, 2018

TheMarex Apr 20, 2018

TheMarex Apr 20, 2018

TheMarex Apr 20, 2018

TheMarex Apr 20, 2018

TheMarex Apr 20, 2018

TheMarex Apr 20, 2018

ghoshkaj Apr 20, 2018


		# Returns a 3x3 duration matrix and a 3x3 distance matrix:
		curl 'http://router.project-osrm.org/table/v1/driving/13.388860,52.517037;13.397634,52.529407;13.428555,52.523219&annotations=distance'

Distances in matrix - CH #4990

Distances in matrix - CH #4990

Conversation

ghoshkaj commented Apr 2, 2018 • edited Loading

Issue

Tasklist

Requirements / Relations

ghoshkaj commented Apr 2, 2018 • edited Loading

TheMarex commented Apr 3, 2018

ghoshkaj commented Apr 3, 2018

TheMarex commented Apr 3, 2018 • edited by ghoshkaj Loading

danpat commented Apr 3, 2018

ghoshkaj commented Apr 3, 2018

ghoshkaj commented Apr 4, 2018

ghoshkaj commented Apr 4, 2018

ghoshkaj commented Apr 5, 2018 • edited Loading

ghoshkaj commented Apr 9, 2018

chaupow commented Apr 19, 2018 • edited by ghoshkaj Loading

Average time on current master:

Average time on current PR:

Average time on current PR with annotations=distance:

chaupow commented Apr 19, 2018

More numbers on matrices requests with annotations=distance

chaupow commented Apr 19, 2018

More numbers on matrices requests with annotations=distance

Average query times:

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

chaupow commented Apr 20, 2018

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

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghoshkaj commented Apr 2, 2018 •

edited

Loading

ghoshkaj commented Apr 2, 2018 •

edited

Loading

TheMarex commented Apr 3, 2018 •

edited by ghoshkaj

Loading

ghoshkaj commented Apr 5, 2018 •

edited

Loading

chaupow commented Apr 19, 2018 •

edited by ghoshkaj

Loading

Average time on current `master`:

Average time on current `PR`:

Average time on current `PR` with `annotations=distance`:

More numbers on matrices requests with `annotations=distance`

More numbers on matrices requests with `annotations=distance`