Hi Mattias, On 6 Oct 2005 at 21:28, Matthias Basler wrote:
> 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. I understand. I also understand that probably you have a more "mathematical" approach to topology, while I'm mostly focused on topology application to geographic databases. Moreover, my personal view of GIS is trongly "database oriented", so to me geometry is nothing more than an attribute like name, address, road type and so on. Sure the two approaches are not "incompatible" but need to be somehow "resized" and placed correctly one near the other so we can plan a good API for topology. BTW: I don't like CAD because CAD is still extensively used for preparing maps... and people using CAD usually is still focused on "drawing" rather than on data and database design. ;o) > 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. Maybe it's not needed at the geometric level. But think of application tasks like "select all the borderlines that separate polygons of type A from polygons of type B" - this of if you have separated edges composing the faces. But maybe not - I'm a bit sticking with ArcInfo 7.0 topology model in which the faces are made of lists of edges, so altering an edge means altering both faces. > > 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. Yes, but in a GIS I usually don't need *just* the coordinates of the start point - I need the *Junction Feature* - which has a point geometry located at the start (or end) point of the geometry of a RoadElement (and this is the implicit relationship) - and I need the Feature because the Junction has related info on vehicle manoveurs, traffic light regulation and so on... What you say is right from a geometric perspective - moreover, geometrically speaking a Junction could also not exist at all if I guarantee the arc connections at endpoints. But in GIS I need to deal with Features - so, to find the start Junction, I have to perform a query with an intersect operator, or better find the junction which coordinates are equal to the coordinates of the starting point of the arc. That's why in GIS we always store the IDs. Sure the IDs can be assigned by the topology engine, but once topology has been validated I can traverse the graph without having to deal with geometry. Probably we should try to separate two levels of relation: the base, lower level is topological and deals with Geometries. The second one is logical and deals with features (or objects, or entities, call them as you like). > > 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 ;-) Oh, yes, that's what I wanted to ask you: let's say you deal with geometries only. Do you expect to use IDs for geometries? Or do the geometries relate to each other simply by reference (I mean Java object variables or pointers). > 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. I don't like the idea of using 3D, mostly 'cause I'm a flat-minded dinosaur. :o))) It's a step forward "cartography", i.e. 2D representation... and sure in future mapping apps, especially in urban situation, it will be more and more important. For now I'd rather stick on 2D models. I started the Topology wiki at http://docs.codehaus.org/display/GEOTOOLS/Topology+Framework and added a page with use cases from my work on road networks (just a skeleton, I still have to write down everything, I hope during the weekend). You and Vitali and anybody else interested are strongly encouraged to do the same: let's see how we think topology, for what we need it (editing, validation, GIS, logic modelling)... this will help us in planning a good API. > 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. This could be a good approach. Ups, I see that docs.codehaus.org is down right now... Better luck tomorrow morning I hope! ;o) 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
