[OSRM-talk] Getting OSMNodeIDs in OSRM

[Daniel Patterson]

Hi Kerrick,

  Yup, the node ids are renumbered to pack them more densely and ensure that values fit inside an unsigned int (32 bits).

  The mapping *is* written to the `.nodes` file though, here:

https://github.com/Project-OSRM/osrm-backend/blob/d189339495e223a6ceea21a73bb7e434775172fa/src/extractor/extractor.cpp#L550-L561 <https://github.com/Project-OSRM/osrm-backend/blob/d189339495e223a6ceea21a73bb7e434775172fa/src/extractor/extractor.cpp#L550-L561>

  when this file is later read, we only load the coordinates from it, so the OSM values are there, but not used:

https://github.com/Project-OSRM/osrm-backend/blob/d189339495e223a6ceea21a73bb7e434775172fa/include/engine/datafacade/internal_datafacade.hpp#L116-L129 <https://github.com/Project-OSRM/osrm-backend/blob/d189339495e223a6ceea21a73bb7e434775172fa/include/engine/datafacade/internal_datafacade.hpp#L116-L129>

  here, you could add the OSM node values to a new array, then you'd have the lookup table you need to map the NodeIDs you have to the original OSM values.

  This will require extra RAM, which may or may not be a problem for you.

daniel
  

> On Feb 1, 2016, at 9:03 AM, Kerrick Staley <kstaley at lyft.com> wrote:
> 
> I want to create a binary that will take an input lat/long and give the two OSMNodeIDs representing the nearest road segment. I was able to hack something together using NearestPhantomNodes in the OSRM codebase, but I can't figure out how to go from the NodeIDs in the PhantomNode to OSMNodeIDs.
> 
> It looks like the NodeID -> OSMNodeID mapping is dropped in osrm-extract/osrm-prepare. Is this the case? Can I use the .osrm or .osrm.nodes file to re-build the mapping?
> 
> Thanks,
> Kerrick
> 
> _______________________________________________
> OSRM-talk mailing list
> OSRM-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osrm-talk/attachments/20160201/f541d132/attachment.html>