[postgis-devel] topology expectations?

[Jose Carlos Martinez]

Hi,
My guess is the algorithm used in the  function ST_Snap (if it is the 
same one that JTS) is not stable. In fact, I did many test trying to 
change the ST_Snap behavior in Jaspa. When the linestrings have small 
segments close to the tolerance the results can be invalid geometries 
because the algorithm does not chose the right vertexes to move.

It does not have an easy solution. According to my test one of the 
solution would be first to remove closed vertexes in the geometries and 
then try to adjust them as ArcGIS does with the cluster tolerance.

For me and for any person who is working with cartography the tolerance 
is crucial. I tried many months ago in the PostGIS and JTS lists to 
discuss and to explain how important is a tolerance system but 
unfortunately I didnt conviced many people.

Im happy though that with persistent topology maybe its going to be the 
first time I can use PostGIS with a complex cartographic model without 
breaking the spatial relation ships among closed geometries every time I 
want to modify one geometry as in a simple feature model happens. (-:

Best,
Jose

On 21/03/2012 9:44, Sandro Santilli wrote:
> On Tue, Mar 20, 2012 at 03:55:34PM -0700, Paul Ramsey wrote:
>> How much should I expect from topology? I just took a polygon file
>> that had contiguous non-overlapping polygons and did this:
>>
>> cded=# select TopoGeo_AddPolygon('sheds', st_geometryn(geom,1), 5.0)
>> from sheds where gis_tag like 'VICT%';
>>
>> ERROR:  Spatial exception - geometry intersects edge 39
>> CONTEXT:  PL/pgSQL function "topogeo_addlinestring" line 175 at assignment
>> SQL statement "SELECT array_cat(edges, array_agg(x)) FROM ( select
>> topology.TopoGeo_addLinestring(atopology, rec.geom, tol) as x ) as
>> foo"
>> PL/pgSQL function "topogeo_addpolygon" line 27 at assignment
>>
>> This is a non-overlapping set of data, originally generated from
>> vector clean ArcINFO coverages...
>>
>> select a.gis_tag, b.gis_tag from sheds a, sheds b where
>> st_overlaps(a.geom,b.geom) and a.gis_tag like 'VICT%' and b.gis_tag
>> like 'VICT%';
>>
>> (0 rows)
>>
>> Thoughts?
> It shouldn't happen. Can you share the data or a portion of it ?
> The idea is that those functions never fail, at the possible cost of
> giving you spaghetti result (hey, that's the official ISO/SQLMM term
> for the result of ST_CreateTopoGeo, as reported by the author!).
>
> Note that for non-overlapping data you probably don't need a big tolerance.
> Tolerance uses ST_Snap which in turn is known to possibly introduce geometry
> invalidities [1]. Not always snapping to the _closest_ item may also
> introduce unpredictable outcomes.
>
> [1] http://trac.osgeo.org/geos/ticket/501
>
> Bottomline: you shouldn't expect 100% success during construction, but
> you can expect being able to construct incrementally thus fixing or working
> around issues as you encounter it. Once the topology is built you can
> use more robust editing routines on the primitive level (SQLMM editing)
>
> --strk;
>
>    ,------o-.
>    |   __/  |    Delivering high quality PostGIS 2.0 !
>    |  / 2.0 |    http://strk.keybit.net - http://vizzuality.com
>    `-o------'
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel