Skip to content

Backward compatibility: label for numeric fields get a decimal .0 added #1627

Closed
strk opened this Issue Dec 5, 2012 · 9 comments

2 participants

@strk
strk commented Dec 5, 2012

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.

@strk
strk commented Dec 5, 2012

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 ?

@strk
strk commented Dec 5, 2012

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:

       karma: 1.0
stringstream: 1

       karma: 0.1
stringstream: 0.1

       karma: 1.0000100000000001
stringstream: 1.00001

       karma: 10000000000.0
stringstream: 10000000000

@strk
strk commented Dec 5, 2012

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.

@strk
strk commented Dec 5, 2012

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:
http://strk.keybit.net/tmp/report.txt

@strk
strk commented Dec 5, 2012

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.

@strk
strk commented Dec 5, 2012

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:
http://strk.keybit.net/tmp/report_full.txt

@springmeyer
Mapnik member

yes, good analysis. See also #1314, #1207.

@strk
strk commented Dec 6, 2012

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

@strk strk added a commit to strk/mapnik that referenced this issue Dec 6, 2012
@strk strk Fix float data conversion to string
Fixes precision digits, closing #430
Also avoids forcing a trailing '.0', closing #1627
19522ac
@strk strk added a commit to strk/mapnik that referenced this issue Dec 6, 2012
@strk strk Fix float data conversion to string
Fixes precision digits, closing #430
Also avoids forcing a trailing '.0', closing #1627
b51b357
@strk
strk commented Dec 6, 2012

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.

@strk strk closed this Dec 6, 2012
@PetrDlouhy PetrDlouhy added a commit to PetrDlouhy/mapnik that referenced this issue Aug 22, 2013
@strk strk Fix float data conversion to string
Fixes precision digits, closing #430
Also avoids forcing a trailing '.0', closing #1627
08ac3d7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.