[geos-devel] WKT Precision

[Martin Davis]

The improvement I'm suggesting can be obtained by setting
WKTWriter.setTrim(true) before use.  I think this should become the
default, but it lets downstream projects work around this issue now.

On Wed, Jan 6, 2021 at 7:54 AM Martin Davis <mtnclimb at gmail.com> wrote:

> 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/d4e00284/attachment.html>