Hi! Continuing the discussion about Topology Data Model for vector data inside of UDIG.
The following editing tools are common for every GIS system (in terms of
feature geometry):
-Divide polygon
-Merge two adjacent polygons
-Cut piece of one polygon and add it to adjacent in case this piece
is touches common border
-Delete polygon
-Move common border for adjacent polygons
These operations should be considerable in context of topology consistence
between different geometries.
TDM can be built from simple feature model. It is quite expensive operation
but it should be performed once, just build TDM. TDM will give benefits
during next editing operations while it is much more easier to deal with TDM
directly then each time perform validation of topology consistence after
each atomic operation. The back building of simple feature model from TDM is
quite straightforward operation, just traverse graph in a special manner.
We have the following "frameworks" :
Com.vividsolutions.jts.geomgraph
Com.vividsolutions.jts.planargraph
Org.geotools.graph
Models of those frameworks differ in terms of various involved entities and
operations.
In most cases for counted editing operations needed TDM is more simple and
Oracle Topology Data Model is the most appropriate as an example what
editing tools need. I suppose so, Oracle TDM is not overloaded by different
additional constructions and objects. While feature model may be huge, the
performance of building TDM, memory issues, etc. are important. As simple
TDM we have and editing operations are satisfied with it so much the better.
The important issue.
Topology data model doesn't replace simple feature model. It serves as an
auxiliary model for performing various complex editing operations
maintaining topology consistence automatically. We edit TDM and reflect
local changes to simple feature model.
Different application requirements suppose various TDM. Having one complete
TDM sometimes is often redundant and make influence on performance where
just small piece of functionality is needed.
In this proposal I consider TDM as an auxiliary model to make editing of
vector data easier and more powerful. And TDM is used directly during
editing step. There are two cases:
-Perform any editing operations without just-in-time validation.
Validation of topology consistence is checked during transaction
committing, for example in the end.
-Perform editing operations over TDM directly and it maintains
topology consistence automatically. Validation in the end is optional
while TDM guarantees consistence after each atomic operation.
I choose the second case.
What is about Luca Sigfrido Percich suggests in
http://docs.codehaus.org/display/GEOTOOLS/Meta+Information+Infrastruct
and how to apply that MII to topology validation, it would be quite powerful
framework for unified topology validation described declaratively by "meta
information" (see attachment file).
I talk about topology in terms of auxiliary data structure to facilitate
editing operations.
Any suggestions, comments, questions to find the golden mean.
Vitali Diatchkov.
<<attachment: winmail.dat>>
