Possible to specify a start/endpoint's osm way id? about osrm-backend HOT 12 CLOSED

Please elaborate a bit on what you mean by "that allowed the request to specify which osm way the point is on?". Would you like to get the ID of the way as it is in the OSM database?

from osrm-backend.

For most situations specifying a lat/lon that I know lies on an osm way is fine, but what happens when there are colinear ways at that point? Or if there was a bridge crossing the intended road at exactly (or very nearly exactly) that point? Then the stated start position would be ambiguous. It could mean the user is starting from the bridge or from the road underneath the bridge, which could give very different results.

Being able to specify which osm way id to start from would remove this ambiguity.

from osrm-backend.

good point. on the other hand, this is not very different from placing the start marker right between two ways; it's not clear where to start, but simply moving the start point a little resolves the ambiguity.

from osrm-backend.

Indeed, but I'm not talking about using this in an interactive context. I, for example, am prototyping a gps trace / route analyzer, where the "points" aren't manually placed points but gps breadcrumbs and I need to be able to micromanage at what point on the graph a point is interpreted as.

For the moment I can probably get away with the ambiguity, because such occurrences should hopefully be rare.

from osrm-backend.

perhaps you can use the previous and next gps point to decide what way the point is on in case of ambiguity.

from osrm-backend.

Sure, there are a few ways I can attempt to infer the right osm way to use, but I'd still need a way of communicating to OSRM which way it should start from.

from osrm-backend.

makes sense. although if you can infer the way, then you can potentially adjust the start marker to make sure there's no ambiguity, and osrm select the right way... probably not practical though :-)

from osrm-backend.

another interesting use for this feature would be to make it easier to write automated tests. it might be easier to specify and read test that include way id or even street adresses than x,y coordinates.

from osrm-backend.

The way id is left out for two reasons. First, it bloats the data. If there are several more or less equal candidates for a start point then one is selected. Using a routing engine for map matching problems may be the wrong hammer for the screw. The second reason for leaving out the id is the fact that OSM data is a moving target. IDs come and go. There is no guarantee at all.

from osrm-backend.

"Using a routing engine for map matching problems may be the wrong hammer for the screw."

Possibly, but either way I will need a way to determine to what extent one point is reachable from another and re-using an existing system for this seems like a better idea than rolling my own dodgy one full of dodgy logical oversights.

"The second reason for leaving out the id is the fact that OSM data is a moving target. IDs come and go."

The intention would be to use OSRM alongside an osm2pgsql postgres database that's updated in parallel with the same data snapshots, so that wouldn't be a problem.

from osrm-backend.

FYI I've managed to hack this functionality into my own branch for the time being by sticking the way id into the various nameID fields. For my use I don't need street names. By doing this I've managed to stay within the 16 byte bounds of EdgeBasedGraphFactory::_NodeBasedEdgeData.

In theory the way id is only needed in the NNGrid, so not too much of a punishment. 4 bytes per entry. But of course since the NNGrid is generated from EdgeBasedNodes, I found the most minimally-invasive way of putting this change in was to bring it in everywhere in place of the nameID.

My branch is at https://github.com/risicle/Project-OSRM/tree/osmwayidhack

from osrm-backend.

Just for reference: I made a similar hack for including the original way ids discarding street names. https://github.com/marcsowen/osrm-backend/tree/wayid_descriptor

from osrm-backend.