[postgis-devel] Validity flag

Hugo Mercier hugo.mercier at oslandia.com
Mon Feb 29 05:23:13 PST 2016


On 29/02/2016 14:15, Oliver Courtin wrote:
> Le 29 févr. 2016 à 14:00, Sandro Santilli a écrit :
> 
>> On Mon, Feb 29, 2016 at 12:45:38PM +0100, Oliver Courtin wrote:
>>
>>> With only the _valid_ one , if we are sure that geometry is valid, 
>>> we could skip the check validity in SFCGAL (or other backend),
>>> and if we not sure (i.e unknown or not valid), 
>>> we have to do the check validity backend side.
>>
>> Why check if it's already checked and invalid ?
>> You could just say it's invalid, right away, and
>> suggest to use ST_MakeValid.
>>
>> BTW, ST_MakeValid checks for validity as its first thing,
>> making it slow when the input is already known as being
>> invalid. It would then also benefit from knowing _invalid_
>> from the start.
>>
>> And ST_Simplify (for example) could set _invalid_ flag when
>> returning collapsed lines (structurally invalid).
> 
> 
> I understand what you mean, Sandro, but:
> 
> - We don't have that much flags still available 
> 
> - On userland indeed we allow invalid geometry to be stored, 
>   but only with the ST_MakeValid stuff, or equivalent, in mind.
> 
>   I can't figure a reason to encourage keeping invalid data on a long term.
>  

My proposition was indeed to have two states : valid / unknown. Lack of
spare bit in the flagset was part of the reason.

But with the spare bits problem aside, I am not against having a third
state for invalidity.
Actually we can even argue this will make them (the ugly invalid
geometries) more visible ...

Any idea to extend the flag set ? Consider it two-byte long if the first
bit is set ?




More information about the postgis-devel mailing list