[postgis-devel] Some thoughts on Topology

[Charles F. I. Savage]

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2781 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20051028/2adffdcb/attachment.bin>