<div dir="ltr">Ideally, specifying a precision model would not imply any sort of precision reduction.  The fact that it does, in this case, is artifact of the GEOS CAPI implementation.  I think these functions are best kept separate, so that precision reduction can be explicitly performed in a way that the user has both control over the "autocleanup" options, and some means of viewing the output of the precision reduction operation.  Many data large data sets, such as TIGER, are already at fixed-precision and only need some way of making GEOS aware of the precision model.<div><br></div><div><div>The cost of the checking is the same as ST_IsValid, which is significant or not depending on the usage pattern.  I'd be less bothered by the cost, than by the idea of PostGIS silently and non-optionally performing "magic" on the inputs in the hope of avoiding what may be a legitimate error downstream, especially since there's no way to know that the invalidity, if found, had anything to do with the precision reduction.</div></div><div><br></div><div>Here's a query that I think illustrates the problem:</div><div><br></div><div>-- No preicsion model</div><div><div>postgres=# SELECT ST_AsText(ST_Intersection('POINT (0 0)', 'POLYGON ((0 0, 1 0, 0 1, 1 1, 0 0))'));</div><div>ERROR:  Error performing intersection: TopologyException: Input geom 1 is invalid: Self-intersection at or near point 0.5 0.5 at 0.5 0.5</div><div>CONTEXT:  SQL function "st_intersection" statement 1</div><div><br></div><div>-- With precision model, GEOSGeom_setPrecision flags GEOS_PREC_NO_TOPO | GEOS_PREC_KEEP_COLLAPSED</div><div>postgres=# SELECT ST_AsText(ST_Intersection('POINT (0 0)', 'POLYGON ((0 0, 1 0, 0 1, 1 1, 0 0))', op_precision := 1e-12));<br></div><div>ERROR:  Error performing intersection: TopologyException: Input geom 1 is invalid: Self-intersection at or near point 0.5 0.5 at 0.5 0.5</div></div><div><br></div><div>-- WIth precision model, no flags to GEOSGeom_setPrecision</div><div><div>postgres=# SELECT ST_AsText(ST_Intersection('POINT (0 0)', 'POLYGON ((0 0, 1 0, 0 1, 1 1, 0 0))', op_precision := 1e-12));</div><div>        st_astext         </div><div>--------------------------</div><div> GEOMETRYCOLLECTION EMPTY</div></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 15, 2016 at 4:41 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 Sun, Mar 13, 2016 at 06:14:44PM -0400, Daniel Baston wrote:<br>
> My rationale here is that it's not the job of ST_Intersection to clean up<br>
> its inputs before computing the intersection, much like the current overlay<br>
> functions don't call ST_MakeValid on their inputs.  I think there is a<br>
> place for a ST_ReducePrecision / ST_SnapToGrid that reduces precision and<br>
> cleans up collapsed geometries, etc., but I don't think it's something that<br>
> should be automatically run on the inputs of all overlay functions.<br>
<br>
</span>But in this case (specifying a precision model) you're also basically<br>
asking ST_Intersection to change the inputs, and it is known that such<br>
changing might introduce invalidities that would be "fatal" for the overlay<br>
operation.<br>
<br>
The only case in which you'd want to avoid fixing invalidities is by knowing<br>
in advance that the reduction would be a no-op (as in your case) and thus<br>
willing to avoid the checking cost. Did you evaluate the cost of checking ?<br>
Could that cost be reduced by determining a "no-op" case directly within GEOS ?<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>