TopologyException makes GEOS/JTS very difficult to employ in my production environments...

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

TopologyException makes GEOS/JTS very difficult to employ in my production environments...

giohappy
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

giohappy
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 <[hidden email]>:

> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

Howard Butler
In reply to this post by giohappy

On Sep 29, 2010, at 8:31 AM, G. Allegri wrote:
> 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.

Your choices are:

- Put the time in and fix the bugs yourself
- Put the money in and attract experts to fix the bugs
- Find an alternative and implement it

Saying that it's a pity you can't use software XX because the bugs *you* need fixed are not being fixed by someone else at no cost is not an option.  First, no one cares.  Second, the social contract of open source software requires that you put the time and money into getting what you need out of it.  Emails like this are not helpful to your cause, and in fact they will act to paint you as someone not being worthy of helping.

What if putting the amount of money you would have to pay for the commercial solution toward the bug fixes you need solved the problem?  I don't know that it would be enough to actually solve your issues, but if you did that, I think you would still be further ahead than if you used the commercial solution.  You need to express the issue(s) to your boss in these terms.  

>
> 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?

One way to eliminate a number of the topology issues might be to re-implement PostGIS with a computational geometry library that uses math that doesn't have floating point precision issues.  LEDA and CGAL come to mind.  Neither of these libraries directly map very well to the specific problems of geographic geometry problems, however, and implementing either would bring significant licensing challenges (you're going to have to pay).  The cost to do this work would be huge as well.

If the vast majority of PostGIS/GEOS users frequently had these problems, they would either be fixed or no one would use PostGIS/GEOS...

Howard_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

Paul Ramsey-3
In reply to this post by giohappy
Pre-empting Martin: your multipolygon is invalid.

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.

Paul

On Wed, Sep 29, 2010 at 7:15 AM, G. Allegri <[hidden email]> 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 <[hidden email]>:
>> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

Maxime van Noppen
In reply to this post by giohappy
On 09/29/2010 03:31 PM, G. Allegri wrote:
> I would be gratefull if you can share your experience and thoughts...

Hi,

We're having the exact same problem. Though we didn't (yet) put money on
the table because we're a very young startup not even making money yet.
:) But we're strongly considering it for the future. Currently I try to
help where I can in geos/PostGis but have not much time to really do
much. :(

To address this problem, or at least reduce it, we wrapped the geos
operations we need (intersection, difference, etc) and perform cascaded
heuristic simplifications when a TopologyException occurs (simplify,
buffer of "epsilon" around the geometry, etc).

--
Maxime
_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

giohappy
In reply to this post by Paul Ramsey-3
> 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 <[hidden email]> 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 <[hidden email]>:
>>> 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
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

giohappy
In reply to this post by Howard Butler
Howard, I know well how foss development works. So, my email wasn't
meant to ask someone to solve things for me. In this project I'm not
in the position to make such choices. I've just been able to move
little money to ask strk a first, basic analysis. I absolutely agree
with the commercial philosophy behind foss, and when I will be able to
manage enough money I won't easitate to invest it in that way.

I'm just surprised to see not so many issues raising from this
topology problems, as GEOS/JTS are maybe the most widespread libraries
used in the gfoss ecosystem. No problems when using it as a data
repository, but as soon as I use it massively for geometry processing
I face, almost everyday, thie TopolyException. So I was simply
wondering what the others think about this, if they have solved it
somehow. OS is also sharing best practices, isn'it? I don't want to
steal industry secrests to anyone, just share ideas...

Giovanni

2010/9/29 Howard Butler <[hidden email]>:

>
> On Sep 29, 2010, at 8:31 AM, G. Allegri wrote:
>> 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.
>
> Your choices are:
>
> - Put the time in and fix the bugs yourself
> - Put the money in and attract experts to fix the bugs
> - Find an alternative and implement it
>
> Saying that it's a pity you can't use software XX because the bugs *you* need fixed are not being fixed by someone else at no cost is not an option.  First, no one cares.  Second, the social contract of open source software requires that you put the time and money into getting what you need out of it.  Emails like this are not helpful to your cause, and in fact they will act to paint you as someone not being worthy of helping.
>
> What if putting the amount of money you would have to pay for the commercial solution toward the bug fixes you need solved the problem?  I don't know that it would be enough to actually solve your issues, but if you did that, I think you would still be further ahead than if you used the commercial solution.  You need to express the issue(s) to your boss in these terms.
>
>>
>> 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?
>
> One way to eliminate a number of the topology issues might be to re-implement PostGIS with a computational geometry library that uses math that doesn't have floating point precision issues.  LEDA and CGAL come to mind.  Neither of these libraries directly map very well to the specific problems of geographic geometry problems, however, and implementing either would bring significant licensing challenges (you're going to have to pay).  The cost to do this work would be huge as well.
>
> If the vast majority of PostGIS/GEOS users frequently had these problems, they would either be fixed or no one would use PostGIS/GEOS...
>
> Howard_______________________________________________
> geos-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

