OSM node-id's returned by "match" call are suddenly different ?! #6024
Comments
|
To reproduce: this is the url I called: |
|
Sounds like yet another case where the "real" OSM ids overflow the internal 33 bit size. See #6016 for context and pointer to a fix. |
|
What I did to fix it (for good I hope). On my pre-calc machine: pull the 5.24.0 docker image, and recalculate the necessary files + move to them to S3. On my cluster, in my bootstrap script I also pull the 5.24.0 image. That seems to work again. Following this flow, I guess I'm safe ? Or #6016 is not fixed yet in 5.24.0 ? |
|
The fix is not included in 5.24.0. To get the fix, you need to either use the |
|
Hmm, but I ran into problems using the latest docker image. Am I correct that you cannot preprocess an OSM file with version X and then run the backend server with version Y ? |
|
@MathiasVersichele It would help if you said exactly what those problems were. But in general yes, data is not compatible between OSRM versions - in fact, the changelog for #6016 specifically calls out that it breaks the data format. You should re-process the data using the same docker image you intend to run it with. |
|
ok, might be worthwhile to mention this in the tutorial section which describes setting up a server ? |
|
@MathiasVersichele OSRM will emit an error message like
When you mix up versions. If you're running the latest, unreleased code, then you're on your own. |
|
Ok, fair enough, didn't catch that message as I deployed it in a EMR cluster. Thanks for the responses guys. |
|
Reopening this. I preprocessed osm files with v5.24.0. Then I set up my service as such: So I fixed the version to make sure I didn't have weird node-id's anymore in my response. Somehow, my responses contain them again. For example, a route in France: Some of the returned node-id's: I read about an overflow bug. But I thought fixing my version would keep my service stable. Seems like it doesn't. Hope there's an easy solution for this, because I can't end up having this issue on and on in a production environment... |
|
@MathiasVersichele The fix for correctly numbering node IDs only exists in v5.25.0: https://github.com/Project-OSRM/osrm-backend/master/CHANGELOG.md#L11 |
|
So:
Can I rest assured that this won't happen again ? Because v5.24.0 used to work... |
|
@MathiasVersichele v5.24.0 still works if you use old OSM data - however OSM now has node IDs that are larger than OSRM 5.24.0 can handle, so you need to update to 5.25.0. The fix included in 5.25.0 doubled the space we allocate for node ID integers, so if you look at these charts, you can project when we'll hit the new limit and will need to bump this ID field size again:
|
|
To be sure, I'd do it like this: |
|
@MathiasVersichele Yes, that looks reasonable. |
|
ok, closing, thx for helping me out |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi. I'm using your map-matching service for an OSM road network that contains all of France. I downloaded the snapshot of the 5th of April of this year. I created the necessary files by following the tutorial:
I saved all files into a zip for later use. In my project (that I run on an Amazon EMR cluster) I have a bootstrap script which does:
In my project, this worked fine on the 21st of April. However, today I see something really weird. The match calls return data and state that they are successful, but the returned node-id's seem scrambled up. Some of them just don't exist, others exist but are not part of a road. How could it be that the returned id's don't belong to roads or just don't exist?
An example:
This contains the node-id: 10952294855
This node doesn't exist in my OSM source file, and doesn't exist right now on OSM: https://www.openstreetmap.org/node/10952294855.
Has the code somehow been updated in the repo over the last few days ? Because a few days ago this worked fine... I am completely stuck by this weird issue, and I'm working on strict commercial deadlines, so any help is greatly appreciated !!
The text was updated successfully, but these errors were encountered: