=Introduction
This module contains support for topological geometry modelling.
Functions exist to satisfy the ISO/SQLMM topology-geometry model
and more are provided to add an additional abstraction level for
topological features and layers, both simple and hierarchical.
You can see an ER diagram of the full conceptual model in the ER dir.
You need xfig (http://epb.lbl.gov/xfig/).
All routines, types and other management objects are stored in the
"topology" SCHEMA.
Comments welcome --strk(2012-03-13);
=Requirements
Many ISO/SQLMM functions use GEOS-3.3.0+ signatures.
The script is still buildable with previous GEOS versions
but you'll need 3.3.0+ at runtime for most uses.
=Building
To build the topology support:
$ make
=Testing
To run regression tests:
$ make check
=Install, upgrade, uninstall
To enable topology support:
$ psql -f topology.sql <your_postgis_enabled_db>
It will create a 'topology' schema in <your_postgis_enabled_db>
hosting all the topology functions. To be run with db-owner perms.
Remember to grant execute to users.
To uninstall:
$ psql -c 'drop schema topology cascade'
To upgrade between minor releases:
$ psql -f topology_upgrade_<version>_minor.sql <your_postgis_enabled_db>
Major releases upgrades should follow the "HARD UPGRADE" procedure
described in main postgis manual.
=Usage
Topology data are stored in named SCHEMAs, where the topology
name is the name of the SCHEMA containing its data.
A catalogue of avalable topologies is kept under the
"topology"."topology" table.
==Creating a topology
To create a topology:
SELECT topology.CreateTopology(<name>, [srid], [tolerance]);
Example:
SELECT topology.CreateTopology('test_schema', 4326 , 0.0001);
or
-- unknown srid, 0 tolerance
SELECT topology.CreateTopology('test_schema');
NOTE: the new schema ('test_schema' in example) will be create
so it must not exist before.
==Destroying a topology
To destroy a topology:
SELECT topology.DropTopology(<name>);
==Loading topology data
To load topology data in a topology you can use INSERT
statements filling up the Edge, Node and Face relations
under you topology schema:
* Edge
* edge_id integer PRIMARY KEY
* start_node integer REFERENCES Node.node_id)
* end_node integer REFERENCES Node.node_id)
* next_left_edge integer REFERENCES abs(Edge.edge_id)
* next_right_edge integer REFERENCES abs(Edge.edge_id)
* left_face integer REFERENCES Face.face_id
* right_face integer REFERENCES Face.face_id
* geom geometry ( a linestring )
* Node
* node_id integer PRIMARY KEY
* containing_face integer REFERENCES Face.face_id
* geom geometry ( a point )
* Face
* face_id integer PRIMARY KEY
* mbr box2d ( can be NULL )
The next_*_edge of an edge is the edge you encounter next while going
around the specified face (right or left) in counterclockwise order
(so that the face is on your left). Note that due to this definition
the edge being considered is traversed in reverse order when traversing
its "right" face. The values are signed to indicate wheter the next edge
will be traversed in its original or reversed orientation.
More details on semantic are contained in the SQL/MM specification, which
this implementation follows as for these views structure.
==Validating topology data
To verify validity of a topology:
SELECT * FROM topology.ValidateTopology(name);
==Defining TopoGeometry objects
Currently, TopoGeometry objects can only be defined by specifying their
component topology elements. We do support both basic TopoGeometry
and hierarchical TopoGeometry. Basic TopoGeometry objects are those
composed by base topolocal elements (faces, edges, nodes). Hierarchical
TopoGeometry objects are composed by other TopoGeometry objects.
Each TopoGeometry object belongs to a specific Layer of a specific
Topology. Before creating a TopoGeometry object you need to create
its Layer in the Topology. A Topology Layer is an association of
a feature-table with the topology. It also contain type and hierarchy
information. We create a layer using the AddTopoGeometryColumn() function:
topology.AddTopoGeometryColumn(topology_name,
schema_name, table_name, column_name, feature_type,
[child_layer])
The function will both add the requested column to the table and add
a record to the topology.layer table with all the given info.
If you don't specify [child_layer] (or set it to NULL) this layer
would contain Basic TopoGeometries (composed by primitive topology
elements). Otherwise this layer will contain hierarchical TopoGeometries
(composed by TopoGeometries from the child_layer).
Once the layer is created (it's id is returned by the AddTopoGeometryColumn
function) you're ready to construct TopoGeometry objects in it:
topology.CreateTopoGeom(
topology_name,
feature_type, -- 1:[multi]point, 2:[multi]line,
-- 3:[multi]poly, 4:collection
layer_id, -- as returned by AddTopoGeometryColumn
TopoElementArray);
The TopoElementArray type is a bidimensional array of integers.
Value semantics depend on the type of the layer associated with
the TopoGeometry object. For Basic TopoGeometry objects this would
be:
{{element_type, element_id}, ...}
For Hierarchical TopoGeometry objects this would be:
{{child_layer_id, topogeometry_id}, ...}
==Converting Geometry to TopoGeometry while populating the topology
You can import a Geometry into an existing topology and at the same
time get its topological definition (its TopoGeometry equivalent)
using the toTopoGeom function:
topology.toTopoGeom(
geometry, -- the simple geometry
topology_name,
layer_id -- as returned by AddTopoGeometryColumn
);
==Getting simple Geometry values from TopoGeometry objects
TopoGeometry to Geometry casting is implicit, so any function accepting
a Geometry would transparently also accept a TopoGeometry. Some functions
may be optimized for TopoGeometry.
=Issues
==Topology tolerance
GEOS (and JTS) often fail due to input precision.
The CreateTopogeo() function currently accept a precision
specification, we might use this to enforce a precision
to the topology element geometries, by mean of SnapToGrid
calls, or alternatively, force use of a specific PrecisionModel
when using GEOS function. The former seems cleaner, but would
require a trigger to run on all inserts, even when the geometry
being input has already been snapped by caller.
==ST_GetFaceGeometry() implementation
The ST_GetFaceGeometry() function is currently implemented
as a call to polygonize() receiving all edges with the
given Face on the left or right side. This reduces the number
of SQL queries to 1, but makes it hard to detect any
inconsistency in the underlying topology.
Also, the polygonize() function does not use *any* of the
metadata informations in the Edge table, so replacing it
with a more topology-aware function could speed it up.
==ValidateTopology() performance
The ValidateTopology() function, as for SQL/MM specification
uses ST_GetFaceGeometry() to check for Within() and Overlap()
conditions. This is an expensive task, and might be replaced
by topology-aware replacement of the two predicates. The
Face geometries might also be cached, but that might still
be slower then overloading the predicates.
==Topology table constraints
In addition to the constraints defined in SQL/MM specification,
this implementation adds constraints to enforce Node and Edge
geometry types to be 'POINT' and 'LINESTRING' respectively.
