[geos-devel] WKT Precision

Wed Jan 6 09:23:14 PST 2021

> On Jan 6, 2021, at 9:20 AM, Martin Davis <mtnclimb at gmail.com> wrote:
> 
> Right, I have now seen that std::setprecision switches to scinot if the precision is less than the magnitude of the number.  Very much not ideal IMO.  So some way of using std::fixed might be needed to solve this. (Not a problem if decimalPlaces is the default 16 though, I think - numbers > 10^16 will still be in scinot, but that should be rare).
> 
> So agreed, your PR seems like the right direction.  Does it work with negative numbers and numbers << 1 ?

No, on re-reading it's still bogus for small numbers. And negatives. I'm surprised there's not a standard c++ way to get something like std::fixed without the trailing zeroes.

P

> 
> On Wed, Jan 6, 2021 at 9:01 AM Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> For interests sake here's a little program that shows the difference between std::fixed and the default aka std::defaultfloat. Note that defaultfloat (which sort of does "what we want" from a trailing zero point of view), also does sigfigs when restricted to a particular precision and scientific notation. 
> 
> I think if changes are to be made, I like the idea of doing
> - default, take the C++ defaults, don't apply anything. this is a change to current behaviour, which applies a default precision
> - if precision is specified, try to do a trimmed, fixed number of decimals output, which is kind of what my PR does
> P.
> 
> 
> 
> > On 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
> > _______________________________________________
> > 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
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel