<div dir="ltr">The relevant code is in GeometryPrecisionReducer.cpp, around line 72.  It can be paraphrased as:<div><br></div><div>geom_reduced = reduce_coordinate_precision(geom)</div><div>if (!geom_reduced.isValid())</div><div>   geom_reduced = geom_reduced.buffer(0)</div><div>return geom_reduced</div><div><br></div><div>The reason I chose to bypass everything after the first line is that (a) an isValid() check is always performed, and (b) if that fails, our geometry gets the bazooka of .buffer(0).  There's no algorithm available to surgically remove only degeneracies caused by the precision reduction.  It's very easy to imagine a case (and I've seen them) where:</div><div><br></div><div>- user has a large polygon at full double-precision</div><div>- coordinates are snapped or truncated to 1e-6, producing a tiny bow-tie effect along an edge somewhere</div><div>- in an attempt to fix the problem, user performs a .buffer(0), causing 99.9% of the original polygon to disappear, and keeping only the tiny part of the bowtie</div><div><br></div><div>This is not the kind of thing I'd want to have silently and automatically in every overlay function.  I really don't see the problem with having overlay functions fail on invalid inputs, even if the input is invalid only because the user supplied an incorrect precision argument.</div><div><br></div><div>The only change I can see making to GEOS is in the C API, renaming the existing GEOSGeom_setPrecision to GEOSGeom_reducePrecision, and adding a new GEOSGeom_setPrecision that does nothing more than set the PrecisionModel.  The PostGIS overlays could then use the new GEOSGeom_setPrecision, while a PostGIS ST_ReducePrecision could use GEOSGeom_reducePrecision.</div><div><br></div><div>Dan</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 15, 2016 at 7:22 AM, Sandro Santilli <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Mar 15, 2016 at 05:52:10AM -0400, Daniel Baston wrote:<br>
<br>
> The cost of the checking is the same as ST_IsValid,<br>
<br>
</span>Are you sure ? Do you have numbers to show ?<br>
Had you considered improving GEOS to make it irrelevant if<br>
none of the coordinates were really changed ?<br>
(as that would be your use case).<br>
<span class=""><br>
> Here's a query that I think illustrates the problem:<br>
><br>
> -- No preicsion model<br>
> postgres=# SELECT ST_AsText(ST_Intersection('POINT (0 0)', 'POLYGON ((0 0,<br>
> 1 0, 0 1, 1 1, 0 0))'));<br>
> ERROR:  Error performing intersection: TopologyException: Input geom 1 is<br>
> invalid: Self-intersection at or near point 0.5 0.5 at 0.5 0.5<br>
> CONTEXT:  SQL function "st_intersection" statement 1<br>
><br>
> -- With precision model, GEOSGeom_setPrecision flags GEOS_PREC_NO_TOPO |<br>
> GEOS_PREC_KEEP_COLLAPSED<br>
> postgres=# SELECT ST_AsText(ST_Intersection('POINT (0 0)', 'POLYGON ((0 0,<br>
> 1 0, 0 1, 1 1, 0 0))', op_precision := 1e-12));<br>
> ERROR:  Error performing intersection: TopologyException: Input geom 1 is<br>
> invalid: Self-intersection at or near point 0.5 0.5 at 0.5 0.5<br>
><br>
> -- WIth precision model, no flags to GEOSGeom_setPrecision<br>
> postgres=# SELECT ST_AsText(ST_Intersection('POINT (0 0)', 'POLYGON ((0 0,<br>
> 1 0, 0 1, 1 1, 0 0))', op_precision := 1e-12));<br>
>         st_astext<br>
> --------------------------<br>
>  GEOMETRYCOLLECTION EMPTY<br>
<br>
</span>The final result is unexpected, how was the polygon changed ?<br>
Reduction should have not moved any vertex, right ?<br>
<br>
I guess I just don't like how the handling is performed by<br>
GEOS. Ideally, it should only fix what was broken by precision<br>
reduction, not what was broken in the input.<br>
<br>
Remember the GEOS side of this is recent, so might need to<br>
still be tweaked.<br>
<div class="HOEnZb"><div class="h5"><br>
--strk;<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/postgis-devel</a></div></div></blockquote></div><br></div>