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...@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 <mtncl...@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 <pram...@cleverelephant.ca> wrote:
>
> What do people think is the best practice for outputing WKT precision?
> _______________________________________________
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
>
> --
> Andrew Bell
> andrew.bell...@gmail.com
> _______________________________________________
> geos-devel mailing list
> geos-devel@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
_______________________________________________
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
