[postgis-devel] Fixed precision for ST_Intersection, ST_Union, etc.

[Daniel Baston]

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.

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.

Here's a query that I think illustrates the problem:

-- No preicsion model
postgres=# SELECT ST_AsText(ST_Intersection('POINT (0 0)', 'POLYGON ((0 0,
1 0, 0 1, 1 1, 0 0))'));
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
CONTEXT:  SQL function "st_intersection" statement 1

-- With precision model, GEOSGeom_setPrecision flags GEOS_PREC_NO_TOPO |
GEOS_PREC_KEEP_COLLAPSED
postgres=# SELECT ST_AsText(ST_Intersection('POINT (0 0)', 'POLYGON ((0 0,
1 0, 0 1, 1 1, 0 0))', op_precision := 1e-12));
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

-- WIth precision model, no flags to GEOSGeom_setPrecision
postgres=# SELECT ST_AsText(ST_Intersection('POINT (0 0)', 'POLYGON ((0 0,
1 0, 0 1, 1 1, 0 0))', op_precision := 1e-12));
        st_astext
--------------------------
 GEOMETRYCOLLECTION EMPTY



On Tue, Mar 15, 2016 at 4:41 AM, Sandro Santilli <strk at keybit.net> wrote:

> On Sun, Mar 13, 2016 at 06:14:44PM -0400, Daniel Baston wrote:
> > 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.
>
> But in this case (specifying a precision model) you're also basically
> asking ST_Intersection to change the inputs, and it is known that such
> changing might introduce invalidities that would be "fatal" for the overlay
> operation.
>
> The only case in which you'd want to avoid fixing invalidities is by
> knowing
> in advance that the reduction would be a no-op (as in your case) and thus
> willing to avoid the checking cost. Did you evaluate the cost of checking ?
> Could that cost be reduced by determining a "no-op" case directly within
> GEOS ?
>
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20160315/da05147f/attachment.html>