>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 http://postgis.refractions.net/mailman/listinfo/postgis-users