Fix JSON rendering of large OSM IDs and handle NaN/Infinity gracefully

[afarber]

Issue

Fixes #7016

This PR addresses the issue where large OSM node IDs (exceeding 10 billion as of August 2025) are rendered in scientific notation (e.g., 11117421192 becomes 1.111742119e+10) or lose precision in JSON responses.

Additionally, this PR improves robustness by outputting null for NaN/Infinity values instead of producing invalid JSON ("nan" or "inf"), since BOOST_ASSERT is disabled in Release builds.

Changes

• Detect non-negative whole numbers in the JSON renderer and format them as integers
• Handle NaN and Infinity gracefully by outputting null (valid JSON)
• Add unit tests for large OSM IDs, floats, and edge cases

Tasklist

• CHANGELOG.md entry (How to write a changelog entry)
• update relevant Wiki pages
• add tests (see testing documentation)
• review
• adjust for comments

Requirements / Relations

Related to PR #7096 which has been pending review since January 2025. This PR provides a more robust solution with additional NaN/Infinity handling and improved test coverage.

[afarber]

Hi @DennisOSRM and all, happy new year!

The idea of my fix is to check if the uint64_t value (which is implicitly converted to double when stored in json::Number) is below 2^53.

If it is, then we can be sure nothing was lost during the conversion, and we can safely print it as an integer without scientific notation.

Additionally, this PR handles NaN/Infinity gracefully by outputting null instead of invalid JSON strings like "nan" or "inf".

Below is a screenshot of me successfully smoke testing Berlin data (which has node IDs > 10 billion) using Docker on Ubuntu 25.04:

wget -O berlin-latest.osm.pbf http://download.geofabrik.de/europe/germany/berlin-latest.osm.pbf
sudo snap install docker
  
sudo docker build -t osrm-fix -f docker/Dockerfile .
sudo docker run -t -v "${PWD}:/data" osrm-fix osrm-extract -p /opt/car.lua /data/berlin-latest.osm.pbf
sudo docker run -t -v "${PWD}:/data" osrm-fix osrm-partition /data/berlin-latest.osrm
sudo docker run -t -v "${PWD}:/data" osrm-fix osrm-customize /data/berlin-latest.osrm
sudo docker run -d -p 5000:5000 -v "${PWD}:/data" osrm-fix osrm-routed --algorithm mld /data/berlin-latest.osrm

The test URL: http://127.0.0.1:5000/match/v1/driving/13.416270,52.526382;13.416849,52.526115;13.416849,52.525750;13.416538,52.525430?annotations=nodes

[afarber]

Hi @DennisOSRM ready for review. I had to update the macOS version in CI because of the:

[Copilot]

Pull request overview

This PR fixes JSON rendering of large OpenStreetMap (OSM) node IDs (exceeding 10 billion) that were previously displayed in scientific notation (e.g., 1.111742119e+10 instead of 11117421192), and adds graceful handling for NaN/Infinity values by outputting null instead of invalid JSON strings.

Key changes:

• Modified the JSON Number renderer to detect non-negative whole numbers up to 2^53 (max exact double precision) and format them as integers without scientific notation
• Replaced BOOST_ASSERT with runtime checks that output null for NaN/Infinity values
• Added comprehensive test coverage for large OSM IDs, float values, edge cases, and NaN/Infinity handling

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
include/util/json_renderer.hpp	Implements integer detection logic for non-negative whole numbers and NaN/Infinity handling; removes BOOST_ASSERT in favor of graceful error handling
unit_tests/util/json_render.cpp	Adds comprehensive test cases covering large OSM IDs (up to 2^53), float formatting, edge cases (negative zero, large floats), and NaN/Infinity in various contexts
CHANGELOG.md	Documents the fix in the changelog under the Misc section
.github/workflows/osrm-backend.yml	Updates macOS x64 runner from macos-13 to macos-15-intel

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[DennisOSRM]

Looking good. Clean and simple change

[afarber]

Thanks for the approve, please merge (I can not merge myself)