Hi!
Actually, Im not working in a project which needs topology, but a year
ago I made a little cost analisis about implementing topology, Ive
been listening your thread with interest and Id like to explain some
ideas.
How about not to implement explicit topology? I was thinking about a
model like ArcSDE Topology Rules.
I'll explain this. In ArcSDE you can implement topology rules, like
triggers that reviews some topology constraint every time you edit a
geometry (before or after). For example, you have a FeatureCollection
with a polygon feature that represents a country, which is
subdivided in regions -another FeatureCollection-. If you change a
region, you'll like to change country geometry so the country's
geometry would be an aggregate of its regions' geometry.
To do that, we must have a FeatureRelationship class which relates
both FeatureCollection. This relationship could be alphanumeric or
topologic. To implement that, we could work with an abstract class
like this:
public abstract class FeatureRelationship{
FeatureCollection master;
FeatureCollection slave;
public abstract Feature[] getSlaves(Feature feature);
public abstract Feature[] getMaster(Feature feature);
}
A FeatureRelationShip instance could have many RelationShip rules.
When we would edit a feature, we would get its related features (the
master or the slaves, in a 1:N relationship), and we would apply its
topology -or bussines- rules:
public interface TopologyRule{
public boolean verify(Feature[] featuresOfAFeatureCollection,
Feature[] featureOfBFeatureCollection);
}
If these topology rules dont verify, it would throw some events, and
some listeners would process it.
These topology rules also could be implemented with triggers of an
spatial database.
Regards.
On 10/5/05, Luca Sigfrido Percich <[EMAIL PROTECTED]> wrote:
> Hi Vitali, hi all,
>
> yes, I've found a lot of great ideas in your proposal, Vitali. The
> nice thing is that you are mainly working on Udig, while I'm working
> on GeoTools/Geoserver, so we've got a chance to unify the Topology
> Data Model (TDM) view. From your mail, I would propose these focus
> points:
>
> - TDM as an "overlaid" model over a SimpleFeature model. Data is
> saved in tables using SimpleFeatures, no explicit topology support,
> so we need to implement the persistence of topology.
>
> - Unify as much as possible TDM on client and server side. Metadata
> can help in keeping track of topology, i.e. when I modify the
> "RoadElement" FeatureType, uDig automatically knows that RoadElements
> are connected at Junctions and network topology has to be preserved.
> Code should be organized in a modular way so for example I can run
> tha same Validation on GeoServer and Udig. Metadata is stored in
> normal FeatureTypes, so it can be accessed client- and server-side.
> Code should be pluggable in a shared framework architecture (I
> presume we should implement this in GeoTools).
>
> - Mantaining topology while editing (before commit) requires
> dedicated procedures. If I split an arc, a node has to be instantly
> created at the split point. If I move a node, all the connected acrs'
> enpoints have to be moved along with it. And so on. These procedures
> are not likely to be useful on server side, but they might be built
> on top of a geometry-handling API.
>
> - Topology means attributes + geometry. If I provide a tool to
> geometrically split a poligon, or to combine more polygons, the same
> tool should allow me to deal with attributes: aggregate /
> disaggregate (weighting by area) or simply keep the existing feature
> attributes into the derived features.
>
> - Topology means relationship: if I split or combine arcs in a
> network, the start/end node IDs have to be recalculated. If I create
> a new node and I still don't know its FID, how can I save the
> relationship with the connecting arcs? Many GIS systems use internal
> numeric IDs for keeping track of such relationships.
>
> Why do we express topological relationships through "foreign keys"
> (relationships by attribute) instead of relying solely on geometric
> relationships (i.e. the start node of this arc is the node which
> intersects the first vertex of the arc)? Mainly for two reasons:
>
> 1. Topology has always a semantic. The boundary between two polygons
> in not simply an arc, it may have attributes. Connections in a
> network tell us how traverse it. And so on. Semantic is better
> expressed by explicit relationships based on attributes.
>
> 2. FK are quicker to navigate than geometric relationships.
>
> - Topology is expensive. Thinking of a topological framework is hard,
> making it operate with reasonable response times is even harder.
>
>
> On 5 Oct 2005 at 13:15, Vitali Diatchkov wrote:
>
> > TDM can be built from simple feature model. It is quite expensive
> > operation but it should be performed once, just build TDM.
>
> Tipically we would need a first "build" and eventually check /
> correct only the modified features. We should always be able to
> rebuild / revalidate topology from scratch.
>
> > give benefits during next editing operations while it is much more
> > easier to deal with TDM directly then each time perform validation of
> > topology consistence after each atomic operation.
>
> Here we should focus in keeping all the edits "local" on uDig, and
> perform a single commit after topology has been built. We could
> provide an "unable to commit if topology isn't clean" validation on
> client side, thus avoiding to have a topology framework on server-
> side, for example if we are working on shapefiles or PostGIS. But we
> would also free to read data from WFS in uDig, and have a topology
> framework on GeoServer, with a topological check on transaction
> commit.
>
> Somehow local edits on topology-enhanced FeatureTypes should be
> cached, we should be able to work with a Transaction logic even on
> client side. This mainly because we have to treat as atomic a list of
> edits performed on different Features and maybe on different
> FeatureTypes (see the previous example on arc/node) in order to have
> a single atomic topological operation.
>
> > simple feature model from TDM is quite straightforward operation, just
> > traverse graph in a special manner.
> >
> > We have the following "frameworks" :
> >
> > Com.vividsolutions.jts.geomgraph
> > Com.vividsolutions.jts.planargraph
> > Org.geotools.graph
>
> I used graphs to implement a Location service, but never tought of
> using them for topology. I'm quite interested in this idea!
>
> > Topology data model doesn't replace simple feature model. It serves as
> > an auxiliary model for performing various complex editing operations
> > maintaining topology consistence automatically. We edit TDM and
> > reflect local changes to simple feature model.
>
> Yes. Thinking about client side we could:
>
> - Read Metadata (the "declarative" topology")
> - Read the SimpleFeatures
> - Build an in-memory TDM with the Features read using metadata info
> - Perform edits on the TDM (which might use of support classes for
> flagging edited features, caching results, perform rollbacks...)
> - "Commit" the TDM -> write back the modified Features.
>
> We could also think of "partial TDM" built on an MBR basis, to reduce
> the overhead. This could also be aligned with a pluggable Feature
> locking system, or use the WFS getFeaturesWithLock.
>
> > Different application requirements suppose various TDM. Having one
> > complete TDM sometimes is often redundant and make influence on
> > performance where just small piece of functionality is needed.
>
> I would propose to write a wiki page with all the possible Topology
> models. For example, dealing with polygons we may need only to check
> boundary consistency (no overlaps or slivers), or we may ned to
> identify the arcs which form the boundary between polygons. If Vitaly
> doesn't mind, I can start the page with all the cases I simply listed
> in my former email, then we both can go on editing it.
>
> > topology consistence automatically. Validation in the end is optional
> > while TDM guarantees consistence after each atomic operation.
>
> I agree. This is by far flexible, allows users to use a rich client
> (uDIg) with a simple RDBMS for storage, or use a web client with
> GeoServer, or both a thick client and GeoServer.
>
> > I talk about topology in terms of auxiliary data structure to
> > facilitate editing operations.
>
> Yes, and on this "topology-enhancing" data structure we can overlay
> different procedures for visually editing, building, mantaining and
> validating topology.
>
> I'll start the Topology wiki ASAP.
>
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
Alvaro Zabala Ordóñez
Miembro fundador de AGIL
Asociación para la promoción del GIS Libre
www.agiles.org
Funcionario del Cuerpo de Gestión de Sistemas e Informática de la
Administración General del Estado.
Confederación Hidrográfica del Guadalquivir.
Teléfono: 954939523
Plaza de España, sector II.
SEVILLA
-------------------------------------------------------
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
