Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix json rendering of large osm ids #7096

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

imannamdari
Copy link

@imannamdari imannamdari commented Jan 12, 2025

Issue

Fix #7016

Tasklist

Requirements / Relations

Link any requirements here. Other pull requests this PR is based on?

Copy link
Contributor

@afarber afarber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -54,7 +54,10 @@ template <typename Out> struct Renderer
// `fmt::memory_buffer` stores first 500 bytes in the object itself(i.e. on stack in this
// case) and then grows using heap if needed
fmt::memory_buffer buffer;
fmt::format_to(std::back_inserter(buffer), FMT_COMPILE("{:.10g}"), number.value);
if (static_cast<std::uint64_t>(number.value) == number.value)
fmt::format_to(std::back_inserter(buffer), FMT_COMPILE("{}"), static_cast<std::uint64_t>(number.value));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the if/else block really needed? Can't a single line below handle the big integer number up to 18446744073709551615 (which is 2^64-1)?

fmt::format_to(std::back_inserter(buffer), FMT_COMPILE("{}"), static_cast<std::uint64_t>(number.value));

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, nevermind, I see that it would break the fractional numbers

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly. For floating-points there gonna be problems.
The previous approach implemented before this commit can be found here (and it works fine):

void operator()(const Number &number)

A more robust solution could be separating floats from integers. Instead of Number struct, we can have Float and Integer structs for example. Each with their own json rendering.
However, that's a significant change! :D
If you agree with this approach (separating floats from integers), I can work on it in another pull request.

Copy link
Contributor

@afarber afarber Jan 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dear @DennisOSRM and @SiarheiFedartsou now that CI build is working again, could you please consider merging this fix by @imannamdari ?

In the past week I have tested his fix with map matching and it really seems to fix the problem with large OSM node/way ids.

And please consider adding a new git tag v5.28.1 after the merge?

Because the current tag v5.27.1 is already three years old and it would be nice to set a newer stable source code "checkpoint" for all users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Json_render is not accurate for osm node ID
2 participants