The PostGIS Topology types and functions are used to manage topological objects such as faces, edges and nodes.
Sandro Santilli's presentation at PostGIS Day Paris 2011 conference gives a good synopsis of PostGIS Topology and where it is headed Topology with PostGIS 2.0 slide deck.
Vincent Picavet provides a good synopsis and overview of what is Topology, how is it used, and various FOSS4G tools that support it in PostGIS Topology PGConf EU 2012.
An example of a topologically based GIS database is the US Census Topologically Integrated Geographic Encoding and Referencing System (TIGER) database. If you want to experiment with PostGIS topology and need some data, check out Topology_Load_Tiger.
The PostGIS topology module has existed for a long time but was not always part of the official documentation. Extensive cleanup removed deprecated functions, fixed known usability issues, documented the features and functions, added new functionality, and improved SQL-MM compliance.
Details of this project can be found at PostGIS Topology Wiki
All functions and tables associated with this module are installed in a schema called topology.
Functions that are defined in SQL/MM standard are prefixed with ST_ and functions specific to PostGIS are not prefixed.
Topology support is built by default and can be disabled by specifying the --without-topology configure option at build time as described in Chapter 2, PostGIS Installation
The core primitives of any topology are stored in the edge_data, node, and face tables that live in the schema created by CreateTopology. Each row of edge_data represents an oriented edge: it records a directed curve from start_node to end_node together with the identifier of the face encountered on the left of that direction (left_face) and the face encountered on the right (right_face). The same geometric segment may therefore appear twice—once for each orientation—when it belongs to two faces.
The next_left_edge and next_right_edge columns complete this orientation information by encoding how to keep walking around a face. They store signed integers whose absolute value is the identifier of the next oriented edge and whose sign determines whether the stored orientation has to be followed as-is or reversed when traversing. Formally, the following rules hold for every edge e:
abs(next_left_edge) is the identifier of the edge reached by continuing around the face that lies to the left of e. If the value is positive the walk continues from the end node of e along the stored orientation of the referenced edge; if it is negative the referenced edge must be followed backwards so that the shared face remains on the walker’s left.
abs(next_right_edge) analogously follows the boundary of the face located on the right of e. A positive value means that the next edge is taken with its recorded orientation starting from the end node of e, whereas a negative value instructs to traverse the referenced edge in reverse, starting from its end node, so that the right-hand face is preserved.
A zero value indicates that the edge is dangling on the corresponding side (for example an isolated edge whose incident face is the universal face 0). The abs_next_left_edge and abs_next_right_edge columns exposed by the edge view are convenience projections of these absolute values.
This representation is a variant of a doubly connected edge list and is exploited by many topology routines. Functions such as GetRingEdges and ValidateTopology rely on it to reconstruct face boundaries and to diagnose inconsistencies—hence the “invalid next_left_edge” and “invalid next_right_edge” diagnostics reported during validation. Constructors like AddEdge initialise the next_* attributes with trivial self references, while editing routines including ST_AddEdgeModFace and ST_RemEdgeModFace update the links as edges are inserted or removed. Other bulk operations (for example Polygonize) may intentionally leave the fields unset, which is why the documentation flags their behaviour explicitly.
This section lists the PostgreSQL data types installed by PostGIS Topology. Note we describe the casting behavior of these which is very important especially when designing your own functions.
ValidateTopology.
This section lists the PostgreSQL domains installed by PostGIS Topology. Domains can be used like object types as return objects of functions or table columns. The distinction between a domain and a type is that a domain is an existing type with a check constraint bound to it.
This section lists the Topology functions for building new Topology schemas, validating topologies, and managing TopoGeometry Columns
table_name in schema schema_name and unregisters the columns from topology.layer table.
This section discusses management of database statistics during topology building.
Adding elements to a topology triggers many database queries for finding existing edges that will be split, adding nodes and updating edges that will node with the new linework. For this reason it is useful that statistics about the data in the topology tables are up-to-date.
PostGIS Topology population and editing functions do not automatically update the statistics because a updating stats after each and every change in a topology would be overkill, so it is the caller's duty to take care of that.
|
|
|
That the statistics updated by autovacuum will NOT be visible to transactions which started before autovacuum process completed, so long-running transactions will need to run ANALYZE themselves, to use updated statistics. |
This section covers the topology functions for creating new topologies.
This section covers topology functions for adding, moving, deleting, and splitting edges, faces, and nodes. All of these functions are defined by ISO SQL/MM.
alinestring to a topology connecting two existing isolated nodes anode and anothernode and returns the edge id of the new edge.
apoint geometry exists as a node an error is thrown. Returns description of move.
aface.
This section covers the functions for processing topologies in non-standard ways.
This section covers the topology functions for creating new topogeometries.
topoelementarray for a set of element_id, type arrays (topoelements).
This section covers the topology functions for editing existing topogeometries.
topoelementarray (an array of topoelements) containing the topological elements and type of the given TopoGeometry (primitive elements).
topoelement objects containing the topological element_id,element_type of the given TopoGeometry (primitive elements).
This section lists the Topology functions used to check relationships between topogeometries and topology primitives
Once you have created topologies, and maybe associated topological layers, you might want to export them into a file-based format for backup or transfer into another database.
Using the standard dump/restore tools of PostgreSQL is problematic because topologies are composed by a set of tables (4 for primitives, an arbitrary number for layers) and records in metadata tables (topology.topology and topology.layer). Additionally, topology identifiers are not univoque across databases so that parameter of your topology will need to be changes upon restoring it.
In order to simplify export/restore of topologies a pair of
executables are provided: pgtopo_export
and pgtopo_import. Example usage:
pgtopo_export dev_db topo1 | pgtopo_import topo1 | psql staging_db
The pgtopo_export script takes the name of a
database and a topology and outputs a dump file which can be used
to import the topology (and associated layers) into a new database.
By default pgtopo_export writes the
dump file to the standard output so that it can be piped to
pgtopo_import or redirected to a file
(refusing to write to terminal). You can optionally specify
an output filename with the -f commandline switch.
By default pgtopo_export includes a dump
of all layers defined against the given topology. This may be more
data than you need, or may be non-working (in case your layer tables
have complex dependencies) in which case you can request skipping the
layers with the --skip-layers switch and deal with those
separately.
Invoking pgtopo_export with the
--help (or -h for short) switch
will always print short usage string.
The dump file format is a compressed tar archive of a
pgtopo_export directory containing
at least a pgtopo_dump_version file with
format version info. As of version 1 the directory
contains tab-delimited CSV files with data of the topology
primitive tables (node, edge_data, face, relation), the
topology and layer records associated with it and
(unless --skip-layers is given) a custom-format
PostgreSQL dump of tables reported as being layers of the given
topology.
The pgtopo_import script takes a
pgtopo_export format topology dump and a
name to give to the topology to be created and outputs
an SQL script reconstructing the topology and associated
layers.
The generated SQL file will contain statements that create a topology with the given name, load primitive data in it, restores and registers all topology layers by properly linking all TopoGeometry values to their correct topology.
By default pgtopo_import reads the dump
from the standard input so that it can be used in conjunction
with pgtopo_export in a pipeline.
You can optionally specify an input filename with the
-f commandline switch.
By default pgtopo_import includes in the output
SQL file the code to restore all layers found in the dump.
This may be unwanted or non-working in case your target database already
have tables with the same name as the ones in the dump. In that case
you can request skipping the layers with the --skip-layers
switch and deal with those separately (or later).
SQL to only load and link layers to a named topology can be generated
using the --only-layers switch. This can be useful to load
layers AFTER resolving the naming conflicts or to link layers to a
different topology (say a spatially-simplified version of the starting
topology).
If the target topology already exists and you want it dropped upfront
you can pass the --drop-topology switch (since PostGIS-3.6.0).