<div dir="ltr">Paul's fine work on adding Ryu [1] finally makes WKTWriter numeric output work as the API implies (i.e. precision means "decimal places" rather than the C-style "significant digits").  This brings GEOS in line with JTS, and more importantly makes it behave in a way that works better for geospatial numeric values.<div><br></div><div>I suggest one further change: make this the default mode for WKTWriter output.<div><br></div><div>Technically, this means that WKTWriter.setTrim(true) will be the default mode (unlike now, where trim=false is the default).</div><div><br></div><div>The effect of this will be to change default output from looking like this:</div><div><br></div><div>bin/geosop -a "Point (1 2)" -f wkt<br></div><div>POINT (1.0000000000000000 2.0000000000000000)</div><div><br></div><div>to this (which is much better IMO)<br></div><div><br></div><div>POINT (1 2)<br></div><div><br><div>Making trim=true mode the default will mean that downstream clients will get sensible behaviour as the default, which should prevent bug reports like GH #375 [2].</div><div><br></div><div>This will have a potential impact on downstream testing, if they are testing exact character output.  Hopefully this won't be too much effort to correct, and is worthwhile, since it avoids baking in tests for undesirable behaviour.  And in any case it seems likely that downstream will always set trim=true anyway, to avoid the kind of issues mentioned in that ticket.</div><div><br></div><div>Furthermore, if this is done then it seems like there is no need for a trim=false mode at all. So we can deprecate and no-op that API method.  <br><div><br></div><div>Comments?</div><div><br></div><div>[1] <a href="https://github.com/libgeos/geos/commit/2376cd6bf5d0743b02b588af17d2e9067c1874de">https://github.com/libgeos/geos/commit/2376cd6bf5d0743b02b588af17d2e9067c1874de</a></div></div></div><div>[2] <a href="https://github.com/libgeos/geos/issues/375">https://github.com/libgeos/geos/issues/375</a></div></div></div>