Consistency for null values in table requests

[jcoupey]

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?

[TheMarex]

Could this be due to a difference of snapping behavior across these requests?

Looking at the map here I think this is one of the weird corner cases that we have sometimes with snapping. In this case we have a oneway-deadend:

I'm not sure why our snapping logic does not detect this case though. Needs investigation.