[geos-devel] WKT Precision

[Paul Ramsey]

For all these reasons and the fact that the current behaviour has existed for a long time and is now baked into downstream (those tests in GeoSwift!!) I'm inclined to just do nothing.

Any objections?

P

> On Jan 6, 2021, at 7:41 AM, Andrew Bell <andrew.bell.ia at gmail.com> wrote:
> 
> 
> 1) This fight really can't be won without implementing all the various things already provided for by a language like C and allowing users to make these choices for themselves.  GDAL, for example, has its own strange logic to do this kind of thing. It's ugly and it's not obvious to a user what's going to happen as it's not well-defined by any documentation.  Some users may want the full precision, and spending a bunch of time figuring out if .999997 is significant or not isn't really the role of a library like GEOS, IMO.  And for some values, scientific notation is what you need. This is why %g exists for printf in C.
> 
> 2) If you're using a text file for your output, you really don't care about size, even if you say you do. Seems like time could be better spent elsewhere unless someone is paying for this functionality.  Someone could certainly reprocess any WKT file to remove digits if they so chose.
> 
> On Wed, Jan 6, 2021 at 10:25 AM Martin Davis <mtnclimb at gmail.com> wrote:
> Is it possible the problem is the use of std:fixed ?  (Which is invoked if the trim option = FALSE, which is the default).
> 
> Currently in WKTWriter.writeNumber there is this code (and the defaults invoke fixed precision):
> 
> if(! trim) {
>         ss << std::fixed;
>     }
>     ss << std::setprecision(decimalPlaces >= 0 ? decimalPlaces : 0) << d;
> 
> This results in the following (as noted on the GeoSwift issue)
> 
> POINT (-0.4225977 46.3406448). ==>. POINT (-0.4225977000000000 46.3406447999999997)
> 
> This carries too much precision, obviously.  I think it might be exposing the IEEE-754 guard digits unnecessarily.  FP output is notoriously tricky, and I suspect it's better to let C++ just do the right thing.
> 
> Also, running reducePrecision causes problems, again I suspect due to to imprecise FP representation:
> 
> bin/geosop -a "Point (-0.4225977 46.3406448)" -f wkt reducePrecision 100
> POINT (-0.4200000000000000 46.3400000000000034)
> 
> If the std::fixed setting is dropped, the output looks more reasonable:
> 
> POINT (-0.4225977 46.3406448). ==>. POINT (-0.4225977234 46.3406448)
> 
> Check that all input sig digits are shown:
> 
> POINT (-0.4225977234 46.3406448) ==> POINT (-0.4225977234 46.3406448)
> 
> Reduced precision displays as expected:
> bin/geosop -a "Point (-0.4225977 46.3406448)" -f wkt reducePrecision 100
> POINT (-0.42 46.34)
> 
> 
> Is the "trim" option needed at all?
> 
> On Tue, Jan 5, 2021 at 3:41 PM Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> 
> What do people think is the best practice for outputing WKT precision?
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
> 
> 
> -- 
> Andrew Bell
> andrew.bell.ia at gmail.com
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel