Hallo Ge,
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 with st_snaptogrid().
If you need more details or an example, just ask...
Birgit.
Am 04.10.2011 09:58, schrieb G. van Es:
Hi Andrea,
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.
thanks,
Ge
------------------------------------------------------------------------
*From:* Andrea Peri <aperi2...@gmail.com>
*To:* PostGIS Users Discussion <postgis-users@postgis.refractions.net>
*Sent:* Thursday, September 22, 2011 12:02 PM
*Subject:* Re: [postgis-users] ST_Insersection problem
>Hello Group,
>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!
>SQL status:XX000
>
>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?
>
>Thanks,
Hi,
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,
Andrea Peri.
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
<mailto:postgis-users@postgis.refractions.net>
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