Maxime van Noppen
In reply to this post by giohappy
On 09/29/2010 03:31 PM, G. Allegri wrote:
> I would be gratefull if you can share your experience and thoughts...

Hi,

We're having the exact same problem. Though we didn't (yet) put money on
the table because we're a very young startup not even making money yet.
:) But we're strongly considering it for the future. Currently I try to
help where I can in geos/PostGis but have not much time to really do
much. :(

To address this problem, or at least reduce it, we wrapped the geos
operations we need (intersection, difference, etc) and perform cascaded
heuristic simplifications when a TopologyException occurs (simplify,
buffer of "epsilon" around the geometry, etc).

--
Maxime
_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

Maxime van Noppen
Sorry for the double post.

--
Maxime
_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

giohappy
In reply to this post by Maxime van Noppen
Hi Maxime,

> To address this problem, or at least reduce it, we wrapped the geos
> operations we need (intersection, difference, etc) and perform cascaded
> heuristic simplifications when a TopologyException occurs (simplify,
> buffer of "epsilon" around the geometry, etc).

me too :) It doesn't work in all the cases I have, but it works many
times. This time it seems the doing a ST_Union (unary union) on the
multipolygons before doing ST_Difference solves the issue. Probably
the union resolves the noding problems, but what I fear is that it
works for this specific data set, then it will fail when some other
corner cases come out...
Thanks for sharing anyway!
_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

Maxime van Noppen
On 09/29/2010 05:37 PM, G. Allegri wrote:
> me too :) It doesn't work in all the cases I have, but it works many
> times. This time it seems the doing a ST_Union (unary union) on the
> multipolygons before doing ST_Difference solves the issue. Probably
> the union resolves the noding problems, but what I fear is that it
> works for this specific data set, then it will fail when some other
> corner cases come out...
> Thanks for sharing anyway!

As I understood from the other posts, you might have invalid geometries.
That's my top-priority check. Before and after any operation I check
that all my geometries are valid, and if not I try to trace back to the
origin the faulty geometry to correct it.

--
Maxime
_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

giohappy
> As I understood from the other posts, you might have invalid geometries.
> That's my top-priority check. Before and after any operation I check
> that all my geometries are valid, and if not I try to trace back to the
> origin the faulty geometry to correct it.

Well, I checked the original polygons and they were right, but two of
them touch. This seems to make the Multipolygon invalid. Anyway I have
to pass through a collection to do the required difference. It seems
that ST_Union succeds in cleanin the bad intersections...
_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

Martin Davis
In reply to this post by giohappy
  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<[hidden email]>  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<[hidden email]>:
>>>> 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
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>
>> _______________________________________________
>> geos-devel mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
--
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022


_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel

