<div dir="ltr"><div><br></div>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.<div><br></div><div>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.<div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 6, 2021 at 10:25 AM Martin Davis <<a href="mailto:mtnclimb@gmail.com">mtnclimb@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Is it possible the problem is the use of std:fixed ? (Which is invoked if the trim option = FALSE, which is the default).</div><div><br></div><div>Currently in WKTWriter.writeNumber there is this code (and the defaults invoke fixed precision):</div><div><br></div><div>if(! trim) {<br></div> ss << std::fixed;<br> }<br><div> ss << std::setprecision(decimalPlaces >= 0 ? decimalPlaces : 0) << d;</div><div><br></div><div>This results in the following (as noted on the GeoSwift issue)</div><div><br></div><div>POINT (-0.4225977 46.3406448). ==>. POINT (-0.4225977000000000 46.3406447999999997)</div><div><br></div><div>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.</div><div><br></div><div>Also, running reducePrecision causes problems, again I suspect due to to imprecise FP representation:</div><div><br></div><div>bin/geosop -a "Point (-0.4225977 46.3406448)" -f wkt reducePrecision 100<br></div><div>POINT (-0.4200000000000000 46.3400000000000034)<br></div><div><br></div><div>If the std::fixed setting is dropped, the output looks more reasonable:<br></div><div><br></div><div>POINT (-0.4225977 46.3406448). ==>. POINT (-0.4225977234 46.3406448)</div><div><br></div><div>Check that all input sig digits are shown:</div><div><br></div><div>POINT (-0.4225977234 46.3406448) ==> POINT (-0.4225977234 46.3406448)<br></div><div><br></div><div>Reduced precision displays as expected:</div><div>bin/geosop -a "Point (-0.4225977 46.3406448)" -f wkt reducePrecision 100<br>POINT (-0.42 46.34)<br></div><div><br></div><div><br></div><div>Is the "trim" option needed at all?</div><div><br></div><div>On Tue, Jan 5, 2021 at 3:41 PM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
What do people think is the best practice for outputing WKT precision?<br>
</blockquote></div></div>
_______________________________________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/geos-devel</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Andrew Bell<br><a href="mailto:andrew.bell.ia@gmail.com" target="_blank">andrew.bell.ia@gmail.com</a></div></div></div></div>