[postgis-devel] [PostGIS] #408: Catch "Exception in LWGEOM2GEOS" in ST_IsValid

[Martin Davis]

Yeah, but isn't it a pain to trap exceptions inside an SQL statement?  
And slow to try and do it using a plpqsl function?

strk wrote:
> I might be missing something, but wouldn't an exception 
> from LWGEOM2GEOS mean unambiguosly that the geometry
> is invalid ?
>
> ... thinkin loud ... could also be an OOM actually ...
>
> --strk;
>
> On Thu, Feb 04, 2010 at 01:26:38PM -0800, Martin Davis wrote:
>   
>> Right, this has just been explained to me by our resident PostGIS expert 
>> Kevin.  To repeat his explanation, the PostgreSQL language engine is 
>> auto-converting the string to a Geometry type, since that's what 
>> st_isvalid accepts.  This is where the exception is happening - which 
>> means that it can't be caught inside st_isvalid.
>>
>> I would humbly suggest that it would be nice to be able to prevent C 
>> exceptions leaking out into the SQL world where possible. Perhaps a
>>
>> st_isvalid_safe(String geomWKT)
>>
>> could be provided to allow users to avoid this.  (And since Kevin also 
>> pointed out that this doesn't allow distinguishing between Geometry and 
>> the new Geography type, a
>>
>> st_isvalid_geog_safe(String geogWKT)
>>
>> might be needed as well.
>>
>> Code it up and let the users vote with their keyboards!
>>
>> PostGIS wrote:
>>     
>>> #408: Catch "Exception in LWGEOM2GEOS" in ST_IsValid
>>> --------------------------+-------------------------------------------------
>>>  Reporter:  ddegasperi   |       Owner:  pramsey
>>>      Type:  enhancement  |      Status:  new    
>>>  Priority:  medium       |   Milestone:         
>>> Component:  postgis      |     Version:  1.4.X  
>>> Resolution:               |    Keywords:         
>>> --------------------------+-------------------------------------------------
>>> Comment (by pramsey):
>>>
>>> Non possible.
>>>
>>> The '':text entry first gets passed into the text parsing routines which
>>> is where the failure actually occurs, not in st_isvalid. We have had
>>> internal arguments many times about where validity checking should occur,
>>> and the current situation is that trivially invalid geometries (1-point
>>> lines, unclosed polygons) are failed during parsing.
>>>
>>> IMO, they shouldn't fail, but that's a personal opinion, not a consensus
>>> one.
>>>
>>>  
>>>       
>> -- 
>> Martin Davis
>> Senior Technical Architect
>> Refractions Research, Inc.
>> (250) 383-3022
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>     
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022