geoms.png (49K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

Martin Davis
  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<[hidden email]>  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<[hidden email]>:
>>>>> 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
>>>> [hidden email]
>>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>>
>>> _______________________________________________
>>> geos-devel mailing list
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>
>> _______________________________________________
>> geos-devel mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>
>
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geos-devel

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

_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

giohappy
In reply to this post by Martin Davis
Hi Martin,

> See the attached diagram which displays the problem (generated using the
> Magnify Topology capability in the development version of JTS TestBuilder)

the Magnify is very nice and useful! I see the problem now...
I will checkout the trunk.

> 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.

I interpreted it the wrong way. In fact I didn't understand what
finite stood for. It's not menat as the number of vertices but the
geometrical interpretation of a line mad by an inifinite number of
points.
Thx

Giovanni

>
> 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<[hidden email]>  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<[hidden email]>:
>>>>>
>>>>> 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
>>>> [hidden email]
>>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>>
>>> _______________________________________________
>>> geos-devel mailing list
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>
>> _______________________________________________
>> geos-devel mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
>
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

giohappy
In reply to this post by Martin Davis
>  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

That's exactly what I did (UnaryUnion), and I confirm it works.
_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

Martin Davis
In reply to this post by giohappy
  Giovanni,

I feel for your frustration.  Be assured that I have had very similar
feelings for a long time!  But as you realize, this just is not an easy
problem to solve (at least not for me, and I presume for others as well
since no-one has popped up with a solution over the last 10 years).  
I've spent literally hundreds of hours and 10's of thousands of dollars
working on potential solutions to this problem.  Many improvements have
been made, such as:

- more accurate intersection compuation
- improved noding (via repeated noding)
- using snapping when topology failures are found

And I have more ideas sitting in the lab, such as Snap-Rounding, and an
improved technique for noding.  But work goes very slowly on these, both
because they are difficult problems to solve (and code), and because I
don't have the luxury of working on them full-time.

It would be great if some funding could be found to allow full-time work
on this solutions.  I'll even lower Paul's number to say 30,000 euros!

Martin

On 9/29/2010 6:31 AM, G. Allegri wrote:

> 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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>

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

_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult...

Chris Hodgson
In reply to this post by Martin Davis
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<[hidden email]>  
>>>> 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<[hidden email]>:
>>>>>> 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
>>>>> [hidden email]
>>>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>>>
>>>> _______________________________________________
>>>> geos-devel mailing list
>>>> [hidden email]
>>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>>
>>> _______________________________________________
>>> geos-devel mailing list
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>
>>
>>
>> _______________________________________________
>> geos-devel mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>

_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult...

Martin Davis
  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<[hidden email]>  
>>>>> 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<[hidden email]>:
>>>>>>> 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
>>>>>> [hidden email]
>>>>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>>>>
>>>>> _______________________________________________
>>>>> geos-devel mailing list
>>>>> [hidden email]
>>>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>>>
>>>> _______________________________________________
>>>> geos-devel mailing list
>>>> [hidden email]
>>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>>>
>>>
>>>
>>> _______________________________________________
>>> geos-devel mailing list
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>
> _______________________________________________
> geos-devel mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>

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

_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
Reply | Threaded
Open this post in threaded view
|

Re: TopologyException makes GEOS/JTS very difficult to employ in my production environments...

rburhum
In reply to this post by giohappy
Giovanni,

I am actually surprised that you bring this comment about a production environment. When working with real data in production environment, FOSS or proprietary alike (i.e ESRI), I *always* encounter data that causes Topology Exceptions (ESRI Geometry/Geoprocessing, GEOS, JTS, whatever) at some point, it happens. It is just the nature of the beast - data is not perfect. 

What I do in such cases, is that before I digest the data, I have a set of "cleansing" and identification procedures that I put my data through before putting it in my pretty system. In other words, a mini-fence that I use to avoid problems (self intersections, nulls, multiparts, whatever).

I apologize if this seems rude, however, the very first thing I do when a geometry pair gives me problems, is to look at it. That would have shown the problem the problem right away.

- Ragi

Date: Wed, 29 Sep 2010 17:26:31 +0200
From: "G. Allegri" <[hidden email]>
Subject: Re: [geos-devel] TopologyException makes GEOS/JTS very
       difficult to    employ in my production environments...
To: GEOS Development List <[hidden email]>

Howard, I know well how foss development works. So, my email wasn't
meant to ask someone to solve things for me. In this project I'm not
in the position to make such choices. I've just been able to move
little money to ask strk a first, basic analysis. I absolutely agree
with the commercial philosophy behind foss, and when I will be able to
manage enough money I won't easitate to invest it in that way.

I'm just surprised to see not so many issues raising from this
topology problems, as GEOS/JTS are maybe the most widespread libraries
used in the gfoss ecosystem. No problems when using it as a data
repository, but as soon as I use it massively for geometry processing
I face, almost everyday, thie TopolyException. So I was simply
wondering what the others think about this, if they have solved it
somehow. OS is also sharing best practices, isn'it? I don't want to
steal industry secrests to anyone, just share ideas...

Giovanni


_______________________________________________
geos-devel mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/geos-devel
12