Seems we are talking about one thing. That is good!
Topology deals with geometries. But geometry can be just attribute of anything. So any entity that is somehow bound to geometry (or geometry is bound to entity) begins to be an entity for topological analysis. We can build TDM from set of geometries. OK. We have features. Do features have geometry as an attribute? Yes, they do. OK. We can build TDM from features.... Here WAS misunderstanding. Am I right...? > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:geotools-devel- > [EMAIL PROTECTED] On Behalf Of Luca Sigfrido Percich > Sent: Thursday, October 06, 2005 5:28 PM > To: [email protected]; Matthias Basler > Subject: Re: [Geotools-devel] Re: Proposals: Topology > > Hi Matthias, > > sorry if my explanation wasn't clear. I'll try to be clearer. > > On 6 Oct 2005 at 15:00, Matthias Basler wrote: > > > - Geometry cares about describing the ... well ... geometry (in > > mathematical sense) of a feature - There are validation rules that > > might apply to check, if, f.e. geometries are allowed to overlap etc. > > The validation rule of overlapping implies more than one geometry, > and must be run over a collection of *Features*. You can do such > validation only if considering Geometries as Feature attributes, so > you can say that a certain Feature is valid because it's geometry > doesn't overlap with the geometry of another Feature. > > > - Features hold the (or some) geomtry/-ies and attributes. When I > > think about attributes I have the "usual" attribute table in mind, > > which means that I speak of "user-defined" attributes, attributes that > > the user somehow attached to the geometries - nothing "geotools > > internal". > > Ok. I would specify, that a Feature is not a way to attach attributes > to a Geometry. A Feature is simply a set of attributes, some of which > might be geometries. > > Features can be related to each other by means of their attributes. > > You can group all the Road Features that share the same "roadClass" > String value. And you can relate two features because their "geom" > Polygon attributes touch or intersect. There relations might be built > within the same FeatureType or different FeatureTypes. > > Most GIS system express topological relationships in both ways: > implicitly (the geometries themselves are related, so the Features > owning them) and explicitly (storing the IDs of the related > Features). > > A plain example: > > FeatureType RoadElement: > LineString geom; > String id; > String startJunction; > String endJunction; > ... > > FeatureType Junction: > Point geom; > String id; > > > Topological relationships: RoadElement and Junction form a linear > network; RoadElements are the "arcs" connectiong Junctions (the > "nodes"). > > Geometrically speaking, I could simply put all the geometries in a > collection, and check that: > > - no node exists if not connected to an endpoint (first / last > coordinate) of an arc; > - no arc exists if not connected through both endpoints to one or two > nodes. > - two arcs may not intersects but at their endpoints. > > What a GIS would usually do would be materializing the arc/node > geometrical relationship into a simple attribute-based relationship, > i.e. storing the start/end node id in the arc. In our example, we > would like to store the Junction id in the startJunction / > endJunction attributes of the RoadElement Feature. Once that topology > is validated, the network can be navigated simply by non-geometric > attribute, i.e. ID lookup. Otherwise, every time I need to grep the > start Junction of a given RoadElement I have to perform a query with > the intersect operator between the first coordinate of the > RoadElement geometry and the geometry of Junctions. > > > Now, a topology whould combine the geometry (in mathematical sense) > > and some special rules into topological objects that would take care > > about validation and what is possible, without Features and attributes > > and such getting involved primarily. Features would work as above. > > I'd like to discuss more about "topological objects", maybe you are > thinking about something similar to org.geotools.graph? > > I don't agree that features don't get involved. First, you need to > know which Feature is topologically correct or not; moreover, you > could have topological check that take into account non-geometric > attributes, for example: intersections not at the endpoint of two > RoadElements are allowed if one of them has the Boolean attribute > "onBridge" set to true. > > > In my understanding the (spatial?) "relation" of features to each > > other is managed in one central object (the "topology"?), which could > > maybe become incorporated into a FeatureCollection? > > You're right, topology is something which works at the "collection" > level. It would be great working at some abstraction level like a > "FeatureRelator" object which can define the way features are related > to each others in terms of geometries and non-geometric attributes. > > I promised to start a wiki page with topology use cases. This could > be a good starting point so we can see what we need for building > topology, what use we plan to make of it and so on. > > Cheers > > Sig > > > > ------------------------------------------------------- > 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 ------------------------------------------------------- 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
