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

Chris Hodgson chodgson at refractions.net
Wed Sep 29 13:50:28 EDT 2010

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.



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

More information about the geos-devel mailing list