[postgis-devel] [geos-devel] Re: TopologyException makes GEOS/JTS very difficult...

Wed Sep 29 11:13:22 PDT 2010

  The idea of checking for invalid input and providing a more specific 
error message seems like an excellent one.  Thanks for thinking of this, 
Chris.

I think it would make sense to run this check inside the JTS/GEOS 
overlay functions, and throw an InvalidGeometry exception instead of a 
TopologyException if an invalid input was detected.  This would be the 
"friendliest" API, e.g. providing the most information to users.  There 
is a cost to checking validity, but this is usually going to be no 
larger than the cost of running the operation in the first place, and it 
will only be incurred when an error is encountered - which is supposed 
to be an unusual event.  And if users are really concerned about 
avoiding this cost, they can call a lower-level API to avoid the check.

(I think this is a general principle of API design, at least for 
JTS/GEOS.  The "obvious" API functions should value correctness and 
safety over performance, and "lower-level" APIs can be provided where 
necessary for performance).

In order to avoid a breaking change to the API, perhaps 
TopologyException should be kept as the general superclass for 
exceptions, and InvalidGeometryException can subclass it.

Martin

On 9/29/2010 10:50 AM, Chris Hodgson wrote:
> I'm crossing this over into PostGIS-devel, for some further input.
>
> It seems to me that 90% of the the "Topology Exceptions" we see are 
> the result of invalid geometries. Would it make sense, somewhere in 
> the postgis-geos wrapper (or in "friendlier" API to GEOS/JTS), to 
> catch these and check the validity of the inputs, and if they are 
> invalid, return the "isValidReason()" output in a "InvalidGeometry 
> Exception"? This way we make it clear to the user what the problem is, 
> because only a very few of these problems actually come down to real 
> floating point or algorithm convergence issues.
>
> It seems like Topology Exceptions are just too nebulous for users, 
> while on the mailing list it tends to be a race to see who can prove 
> that the inputs were invalid.
>
> Also, it seems that in this case the invalid input might actually be 
> an output of another PostGIS function, likely ST_Collect? Certainly 
> ST_Collect can create an invalid multipolygon, if the input polygons 
> are overlapping. There are other functions that can create invalid 
> outputs; I think it was previously decided that this is acceptable - 
> but perhaps we need to document this with a big red warning in the 
> docs so that users are at least made aware of these potential pitfalls.
>
> Thoughts?
>
> Chris
>
>
>
> Martin Davis wrote:
>>  In case it helps, you can deal with this invalidity by running 
>> either UnaryUnion or buffer(0) over the invalid MultiPolygon.  When 
>> unary union is used, difference() then works on the results.
>>
>> On 9/29/2010 9:15 AM, Martin Davis wrote:
>>>  I'll make the easy reply first.   8^)
>>>
>>> The invalidity is due to one component polygon overlapping another one.
>>>
>>> See the attached diagram which displays the problem (generated using 
>>> the Magnify Topology capability in the development version of JTS 
>>> TestBuilder)
>>>
>>> Also, many of the segments of this component polygon are coincident 
>>> with the adjacent polygon boundary segments.  This violates the rule 
>>> from SFS 2.1.12 that you quote, since segments contain an infinite 
>>> number of points.
>>>
>>> Martin
>>>
>>> On 9/29/2010 8:16 AM, G. Allegri wrote:
>>>>> Pre-empting Martin: your multipolygon is invalid.
>>>> Thanks Paul, I've learned something I didn't know... I thought that a
>>>> MP where two polygons touch on a vertice was valid.
>>>> > From SFS Specifications (par. 2.1.12):
>>>>
>>>> "The Boundaries of any 2 Polygons that are elements of a MultiPolygon
>>>> may not ‘cross’ and may touch
>>>> at only a finite number of points"
>>>>
>>>> JTS tells me that I have a self-intersection, but visually I only see
>>>> two vertices touchin at 1664458.5096082322,1664458.5096082322
>>>>
>>>>> However: yes, there are lots of people who do big geoprocessing with
>>>>> PostGIS who inevitably, in sieving millions of features through the
>>>>> hopper, find pairs that cause topology exceptions. Would I like that
>>>>> not to happen: oh yes. Do I have the time and money to fund the
>>>>> development to conclusively remove those cases? I do not. Let's
>>>>> randomly say it would take 100,000 euros to put a stake through the
>>>>> heart of this one and fro all and see if anyone's pain rises to that
>>>>> level.
>>>> Well, I don't have 100.000, neither my company. I will keep
>>>> TopologyExcpetions here and there :)
>>>>
>>>> Giovanni
>>>>
>>>>> Paul
>>>>>
>>>>> On Wed, Sep 29, 2010 at 7:15 AM, G. Allegri<giohappy at gmail.com>  
>>>>> wrote:
>>>>>> Here are the WKB representations of a polygon and a multipolygon 
>>>>>> which
>>>>>> cause a TopologyException for ST_Difference:
>>>>>>
>>>>>> Polygon: http://pastebin.com/rWAGMmME
>>>>>> Multipolygon: http://pastebin.com/sik9jZk2
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2010/9/29 G. Allegri<giohappy at gmail.com>:
>>>>>>> Sorry for this strong title, but I would like to open a 
>>>>>>> discussion on
>>>>>>> this topic. There are already several tickets about 
>>>>>>> TopologyException
>>>>>>> happening in various contexts, and I now it is not an easy to solve
>>>>>>> problem. We, in my company, have struggled to circumvent this 
>>>>>>> frequent
>>>>>>> error, and we put some (few) money to let Sandro (strk) analyze it.
>>>>>>> The only solutions, at now, have been various workarounds that (not
>>>>>>> deterministically) work for some cases/datasets, but fail with 
>>>>>>> others.
>>>>>>> Our first "meet" with this exception was due to GeomUnion 
>>>>>>> operations.
>>>>>>> Today we face it for ST_Difference op in PostGIS, and this time no
>>>>>>> workaround is working.
>>>>>>>
>>>>>>> I anticipate the critics: put the money on the table and someone 
>>>>>>> could
>>>>>>> invest time to solve it. Holy words, this is how foss should 
>>>>>>> work. But
>>>>>>> I'm not the boss of my company, and I've suggested to employ
>>>>>>> PostGIS->GEOS in a big job... and now I have to solve this 
>>>>>>> issue, with
>>>>>>> no extra-money.
>>>>>>>   If this problem cannot be solved I have to abandon PostGIS for 
>>>>>>> one of
>>>>>>> our production environments, and that would be a pity.
>>>>>>>
>>>>>>> So, my reflection is: in a few weeks we have fighted, almost daily,
>>>>>>> with this error. Are we the only ones to get stuck in it? Have 
>>>>>>> others
>>>>>>> found consistent,deterministic solutions?
>>>>>>>
>>>>>>> I would be gratefull if you can share your experience and 
>>>>>>> thoughts...
>>>>>>> Giovanni
>>>>>>>
>>>>>> _______________________________________________
>>>>>> geos-devel mailing list
>>>>>> geos-devel at lists.osgeo.org
>>>>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>>>>
>>>>> _______________________________________________
>>>>> geos-devel mailing list
>>>>> geos-devel at lists.osgeo.org
>>>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>>>
>>>> _______________________________________________
>>>> geos-devel mailing list
>>>> geos-devel at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>>
>>>
>>>
>>> _______________________________________________
>>> geos-devel mailing list
>>> geos-devel at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>

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