Hi Vitali, hi all, yes, I've found a lot of great ideas in your proposal, Vitali. The nice thing is that you are mainly working on Udig, while I'm working on GeoTools/Geoserver, so we've got a chance to unify the Topology Data Model (TDM) view. From your mail, I would propose these focus points:
- TDM as an "overlaid" model over a SimpleFeature model. Data is saved in tables using SimpleFeatures, no explicit topology support, so we need to implement the persistence of topology. - Unify as much as possible TDM on client and server side. Metadata can help in keeping track of topology, i.e. when I modify the "RoadElement" FeatureType, uDig automatically knows that RoadElements are connected at Junctions and network topology has to be preserved. Code should be organized in a modular way so for example I can run tha same Validation on GeoServer and Udig. Metadata is stored in normal FeatureTypes, so it can be accessed client- and server-side. Code should be pluggable in a shared framework architecture (I presume we should implement this in GeoTools). - Mantaining topology while editing (before commit) requires dedicated procedures. If I split an arc, a node has to be instantly created at the split point. If I move a node, all the connected acrs' enpoints have to be moved along with it. And so on. These procedures are not likely to be useful on server side, but they might be built on top of a geometry-handling API. - Topology means attributes + geometry. If I provide a tool to geometrically split a poligon, or to combine more polygons, the same tool should allow me to deal with attributes: aggregate / disaggregate (weighting by area) or simply keep the existing feature attributes into the derived features. - Topology means relationship: if I split or combine arcs in a network, the start/end node IDs have to be recalculated. If I create a new node and I still don't know its FID, how can I save the relationship with the connecting arcs? Many GIS systems use internal numeric IDs for keeping track of such relationships. Why do we express topological relationships through "foreign keys" (relationships by attribute) instead of relying solely on geometric relationships (i.e. the start node of this arc is the node which intersects the first vertex of the arc)? Mainly for two reasons: 1. Topology has always a semantic. The boundary between two polygons in not simply an arc, it may have attributes. Connections in a network tell us how traverse it. And so on. Semantic is better expressed by explicit relationships based on attributes. 2. FK are quicker to navigate than geometric relationships. - Topology is expensive. Thinking of a topological framework is hard, making it operate with reasonable response times is even harder. On 5 Oct 2005 at 13:15, Vitali Diatchkov wrote: > TDM can be built from simple feature model. It is quite expensive > operation but it should be performed once, just build TDM. Tipically we would need a first "build" and eventually check / correct only the modified features. We should always be able to rebuild / revalidate topology from scratch. > 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. Here we should focus in keeping all the edits "local" on uDig, and perform a single commit after topology has been built. We could provide an "unable to commit if topology isn't clean" validation on client side, thus avoiding to have a topology framework on server- side, for example if we are working on shapefiles or PostGIS. But we would also free to read data from WFS in uDig, and have a topology framework on GeoServer, with a topological check on transaction commit. Somehow local edits on topology-enhanced FeatureTypes should be cached, we should be able to work with a Transaction logic even on client side. This mainly because we have to treat as atomic a list of edits performed on different Features and maybe on different FeatureTypes (see the previous example on arc/node) in order to have a single atomic topological operation. > 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 I used graphs to implement a Location service, but never tought of using them for topology. I'm quite interested in this idea! > 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. Yes. Thinking about client side we could: - Read Metadata (the "declarative" topology") - Read the SimpleFeatures - Build an in-memory TDM with the Features read using metadata info - Perform edits on the TDM (which might use of support classes for flagging edited features, caching results, perform rollbacks...) - "Commit" the TDM -> write back the modified Features. We could also think of "partial TDM" built on an MBR basis, to reduce the overhead. This could also be aligned with a pluggable Feature locking system, or use the WFS getFeaturesWithLock. > 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. I would propose to write a wiki page with all the possible Topology models. For example, dealing with polygons we may need only to check boundary consistency (no overlaps or slivers), or we may ned to identify the arcs which form the boundary between polygons. If Vitaly doesn't mind, I can start the page with all the cases I simply listed in my former email, then we both can go on editing it. > topology consistence automatically. Validation in the end is optional > while TDM guarantees consistence after each atomic operation. I agree. This is by far flexible, allows users to use a rich client (uDIg) with a simple RDBMS for storage, or use a web client with GeoServer, or both a thick client and GeoServer. > I talk about topology in terms of auxiliary data structure to > facilitate editing operations. Yes, and on this "topology-enhancing" data structure we can overlay different procedures for visually editing, building, mantaining and validating topology. I'll start the Topology wiki ASAP. Cheers Sig -- Luca Sigfrido Percich ([EMAIL PROTECTED]) Agenzia Milanese Mobilità e Ambiente s.r.l. (http://www.ama-mi.it) Direzione Sistemi Informativi e Modellistica Via Beccaria, 19 - 20122 Milano - tel. +39 02 884.67.262 ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
