<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We have had lots of discussions internally about whether validity is<br>
linked or not to the handling of precision (i.e. coordinates snapped to<br>
a regular grid rather than using the floating point irregular grid). We<br>
finally conclude discussions about handling of precision should be<br>
postponed and we should focus first on validity (even if we already have<br>
some ideas about a ST_Valid variant that takes a precision as arguments).<br></blockquote><div> </div><div>Is there any spec that defines "Valid within precision"?<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We then propose to add a new bit in the header to handle the validity state.<br>
Two states Valid/Unknown should be ok, meaning that geometries that have<br>
already been tested as valid do not have to be tested again, and invalid<br>
and unknown geometries are treated the same way.<br>
We could add another bit to deal with a three-state:<br>
Valid/Invalid/Unknown, but I am not totally sure it is needed.<br></blockquote><div><br></div><div>Bit number two (depending on side you count) in gserialized is already called Validity:</div><div><a href="https://github.com/postgis/postgis/blob/d1e5a63aac0078b6699702d8758dc1f0c7714841/liblwgeom/g_serialized.txt#L45">https://github.com/postgis/postgis/blob/d1e5a63aac0078b6699702d8758dc1f0c7714841/liblwgeom/g_serialized.txt#L45</a> <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
There was previously the question of whether to have a validity state by<br>
geometry backend, since backends may answer differently about validity.<br>
But it appears differences are due to one of the backends that may have<br>
a buggy implementation of the validity check for some cases.<br>
<br>
For example, PolygonZ with random coordinates on Z are valid for GEOS,<br>
and should not be.<br>
In theory, on very extreme cases at the limit of floating point<br>
representation, GEOS and SFCGAL may have predicates that answer<br>
differently, but in practice, despite our efforts, we are not able to<br>
exhibit such cases.<br></blockquote><div><br></div><div>Do we need ST_IsValid to actually call both implementations and store AND of them in Validity bit? Can we also print the mismatch warning then?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So we would prefer to have only one definition of validity for everyone<br>
and fix validity test bugs of one or the other backend.<br>
<br>
The validity state could also be enforced by adding a type modifier,<br>
like Geometry(point, 4326, valid). We do not have a strong opinion about<br>
that, any pro/cons ?<br></blockquote><div><br></div><div>No pro that I see. You can't enforce typmod on function signature, so it's not that useful - you can't define a function that will only operate on valid inputs.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
We propose to add/modify the following functions:<br>
<br>
- ST_IsValid:<br>
  - if the geometry has a validity flag set to Valid, do not do anything<br>
  - otherwise, test if the geometry is valid.<br>
- ST_Validate(geom) : calls ST_IsValid and sets the validity flag if it<br>
is Valid<br>
- ST_HasValidityFlag(geom)<br>
- ST_ForceValidityFlag(geom, is_valid), force the validity flag. To be<br>
used with caution.<br></blockquote><div><br></div><div>Did you say that invalid in SFCGAL can crash backend? Well, that's a way to DoS a database, so better not be implemented.</div><div><br></div><div>I have a feeling it's a job for something like VACUUM, to walk the tables and validate geometries in background.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Then what to do with this validity flag in other functions ?<br>
<br>
When geometries are passed as input, the main goal is to shortcut some<br>
verification code when the geometry is known to be valid. The initial<br>
target was to speed up SFCGAL functions, and we would already benefit<br>
from it, but it could be used elsewhere.<br>
<br>
For functions that output geometries, for creation or modification, the<br>
question is whether to set or maintain a validity flag, without a call<br>
to a full validity check. Since it is probably hard to ensure every<br>
modification functions maintain the flag, we propose in a first step to<br>
reset the validity flag for every function that returns a geometry<br>
(except for some possible trivial cases). This won't add any regression<br>
and would let time to optimize functions' output step by step.<br>
<br>
Looking forward to read your reactions :)</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Darafei Praliaskouski<br>Support me: <a href="http://patreon.com/komzpa">http://patreon.com/komzpa</a></div></div>