Zitat von Luca Sigfrido Percich <[EMAIL PROTECTED]>: > sorry if my explanation wasn't clear. I'll try to be clearer.
Thanks a lot for you well explaination here. I will try to comment on it inline: > 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. Well, I looked at JTS. JTS can intersect (or union) two geometries and create a new geometry from it. It doesn't need to know if the two geometries are "feature attributes" or are used in a CAD program or anything else. Likewise I believe a topology validation engine does not need to know anything about "Features", "Attributes" (or generally speaking the context in which it is used) to do the (basic) validation. > 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. Agree. This is the Geotools (and OGC) way of looking at it. > 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. Yes, this is known to me. > 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). Guess this is the interesting part: What I have in mind is probably implicite relationships. If two faces share the same edge then moving the edge will implicitely edit both face geometries. I wouldn't intuitively use "explicite relationships" (i.e. feature attributes) for the above task. I would use "explicite relationships" for example to define a "road" as an ordered set of "road elements", to stay with your example. > A plain example: > > FeatureType RoadElement: > LineString geom; > String id; > String startJunction; > String endJunction; > ... > > FeatureType Junction: > Point geom; > String id; Nice example: If I'd do it it would look like: FeatureType RoadElement: LineString geom, implicitely storing the geometry of start and end junction id String id .. FeatureType Junction: Point geom; String id; > 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. Well, that reflects my view. > 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. I see the reason behind this. > 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. Huh? An intersect operation for getting the start or end junction. Doesn't make sense for me. In my example above you would query the geometry attribute (an edge/arc) and would simply "ask" it for it's start and end point. > I'd like to discuss more about "topological objects", maybe you are > thinking about something similar to org.geotools.graph? Probably. Will have a look at it, when I find some time. > I don't agree that features don't get involved. First, you need to > know which Feature is topologically correct or not; For me: ... which geometry 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. Good point. Now we leave the territory of classical topology and come to GIS-specific validation. I guess for such cases we would indeed not be able to use any existing "general topology API" as I describe it above, but we would either need something really GIS-aware (validation using non-geometrical attributes as you imagine it) ... .. or a 3D topology, which could deal with the bridge example easily without knowing anything about "onBridge" attributes. To make one point: I do not say that ALL validation should be done on the "geometry collection" level, rather do I imagine that basic rules like "no overlap", "common edge/node handling" etc. could be implemented there and that GIS-specific (or feature type specific) validations could be on top of it, at the "FeatureCollection" level. But I could understand if people say they want to have all validation on one central place (on the "FeatureCollection" level) and the geometric primitives should not care about this at all. > 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. I'm looking foreward to this wiki page. Matthias Basler [EMAIL PROTECTED] ---------------------------------------------------------------- This mail was sent through http://webmail.uni-jena.de ------------------------------------------------------- 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
