[postgis-devel] AutoFix Again

[Daniel Baston]

I think Paul is right to frame this as a question about handling all errors
from GEOS, which is broader than just GEOS errors caused by invalid
geometry.

I haven't seen anything documented about the design of the autofix system,
which is part of why I'd like to revert the auto-fix changes introduced in
2.5 and discuss the topic at the sprint.

(PR to revert: https://github.com/postgis/postgis/pull/268)

If we don't revert this, we may be left supporting/explaining with three
different systems for handling invalid geometry (2.4, 2.5, 3.0).

With regard to the suggestion that processes with invalid geometries should
"just work," any software must specify its acceptable inputs, and the
OGC/ISO standards do this for geometry validity. We shouldn't expect
non-conforming data to "just work" any more than we should expect invalid
JSON or XML to be "autofixed" by tools operating on that data. Unlike
invalid JSON, we don't block import of invalid geometry into PostGIS (and
we shouldn't), so we're left with the more difficult task of delineating
which parts of the system require valid geometry, and what we do when they
don't get it. I would lean towards some combination of a lazy validity
flag, validity-checking of inputs, and function parameters for error
handling, but the topic is an important enough one that we should probably
sketch out several prototypes before committing anything.

Dan



On Tue, Jul 24, 2018 at 9:54 AM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

> Just trolling tickets and reading/thinking, was thinking that the
> autofix question falls into two parts:
>
> - having a whole query interrupted by a single row problem is
> sometimes not desired
> - what *is* desired in that case is quite variable
>
> This is something for discussion perhaps at the sprint, but the
> problem of "policy" is going to keep coming up...
>
> - is a given behaviour a policy or a parameter?
>
> For example, does it make more sense to have
>
> set postgis.geos_exception_action = return_null;
> set postgis.geos_exception_action = attempt_repair;
> set postgis.geos_exception_action = fatal_error;
>
> Or, should that kind of thing be a parameter to each effected function?
> The same question will obtain for things like tolerance. If we add a
> tolerance module, is it a global setting, or is it a function
> parameter? Or, heaven help us, is it both?
> The whole question is further complicated by the issues we have had in
> the past with interactions between GUC and upgrades.
>
> Anyways, I feel like this stuff needs to be written out a little bit
> more, but maybe I'm just ignorant and it's already written out.
>
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180725/1adc6dff/attachment.html>