On Wed, Feb 29, 2012 at 08:19:18AM +0100, Denis Rouzaud wrote: > Hi Sandro.... > > Me again :( > > I recompiled postgis, and re-run the file > https://github.com/3nids/qWat/blob/38cde48d509d9b9a179eea1fd4db5bbd67121dcf/sql/strk.demo.sql > > here is there error I get: > > psql:strk.demo.sql:18: ERROR: SQL/MM Spatial exception - start node > not geometry start point. > > CONTEXT: SQL statement "SELECT ST_ChangeEdgeGeom(atopology, > rec.edge_id, snapedge)"
Ouch. I bet this time ST_Snap snapped the wrong vertex (an endpoint rather than an internal point). No wonder it is the _start_ node because ST_Snap is known to snap the first vertex below threshold rather than the closest one, see http://trac.osgeo.org/geos/ticket/501 As usual, file another bug on the postgis side. Note that if you enable debugging (manually editing topology/sql/populate.sql.in.c, adding a define a rebuilding): #define POSTGIS_TOPOLOGY_DEBUG 1 Should tell you the tolerance used in snapping. See also http://trac.osgeo.org/postgis/ticket/1625 And http://trac.osgeo.org/postgis/wiki/ToleranceDiscussion We're fully in the storm eye, into the source of all the topologyexception you've ever seen from GEOS functions. The bright side of persistent topology in postgis is that you can isolate the single problematic edge, threat it specially and continue once fixed locally. Surely enhancing the error message might help looking at it visually, like it could include a coordinate. PS: I already have a fix in mind, we could re-add the first point if lost due to snapping, but a parametrized ST_Snap may be generally more useful for the future. PPS: Hey, your data sucks [1] ! :P [1] http://www.youtube.com/watch?v=IX8iQN04tOo --strk; ,------o-. | __/ | Delivering high quality PostGIS 2.0 ! | / 2.0 | http://strk.keybit.net - http://vizzuality.com `-o------' _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
