<div dir="ltr">Hi Olivier,<div><br></div><div>Here's an example where GEOS and SFCGAL report a different result for ST_IsValid:</div><div><br></div><div>SELECT ST_IsValid('POLYGON ((0 0 0, 1 0 0, 1 0 0, 1 1 0, 0 1 0, 0 0 1))');<br></div><div><br></div><div>This returns true with GEOS, but false with SFCGAL (on Hugo's branch, where ST_IsValid is implemented with SFCGAL).  So, we wouldn't want a situation where the flag is set with a GEOS backend and read with a SFCGAL backend.</div><div><br></div><div>Dan </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 4, 2016 at 9:33 AM, Olivier Courtin <span dir="ltr"><<a href="mailto:olivier.courtin@oslandia.com" target="_blank">olivier.courtin@oslandia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le 4 mars 2016 à 14:58, Daniel Baston <<a href="mailto:dbaston@gmail.com">dbaston@gmail.com</a>> a écrit :<br>
<br>
Hi Dan,<br>
<span class=""><br>
> I like the suggestion to add an optional set of extra flags at the end of the geometry, as a nice backwards-compatible way to store extra information when we need the ability.  But it seems like overkill for the current situation, where we do have flags available in the current structure.  Can we not get 99% of the benefits (avoid repeatedly testing geometries known to be valid) by storing the single "valid / unknown" flag in the current structure?<br>
<br>
</span>I have the same feeling (invalid flag looks like overkill),<br>
But sooner or later we will need new flags…<br>
<br>
And we have to face now, the following choice:<br>
- use the last flag space left, for "valid / unknown" notion<br>
- or use the last one for activating the extra flags handling (at the end of the geometry)<br>
<br>
And if we have extra flags, we could afford more liberally to spare few, even for quite peculiar use case.<br>
(as we could even imagine to add later an another extra 8-bytes at the end of the end and so on…)<br>
<br>
<br>
<br>
<br>
The other alternative is to remove at least one flag who is not that meaningful (as flag)<br>
(readonly could be a candidate ?).<br>
<span class=""><br>
<br>
<br>
> On unrelated note, do we need to further quality what we mean by "valid" ?  Is SFCGAL validity always the same as GEOS validity ?<br>
<br>
</span>Good question !<br>
Depends on OGC SFS Validity notion, so should not be different upon backend (GEOS, SFCGAL, whatever)<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
O.<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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>