[geos-devel] WKT Precision

Martin Davis mtnclimb at gmail.com
Wed Jan 6 07:54:02 PST 2021


Well, yes.  The current default behaviour seems really unpleasant:

POINT (-0.4225977 46.3406448). ==>. POINT (-0.4225977000000000
46.3406447999999997)

bin/geosop -a "Point (-0.4225977 46.3406448)" -f wkt reducePrecision 100
POINT (-0.4200000000000000 46.3400000000000034)

I agree with Andrew Bell - there is no way GEOS should be trying to
outsmart the C++ language.  And add to that, that setting output precision
is a perilous hack, since rounding/truncating data pointwise can result in
invalid topology.

Not saying get rid of the setRoundingPrecision, since it's the user's
decision. But the default should be to just output "full" precision (as
decided by the standard floating-point output routines, which know about
weird things like IEEE-754 guard digits). And forget about trimming, since
the standard output seems to do that just fine.





On Wed, Jan 6, 2021 at 7:43 AM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

> 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
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20210106/3f8adc21/attachment-0001.html>


More information about the geos-devel mailing list