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
