Hi All, I'm also very interested in Topology, and I'll have to implement it in our road information system.
On 24 Sep 2005 at 0:06, Matthias Basler wrote: > Citing Diatchkov Vitali: > > It is obvious during vector data editing operations it is necessary > > to preserve topological consistence between different vector > > objects. Not necessarily during edit. You may have also an inconsistent topological state during edits, and when you're finished editing (i.e. you permorm a Transaction.commit()) the Feature set is checked against topological constraints. Node snapping, aligned Feature editing and so on should be handled on the client side. When Features are committed on the server, they can be just checked for topological consistency, it's hard to think about a server-side topologycal auto- completion (i.e. add the end nodes for a new arc). > > Feature model is not appropriate at all because of there is > > no topological information keeping when each feature is supposed as > > a standalone feature. The case is when two features with polygonal > > geometries touch each other A good solution seems to be using a Simple Feature model along with application metadata which keep track of topological relationships, and Validation objects to check for it. BTW we're working at applicatrion metadata here: http://docs.codehaus.org/display/GEOTOOLS/Meta+Information+Infrastruct ure and soon add a Topology section - hope afer our discussion! > of second feature. I want to move common segment of both features > simultaneously. When we have simple model of features with geometry > without topological information it is hard to maintain topological > relations. If we use metadata, a thick client could read them and use pre- defined Calculation objects to perform the modifications resulting from changing a Feature (i.e. if I delete a dangling arc, delete the orphaned node; if I move a polygon boundary, snap to it the boundary of the intersecting polygons). > > So the proposal is to build Topology Data Model for such operations > > from a list of simple features with geometry. I do agree. Topology can be viewed a set of explicit associations between Features, associations which correspond to certain geometric properties and relationships. I can use geometry to "calculate" the associations, but then I store the association instances as I would do in a normal RDBMS - as "foreign keys". For now I only focused on topology Definition and Validation, and I envisaged the following "framework". I identified the following topological relationships (more to come I hope!): Network LinearReferencingSystem PointOnLIne SegmentOnLine RouteSystem SubNetwork PolygonBoundary (polygons delimited by LineStrings) FeatureComposition (Generalization) Each "Topological relationship" can be described (with application metadata) in terms of: - which FeatureTypes are involved - which association between the given FT express the relationship (please note that associations are already described in our app metadata) - which IntegrityValidation object(s) can check it, and which parameters are needed to it. EXAMPLE the simplest ;o) - Network topology A Network is composed of a "LineString" FeatureType (i.e. a FeatureType having it's default geometry set to LineString) - let's call it {ARC} - and a "Point" FeatureType - let's call it {NODE}. Each instance of {ARC} starts into and instance of {NODE}. This is expressed by the {START_NODE} relationship defined for {ARC}. Each instance of {ARC} ends into and instance of {NODE}. This is expressed by the {END_NODE} relationship defined for {ARC}. This topological relationships is checked by a NetworkTopologyIntegrityValidation class, which is the connected to the transaction Validations by the metadata engine. In metadata, we can declare that: - "RoadNetwork" is an instance of Network RoadNetwork.ARC = RoadElement (Name of a FeatureType) RoadNetwork.NODE = Junction RoadNetwork.START_NODE=startNode (name of the association already defined in metadata) RoadNetwork.END_NODE=endNode We could plug a simple TopologyValidation which checks if any of the FeatureTypes involved in the Transaction is part of a Topological Relationship, and, if so, instantiates the proper TopologyValidation object. Inside the code of NetworkTopologyIntegrityValidation, {ARC}, {NODE}, {START_NODE}, {END_NODE} are parameters which are used to access the proper features and metadata in order to perform the check: - each arc points to two existing nodes. - the coordinates of the nodes are the same of the starting and ending point defining the arc's LineString - a node cannot exist if it's not connected to at least one arc. More checks can be added, possibly in different Validation objects: - two arcs may not intersect in a point which is not a node: true for rivers, false for streets in the case of bridges. The check could be not trivial - if two RoadElements have a crossing not on a node, and if none of them is on a bridge, then there is an error. - Allow rings (start_node = end_node)? All of these checks could be described in metadata. The former are "declarative" topologies, well, we can also think about "procedural" topologies: LayerDerivation (Derive LineStrings from LineStrings) Skeletonization (Derive LineStrings from polygons) (I mean, each time I modify a polygon, the system will automatically generate it's linear representation). Yes, we're planning to derive the road network from the polygon representation of roads. Sounds a bit sci-fi, I know... ;o) I'm still thinking about how to formally describe topologies in metadata, I hope that a discussion will follow so we can share ideas and thoughts and reach a common solution. 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 ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
