[postgis-users] ST_Insersection problem
G. van Es
gves2000 at yahoo.com
Tue Oct 4 05:20:15 PDT 2011
Good point about the validity of the geometry! However in my case just by experiment I have deleted all records where st_isvalid(ST_GeomFromEWKT(st_asewkt(the_geom)))='f'
From the 11mio records a little over 800 where invalid and deleted.
Still my original query crashes on:NOTICE: TopologyException: side location conflict at 129105 515684 ERROR: GEOS Intersection() threw an error!
All intersection parameters are like ST_SnapToGrid(the_geom, 0.000001) so that doesn't resolve the issue either. Although it makes some difference on which object the process crashes.
Any ideas are still very welcome.
From: Birgit Laggner <birgit.laggner at vti.bund.de>
To: postgis-users at postgis.refractions.net
Sent: Tuesday, October 4, 2011 10:35 AM
Subject: Re: [postgis-users] ST_Insersection problem
this intersection error happens very often to me, too. Mostly, this
is really due to invalid polygons. My experience is, that the
validity of some polygons seems to depend on precision issues. If I
am testing these geometries with st_isvalid, everything seems to be
fine, but if I do a conversion into wkt format and back on the same
geometries, the result is not valid anymore. So, my first step in
your case would be to test validity of the converted geometries and
repair the invalid ones.
If the problem of the intersection error still occurs, my next
proposal would be to execute the intersection within a function with
a loop and an exception handler. And in the exception handler I
would experiment with small buffers and small polygon corrections
If you need more details or an example, just ask...
Am 04.10.2011 09:58, schrieb G. van Es:
>I'm still working on this issue. To my knowledge there are no Collections. The GeometryType on all records in both tables is POLYGON. So I expect the LINESTRING error to be an internal issue where I'm unable to detect or prevent this from happening.
>I you or anybody else has some idea's please let me know.
>From: Andrea Peri <aperi2007 at gmail.com>
>To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
>Sent: Thursday, September 22, 2011 12:02 PM
>Subject: Re: [postgis-users] ST_Insersection problem
>We are using "POSTGIS="1.5.1" GEOS="3.2.2-CAPI-1.6.2" PROJ="Rel. 4.7.1, 23 September 2009" LIBXML="2.7.6" USE_STATS" and having a problem with ST_Intersection(). >Given the following query
>select count(st_intersection(tbl_a.the_geom,tbl_b.the_geom)) from tbl_a, tbl_b;
>will result in this error message
>NOTICE: TopologyException: found non-noded intersection between LINESTRING (62723.7 426635, 62722.5 426634) and LINESTRING (62723.7 426635, 62726.2 426632) at 62723.7 426635 >ERROR: GEOS Intersection() threw an error!
>After the NOTICE message we expect the query to continue but it doesn't. Both tables have all records st_isvalid='t'.
> >Does anyone know a solution or workaround for this problem?
I give my 2ct. :)
The problemyou report is not really a problem of postgis, but instead is a problem of the finite arithmetic use by the pcs and of the methematical algorithm used . I have every time the error you report.
Please notice I run about 10-20 million records of geometry and some geometry has also 1 million vertex :) Is a nightmare.
But this is the beautiful and the hell of the arithmetic finite . To resolve this you must detect at every step what happened and filter they using specific "where" clause or CASE operators. Is pretty easy,
you will see often it return a Collection, and you get only the lines or the polys from that, again you can filter out the empty geometry.
After this long path you will have a good procedure to clean all the problem of a real intersection on a arithmetic finite machine. Regards,
>. . . . . . . . .
>postgis-users mailing list
>postgis-users at postgis.refractions.net
postgis-users mailing list postgis-users at postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
postgis-users mailing list
postgis-users at postgis.refractions.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the postgis-users