Truncated OSM node IDs on Raspberry Pi 4 with 64bit OS

[matlen]

Issue

I installed osrm-backend v5.28.0 on my Raspberry Pi 4 running Debian Bullseye in the 64 bit version. So in theory, the system should be able to deal with OSM IDs higher than 4294967295. However, I noticed that the IDs get truncated anyway. Is there anything I can do in the compilation to improve this?

Steps to reproduce

An example is the query https://routing.openstreetmap.de/routed-bike/route/v1/driving/9.98356,53.59720;9.98357,53.59614?alternatives=true&overview=full&steps=true&annotations=true, which yields the following output. Pay attention to the OSM node ID 11455378494 (printed bolt).

{"code":"Ok","routes":[{"geometry":"oecfIq~|{@ja?Lb@xBF","legs":[{"steps":[],"summary":"","weight":48.7,"duration":48.7,"annotation":{"metadata":{"datasource_names":["lua profile"]},"datasources":[0,0,0],"weight":[10.3,6.3,30.5],"nodes":[1490604279,1492031044,11455378494,5594295924],"distance":[42.738124380,13.967053929,67.826637997],"duration":[10.3,6.3,30.5],"speed":[4.1,2.2,2.2]},"distance":124.5}],"weight_name":"duration","weight":48.7,"duration":48.7,"distance":124.5}],"waypoints":[{"hint":"Un8ugO4W0oQjAAAAZwAAAOgAAAAAAAAANQ9rQdfzKkJVVodBAAAAACMAAABnAAAA6AAAAAAAAACSEAAAtVeYABDUMQNIVpgAENQxAwMAPwuDikf9","distance":24.178288347,"name":"Tarpenbekstraße","location":[9.983925,53.5972]},{"hint":"8BbShPO8Xo4xAQAAhgAAAD8AAAAAAAAAPaeHQuz9bEEOeV9BAAAAADEBAACGAAAAPwAAAAAAAACSEAAA4VaYAOnPMQNSVpgA7M8xAwEAbwuDikf9","distance":9.478472376,"name":"","location":[9.983713,53.596137]}]}

When I run the same query on my Raspi, the result looks like this. The OSM ID got truncated to 1.145537849e+10, which is 11455378490.

{"code":"Ok","routes":[{"geometry":"oecfIq~|{@ja?Lb@xBF","legs":[{"steps":[],"summary":"","weight":27.6,"duration":27.6,"annotation":{"metadata":{"datasource_names":["lua profile"]},"datasources":[0,0,0],"weight":[7.7,3.1,15.2],"nodes":[1490604279,1492031044,1.145537849e+10,5594295924],"distance":[42.73812438,13.96705393,67.826638],"duration":[7.7,3.1,15.2],"speed":[5.6,4.5,4.5]},"distance":124.5}],"weight_name":"duration","weight":27.6,"duration":27.6,"distance":124.5}],"waypoints":[{"hint":"whQBgB0aCYAaAAAATQAAAN0AAAAAAAAANQ9rQdfzKkJVVodBAAAAABoAAABNAAAA3QAAAAAAAAAjAAAAtVeYABDUMQNIVpgAENQxAwMAPwu8CQRc","distance":24.17828835,"name":"Tarpenbekstraße","location":[9.983925,53.5972]},{"hint":"HxoJgD4aCYCYAAAAhgAAAB8AAAAAAAAAPaeHQuz9bEEOeV9BAAAAAJgAAACGAAAAHwAAAAAAAAAjAAAA4VaYAOnPMQNSVpgA7M8xAwEAbwu8CQRc","distance":9.478472377,"name":"","location":[9.983713,53.596137]}]}

Interestingly, the OSM ID 5594295924 is also exceeding uint32, but is shown correctly. So it seems to switch to scientific number representation as soon as it exceeds 1e10.

Any hint would be appreciated. Thanks in advance!

[tumik]

I see the same issue running on PC.
Running almost up to date version, git hash 31e31a6 also on Debian Bullseye, amd64 platform so not related to Raspberry Pi.
I have not tested if pull request #5968 would affect this but it seems to touch some related code parts.

Could be related to different flatbuffer versions, seems like the flatbuffer project has had somewhat recent changes related to outputting in scientific notation.

Just to provide another example, my query is:
https://routing.openstreetmap.de/routed-car/match/v1/car/23.775705,61.49838;23.77577,61.498386?timestamps=1705432448;1705432458&overview=false&annotations=nodes&steps=false

On routing.openstreetmap.de the first node ID returned is: 10171397496
On my local build the first node ID returned is 1.01713975e+10

http://router.project-osrm.org/ provides the correct ID, same as https://routing.openstreetmap.de.