[postgis-users] topology example, new bug?

[Sandro Santilli]

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