-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Consistency for null values in table requests #4448
Description
I'm currently experiencing a puzzling behaviour with table requests. I'm running v5.8.1 on a geofabrik england extract with CH algorithm but I'm able to reproduce it on the demo server.
I'm typically firing a single table request to decide the order in which locations should be visited based on travel times. Once this is done I issue route requests whenever I want to retrieve distances for the selected routes. To avoid connectivity issues, I always check there is no occurrence of null in the matrix durations, which normally should prevent getting any NoRoute result in subsequent route requests.
Narrowing down to a minimal exemple:
http://router.project-osrm.org/table/v1/car/-0.052343,51.547595;-0.054687,51.547284;-0.054818,51.547440
yields this matrix:
[[0,194.6,194.6],
[201.4,0,0],
[201.4,0,0]]
So far, so good, non-diagonal zeros are due to second and third coordinates being snapped to the same place. Now I expect a 0 duration and distance route for a route request between those, but I get a NoRoute error on:
http://router.project-osrm.org/route/v1/car/-0.054687,51.547284;-0.054818,51.547440
For the table request for those two coordinates only, one would expect to get the sub-matrix from the previous one with second and third row/column (in that case filled with zeros). But here the null value is actually showing up:
http://router.project-osrm.org/table/v1/car/-0.054687,51.547284;-0.054818,51.547440
[[0,null],
[4,0]]
From what I can gather so far, this only happens when including locations that are very close. Could this be due to a difference of snapping behaviour across these requests?