In 2.0.x you'd get the label 1 for a postgis field of type numeric and value 1.
In 2.1.x you get the label 1.0 instead.
Also, a value of 1.00001 gets rendered literally in 2.0 but becomes 1.0000100000000001 in 2.1.x.
Sounds like an excess of precision in there. Is there any plan for controlling that ?
I see the difference is between using stringstream (granted, it's slow) and boost::spirit::karma.
I made a simple script to compare the two, here's the outcome so far:
I belive the problem is with the precision() function we use in double_policy. ACcording to docs that's the max number of decimals to print, not the max number of significant digits.
Alright, by computing the precision dinamically (based on number of non-decimal digits in the original number) gives comparable results. I'ms till not sure about the scientific notation, which was engaged in 2.0.0 for numbers bigger than a given threshold. Ideas ?
This is what I have so far:
More comparison, where you see the boundaries over which (min/max) numbers start to get rendered in scientific notation with the iostream approach: http://strk.keybit.net/tmp/report2.txt
I may replicate also that part, if you think it makes sense.
I add a full report showing both stringstream output (as of mapnik-2.0.0), current karma-based output (in current mapnik-2.1.x) and a new karma-based output with precision computed based on the actual number:
yes, good analysis. See also #1314, #1207.
Thanks for the pointers !
For now I will complete my patch and turn into a pull request, producing 2.0.x output.
Do I get it right there are no tests currently ?
Parametrization I think will need to be introduced in 2.2.x, but this one (backward compatibility) is for 2.1.x
Fix float data conversion to string
Fixes precision digits, closing #430
Also avoids forcing a trailing '.0', closing #1627
Backward compatibility is partially fixed by pull requests #1631 (for 2.1 branch) and #1632 (for master).
It's partial because in 2.0.x we also got scientific notation for floating points, while we're not doing that in 2.1.x and up.
Anyway this specific ticket was for the trailing .0, which is fixed by those pulls.