[postgis-devel] topology expectations?

[Jose Carlos Martinez]

Hi Sandro, I want to share the problems I got and especially the 
conclusion which I reached about beeing a couple of weeks dedicated to 
change and improve the JTS Snap method, but at this poiint I can not 
give you details (the main reason is that I forgot many things about the 
different algorithm I tried).

Anyways I remember the main conclusions. The procedure I followed was:

1.- I detected the JTS snap method is not working. Not because it has 
bugs but because the algorithm does not chose the right vertexes, 
specially when the segments are shorter os similar to tolerance distance.
2.- I detected too the JTS snap method is not optimized for performance 
(Martin already said that in the source code)

3.- I implemented some spatial indexes within geometries in the snap 
process and the result were very satisfactory. The speed was not the 
goal though but at least we can improve it.
4.- I did many many tests with different variations to the JTS algorithm 
even designing new algorithms (checking validity and according to that 
moving the selected vertex or segments).  The tests told me that these 
algorithm had a better behaviour but they still couldnt work in 100% of 
the cases (*)

5.- Finally I reached the conclusion that before using snap algorithm 
the geometries have to be cleaned according with some algorithm that:
       - Remove shorter segments than tolerance distance.
       - Remove closer vertex than tolerance distance

The bad news is 5) is going to collapse some geometries but if it 
happens means the geometries are not ready

Its funny that after doing a lot of work I noticed that I finished 
imitating AcGIS cluster tolerance procedure.

(*) its not going to work when geometry A is snapped to B and B to A, 
but then another geometry C has to be snapped to A and then it changed 
geometry A which loose the spatial relation ships with B. But this issue 
is just needed in a  simple feature model where the spatial relation 
ships between adjacent or close geometries must be kept. So if means you 
can not change a geometry without changing the adjacent geometries. My 
opinion is that the solution is to use persistent topology or a system 
which adjust all the geometries around all the layers. I did that in a 
experimental way with Jaspa and it worked. One more time I finished 
imitating arcgis cluster tolerance between layers. My opinion about that 
is that to use a complex cartography model in PostGIS one just have one 
way: using persistent topology, thats way Im really interested in your 
work. Unfortunately I think we need materialized views (as you said) 
otherwise persistent topology in a relational model is going to be too slow.

Some one is interested in developing a persistent topology model in db4o 
o perst? Im thinking about that to be my next research project.

Sorry about I cant give you more details now, you can check jaspa source 
code thogh. When I have time I will check it too to remember the steps I 
made in a more detailed way.

Anyways thanks a lot for your work in PostGIS!!


On 26/03/2012 10:10, Sandro Santilli wrote:
> On Wed, Mar 21, 2012 at 09:44:00AM +0100, Sandro Santilli wrote:
>> On Tue, Mar 20, 2012 at 03:55:34PM -0700, Paul Ramsey wrote:
>>> 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
>> 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
> For the record: the topology construction robustness issue was fixed:
> http://trac.osgeo.org/postgis/ticket/1706
>
> The problem was confirmed being about use of ST_Snap for handling tolerance,
> that is: specifying a tolerance could currently do worst than not
> specifying one, due to ST_Snap doing a suboptimal work.
>
> If anyone wants to help with improving ST_Snap please do with ideas here,
> on the wiki [2], in the GEOS ticket [3].
>
> [2] http://trac.osgeo.org/postgis/wiki/ToleranceDiscussion
> [3] http://trac.osgeo.org/geos/ticket/501
>
> --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