[postgis-devel] Some thoughts on Topology

Tue Nov 1 02:04:55 PST 2005

Charles, I'll be probably busy on other tasks for the following month. 

If you want to contribute please try to keep the discussion at the
conceptual level, possibly commenting on the ER. Anything below it
is there as a proof of concept, not being the product of a top-down
design.

If you can't read .xfig files I can include a .png version in CVS,
but I strongly reccommend installing Xfig.

Thanks.

--strk;

On Fri, Oct 28, 2005 at 11:17:59AM -0600, Charles F. I. Savage wrote:
> Thanks for the feedback strk.  Some more thoughts...
> >To obtain better performances we should keep separate RELATION
> >and TOPOGEOMETRY tables for each layer in a topology. I've been
> >thinking about using a TopoGeometry table, also for referential
> >integrity between feature tables and existing TopoGeometries.
> >  
> There are some advantages to having a big relation table - if you want 
> to render a map there is one table where you go to extract out all the 
> information from one place as opposed to having to query a bunch of 
> tables to get what you need. 
> 
> A middle ground is to have topogeom_point, topgeom_line and 
> topogeom_area tables.  A topogeom_point table would include the 
> topogeom_id's for all topogeometries that were points (so each one 
> points to a node), topogeom_line would hold all topogeometries that were 
> lines (i.e., made up of edges), etc.   You would also need 3 relation 
> tables.  For instance, one would be a topogeom_line_relation table since 
> a topogeom_line can constist of many edges, an edge can be part of many 
> topogeom_lines.
> 
> So something like:
> 
> CREATE TABLE topogeom_line
> (
> topogeo_id int4 DEFAULT nextval("topogeometry_id_seq") NOT NULL,
> layer_id int4,
> CONSTRAINT topogeometry_key UNIQUE (topogeo_id)
> )
> 
> CREATE TABLE topogeom_line_relation
> (
> topogeo_id int4 NOT NULL,
> element_id int4 NOT NULL,
> element_type int4 NOT NULL,
> CONSTRAINT relation_layer_id_key PRIMARY (topogeo_id, element_id, 
> element_type)
> CONSTRAINT fk_line_relation  FOREIGN KEY (topogeom_id) REFERENCES  
> topogeom_line (topogeo_id);
> )
> 
> An advantage, or disadvantage (depending on your way of thinking) of 
> this way of doing things is that you've segregated different types of 
> geometries so you don't need the element_type field anymore - its 
> implied by the table in which the topogeom is defined.  An interesting 
> point you brought up the last email was dealing with collections of 
> things - say multiple topogeometries that are linear.  I haven't thought 
> through how those would fit in (maybe separate top level top geom tables 
> for them, maybe not).
> 
> >About info duplication in TopoGeometry object the only redundancy
> >is really only TopoGeometry type, as TopologyId, LayerId and
> >TopoGeoId are needed to reference a specific TopoGeometry.
> >
> >  
> In the current implementation I agree those fields are needed to 
> reference a specific TopoGeomeetry.  However, that doesn't mean their 
> isn't duplication of information - it just means the current 
> implementation is not as normalized as it could be thus forcing this 
> information to be duplicated.  The addition of a TopGeometry table, as 
> discussed in my last post, would make all the information contained in 
> the TopoGeometry objects redundant, plus remove at least one column (the 
> layer_id column, which would move to TopoGeometery) from the relation table.
> 
> >The TopoGeometry type can be see like a cache.
> >Take the GeometryType(TopoGeometry) function (not implemented yet).
> >If you drop it from the TopoGeometry table you'll be forced to 
> >make assumptions about the type looking at components.
> >Still (apart from performance) a geometry composed by two faces
> >could be both a Polygon (the faces are contained one within the other)
> >or a MultiPolygon (the face are disjoint), or a Collection (that currently
> >just happen to contain those two faces).
> >  
> Yes, interesting point...see above.
> >If you read initial part of topology.sql.in you'll see SQL/MM functions
> >and PostGIS specific functions. The SQL/MM specification says nothing
> >about TopoGeometry types, just primitive node,edge and face.
> >  
> Great - I've read through a fair bit of topology.sql.in and see the list 
> of SQL/MM functions at the top.
> >So we are doing a mix of the two.
> >SQL/MM interfaces are implemented:
> >	- topology model (a topology is a schema, containing well defined
> >	  edge,face,node tables)
> >	- topology operations (see functions with ST_ prefix)
> >
> >  
> I'm not sure I understand the reasoning behind a topology is a schema.  
> Let's say I run a city GIS and am storing all the city spatial data in 
> PostGIS.  Now let's say I need to model various networks, maybe a 
> road_network, an electrical_network and a water network.  Each network 
> may of course be made up of different types of things.  For example, a 
> road_network includes streets, highways, off-ramps, parking lots, etc.  
> I may also have non-network topologies, such as parcels.
> 
> Anyway, why am I forced to store all these different topologies in 
> different schemas, all of which have their own edge/node/face tables?  
> Not saying that is a bad idea, but I could certainly see wanting to have 
> all my data in one schema.
> 
> I think the problem is that two things that are separate are being mixed 
> up.  The first is the concept of some sort of topology (road network, 
> electrical network, parcels, etc.).  Second is how/where to store these 
> networks.  These things should be separate.  In my view:
> 
> You have a topology (I've also seen this called a manifold).  A topology 
> is made up of geometries of different types of features (in this 
> implementation they are called layers).  These geometries are made up of 
> topology primitives (nodes, edges, faces).  Oracle also adds the idea 
> that topogeometry can be made up of other topogeometries.
> 
> I'm not sure where concept of schema comes in at all.  To draw a 
> parallel (not a very good one, but), its as if PostGIS forced me to 
> create a LineString schema to hold all my LineStrings data, a Polygon 
> schema to hold polygon data, etc. 
> 
> So I would do this differently.  I would define "topology" as collection 
> of features/layers that interact.  Then I would add separate 
> functionality that would "topologically" enable a schema.  This 
> functionality would add/remove the edge/node/face/etc. tables as 
> needed.  If I wished, I could topologically enable one schema, 2 
> schemas, 10 schemas, etc.
> 
> When I define a new topology (say a road network), I would define into 
> which topologically enabled schema I wanted it stored.  I think an 
> implementation like this would be a lot more flexible.
> 
> Hope you find these ideas useful,
> 
> Charlie
> 
> 
> 

> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel