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
