Nearest Service returning an incorrect node ID of 0

[chaupow]

When requesting \nearest we often find the annotation of nodes returning an incorrect node ID of 0.
We're seeing a node ID 0 in about 17% of all requests.

Example:

https://router.project-osrm.org/nearest/v1/driving/13.5077,52.5643

Response:

{
  "waypoints": [
    {
      "nodes": [0, 536784367],
      "hint": "RdUOif___38BAAAAYgAAAAAAAACyAAAAJ1ZePxQrG0IAAAAAtpaPQgEAAAAxAAAAAAAAAFkAAABvpgAAcRzOAE8RIgN0HM4ATBEiAwAA7w4PM8D1",
      "distance": 0.39091554070843676,
      "name": "Falkenberger Chaussee",
      "location": [13.507697, 52.564303]
    }
  ],
  "code": "Ok"
}

Expected Behaviour

Instead of node ID 0, we would expect 536784687

[chaupow]

capturing per chat with @daniel-j-h:

https://github.com/Project-OSRM/osrm-backend/blob/master/include/engine/api/nearest_api.hpp#L47
this is where you need to go in and debug it

[Gp2mv3]

Hey,
We changed slightly the code of node retrieval here: https://github.com/cParkApp/osrm-backend/tree/fix-OSM-nodes
We are testing internally but our first tests are working fine.

Don't hesitate to try our code.

[yfyf]

I'm also observing the behaviour that around ~10% of the responses contain an invalid 0 node id. Additionally, some responses contain only a single node (which can't define a waypoint, right?)

I've tried running @Gp2mv3's fix-OSM-nodes branch and it indeed resolves the issue - it always returns 2 or more valid nodes.

However, it was my understanding that originally the Nearest service returned the two nodes which correspond to the nearest segment. With the patch, it seems to simply return all nodes that define the whole (nearest) way?

[Gp2mv3]

However, it was my understanding that originally the Nearest service returned the two nodes which correspond to the nearest segment. With the patch, it seems to simply return all nodes that define the whole (nearest) way?

Indeed, that's exactly the behaviour I wanted. It seems more logical, no?

[yfyf]

Indeed, that's exactly the behaviour I wanted. It seems more logical, no?

Hmm, not sure, because at least in my usecase I'm interested in identifying the actual closest segment, not the whole way (which might be huge). Returning all the nodes for the way is also kind of redundant, because the caller might as well get just the way_id instead and lookup the nodes themselves.

[RuiLoureiro]

I'm still observing this behaviour. Any new information on this issue?