[postgis-devel] Validity flag

[Sandro Santilli]

On Thu, Nov 15, 2018 at 10:41:22AM +0100, Hugo Mercier wrote:

> So we would prefer to have only one definition of validity for everyone
> and fix validity test bugs of one or the other backend.

We already have ST_IsValid* accepting flags to specify
which validity kind to consider. A well-known ESRI variant of
validity (self-intersecting rings considered valid) is in particular
used by PostGIS users in the public sector.
For this reason I really think validity-kind is a must-have, if we
introduce flags.

The flags argument for validity is currently an "int" type (32bits).
A single flag is currently supported (the "ESRI" one).
I guess we might want to add more flags for more kind of validity
checks (Z consistency, for instance). Why not starting there, to
find out how many flags we really need ? To me it's surely not 1bit.

> The validity state could also be enforced by adding a type modifier,
> like Geometry(point, 4326, valid). We do not have a strong opinion about
> that, any pro/cons ?

How much space would we have if we use that ?

> 
> We propose to add/modify the following functions:
> 
> - ST_IsValid:
>   - if the geometry has a validity flag set to Valid, do not do anything
>   - otherwise, test if the geometry is valid.
> - ST_Validate(geom) : calls ST_IsValid and sets the validity flag if it
> is Valid

We have ST_MakeValid which could do that (appropriately accepting the
same flags as ST_IsValid and friends).

> - ST_HasValidityFlag(geom)
> - ST_ForceValidityFlag(geom, is_valid), force the validity flag. To be
> used with caution.

I don't think we should allos forcing a flag as my understanding is
that the flag would be used by SFCGAL to skip the check, which may
in turn result in a backend crash when the input is invalid (for the
SFCGAL expected validity kind).

> When geometries are passed as input, the main goal is to shortcut some
> verification code when the geometry is known to be valid. The initial
> target was to speed up SFCGAL functions, and we would already benefit
> from it, but it could be used elsewhere.

In an ideal world SFCGAL would just give an unpredictable answer when
input is not valid. The real problem here is that it _CRASHES_ the
backend instead...

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   https://strk.kbt.io/services.html