<div dir="ltr">My rationale here is that it's not the job of ST_Intersection to clean up its inputs before computing the intersection, much like the current overlay functions don't call ST_MakeValid on their inputs.  I think there is a place for a ST_ReducePrecision / ST_SnapToGrid that reduces precision and cleans up collapsed geometries, etc., but I don't think it's something that should be automatically run on the inputs of all overlay functions.<div><br></div><div>Dan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 13, 2016 at 4:42 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 Thu, Mar 10, 2016 at 07:47:49AM -0500, Daniel Baston wrote:<br>
> You're right, I didn't describe that well.  I should say instead that these<br>
> functions aren't using GEOS' behavior of cleaning up topological collapses<br>
> (GEOS_PREC_NO_TOPO and GEOS_PREC_KEEP_COLLAPSED in the CAPI).  GEOS is<br>
> indeed doing a pointwise precision reduction, which should be a no-op in my<br>
> use case but may not be in others.<br>
<br>
</span>What's the rationale for NOT handling the collapsing ?<br>
Theoretically, feeding invalid geometries to GEOS overlay operations<br>
should result in an exception being thrown or some other undesired<br>
result, so why taking the risk at all ?<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>