Nearest api returning node with id 0

[moboge]

Issue

I have en issue where the nearest api returns a node with id 0.

Reproduce

1. make the following call
   https://router.project-osrm.org/nearest/v1/driving/5.559843314527809,51.699737313452786?number=1

2. The api returns

{
  "code": "Ok",
  "waypoints": [
    {
      "hint": "GOgtgP___38FAAAADwAAAAAAAABxAAAArMVeQB7JyUAAAAAA12eWQgUAAAAPAAAAAAAAAHEAAABRCwEAdNZUAHzgFAMj1lQAGeAUAwAAXwcHy9lF",
      "nodes": [0, 43566576],
      "distance": 12.358071624,
      "name": "Kloosterhof",
      "location": [5.559924, 51.699836]
    }
  ]
}

Investigating the location on a map clearly indicates where the location should snap in to the road network. The location snaps into a one-way road and I think that is where the problem is. The location should snap in to the segment between node 3524555540 and node 43566576.
The road segment is one-way directed from node 43566576 to node 3524555540.
In the reply, the node 43566576 is the second node (to node) which is against the direction of the road.

If I increase the number in the api call to 4 instead, the api returns the nodes 43566576 (as the from node) and node 3524555540 (as the to node) as the fourth reply - so following the direction of the road segment.

According to the map, as the snap-in segment is one-way, it makes sense that you cannot go from node 3524555540 to node 43566576 as this is against the direction of driving. I assume this is why the first reply does not give this reply, but it should never return the node with id 0.
Either it should return 43566576 as first node and 3524555540 as second node or interchange the two node ids.

I have solved this issue myself by changing the nearest_api.hpp code by adding the following (see attachment). But I think it would make sense to get this fixed in the master

[jcoupey]

Thanks for reporting and hinting to a fix. This has been a known issue for quite some time. See #5415 where another potential fix is linked in the comments.

It would be great to compare changes from there and the one you suggest to decide on the best fix and have it as a PR.

[muteebali]

Pull Request - The issue reported by @moboge has been resolved. After fixing it, the nearest API was called for the location [5.559859, 51.699741]. Please see the attached results.

FYI @jcoupey