Les types et fonctions topologiques de PostGIS sont utilisés pour gérer les objets topologiques tels que les faces, les arêtes et les des noeuds.
La présentation de Sandro Santilli à la conférence PostGIS Day Paris 2011 donne un bon aperçu de PostGIS Topology et de son évolution Topology with PostGIS 2.0 slide deck.
Vincent Picavet fournit un bon résumé et une vue d'ensemble de ce qu'est la topologie, comment elle est utilisée, et divers outils FOSS4G qui la supportent dans PostGIS Topology PGConf EU 2012.
Un exemple de base de données SIG topologique est la base de données US Census Topologically Integrated Geographic Encoding and Referencing System (TIGER). Si vous souhaitez expérimenter la topologie PostGIS et avez besoin de quelques données, consultez 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.
Les détails sur ce projet peuvent être trouvés à PostGIS Topology Wiki
Toutes les fonctions et toutes les tables associées à ce module sont installées dans un schéma appelé topology.
Les fonctions qui sont définies dans le standard SQL/MM sont préfixées par ST_ et les fonctions spécifiques à PostGIS ne sont pas préfixées.
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, Installation de PostGIS
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.
Cette section liste les types de données de PostgreSQL installés par "PostGIS Topology". Notez que nous décrivons leurs comportements de transtypage, ce qui est très important en particulièrement lorsque l'on définit ses propres fonctions.
ValidateTopology.
Cette section énumère les domaines PostgreSQL installés par PostGIS Topology. Les domaines peuvent être utilisés comme des types d'objets, en tant qu'objets de retour de fonctions ou de colonnes de tables. La distinction entre un domaine et un type est qu'un domaine est un type existant avec une contrainte de vérification liée à lui.
Cette section énumère les fonctions topologiques permettant de créer de nouveaux schémas topologiques, de valider les topologies et de gérer les colonnes TopoGeometry
table_name dans le schéma schema_name et désenregistre les colonnes de la table topology.layer.
Cette section traite de la gestion des statistiques de la base de données pendant la construction de la topologie.
L'ajout d'éléments à une topologie déclenche de nombreuses requêtes dans la base de données pour trouver les arêtes existantes qui seront divisées, ajouter des nœuds et mettre à jour les arêtes qui formeront un nœud avec le nouveau réseau de lignes. C'est pourquoi il est utile que les statistiques relatives aux données contenues dans les tables de topologie soient à jour.
Les fonctions d'insertion et d'édition de topologie de PostGIS ne mettent pas automatiquement à jour les statistiques, car une mise à jour des statistiques après chaque changement dans une topologie serait exagérée, et c'est donc à l'appelant de s'en charger.
|
|
|
Les statistiques mises à jour par autovacuum ne seront PAS visibles pour les transactions qui ont démarré avant la fin du processus d'autovacuum, de sorte que les transactions de longue durée devront exécuter ANALYZE elles-mêmes, pour utiliser les statistiques mises à jour. |
Cette section couvre les fonctions de topologie permettant de créer de nouvelles topologies.
Cette section traite des fonctions topologiques permettant d'ajouter, de déplacer, de supprimer et de diviser des arêtes, des faces et des nœuds. Toutes ces fonctions sont définies par ISO SQL/MM.
alinestring à une topologie reliant deux nœuds isolés existants anode et anothernode et renvoie l'identifiant de l'arête de la nouvelle arête.
apoint existe en tant que noeud, une erreur est générée. Retourne la description du déplacement.
aface.
Cette section couvre les fonctions permettant de traiter les topologies de manière non standard.
Cette section couvre les fonctions de topologie permettant de créer de nouvelles topogéométries.
topoelementarray pour un ensemble de tableaux de type, element_id (topoelements).
Cette section couvre les fonctions de topologie permettant d'éditer les topogeometries existantes.
topoelementarray (un tableau de topoelements) contenant les éléments topologiques et le type de la TopoGeometry donnée (éléments primitifs).
topoelement contenant les éléments topologiques element_id,element_type de la TopoGeometry donnée (éléments primitifs).
Cette section énumère les fonctions de topologie utilisées pour vérifier les relations entre les topogeometries et les primitives topologiques
Une fois que vous avez créé des topologies, et éventuellement des couches topologiques associées, vous pouvez les exporter dans un format de fichier pour les sauvegarder ou les transférer dans une autre base de données.
L'utilisation des outils standards de dump/restauration de PostgreSQL est problématique car les topologies sont composées d'un ensemble de tables (4 pour les primitives, un nombre arbitraire pour les couches) et d'enregistrements dans des tables de métadonnées (topology.topology et topology.layer). De plus, les identifiants de topologie ne sont pas univoques d'une base de données à l'autre, de sorte que les paramètres de votre topologie devront être modifiés lors de sa restauration.
Afin de simplifier l'exportation/la restauration des topologies, une paire d'exécutables est fournie : pgtopo_export et pgtopo_import. Exemple d'utilisation :
pgtopo_export dev_db topo1 | pgtopo_import topo1 | psql staging_db
Le script pgtopo_export prend le nom d'une base de données et d'une topologie et produit un fichier dump qui peut être utilisé pour importer la topologie (et les couches associées) dans une nouvelle base de données.
Par défaut, pgtopo_export écrit le fichier dump sur la sortie standard afin qu'il puisse être acheminé vers pgtopo_import ou redirigé vers un fichier (refusant d'écrire dans le terminal). Vous pouvez optionnellement spécifier un nom de fichier de sortie en utilisant l'argument -f dans la ligne de commandes.
Par défaut pgtopo_export inclut un dump de toutes les couches définies par rapport à la topologie donnée. Cela peut être plus de données que vous n'en avez besoin, ou peut ne pas fonctionner (dans le cas où vos tables de couches ont des dépendances complexes), auquel cas vous pouvez demander à ignorer les couches avec l'argument --skip-layers et les traiter séparément.
En utilisant pgtopo_export avec l'argument --help (ou -h en abrégé) affichera toujours une courte chaîne de caractères sur l'utilisation.
Le format du fichier dump est une archive tar compressée d'un répertoire pgtopo_export contenant au moins un fichier pgtopo_dump_version avec des informations sur la version du format. A partir de la version 1, le répertoire contient des fichiers CSV délimités par des tabulations avec les données des tables primitives de topologie (node, edge_data, face, relation), les enregistrements de topologie et de couche associés et (sauf si --skip-layers est donné) un dump PostgreSQL au format personnalisé des tables signalées comme étant des couches de la topologie donnée.
Le script pgtopo_import prend un dump topologique au format pgtopo_export et un nom à donner à la topologie à créer et produit un script SQL reconstruisant la topologie et les couches associées.
Le fichier SQL généré contiendra des instructions qui créent une topologie avec le nom donné, chargent les données primitives, restaurent et enregistrent toutes les couches de la topologie en liant correctement toutes les valeurs TopoGeometry à leur topologie correcte.
Par défaut, pgtopo_import lit le dump depuis l'entrée standard afin qu'il puisse être utilisé en conjonction avec pgtopo_export dans une chaîne de traitement. Vous pouvez optionnellement spécifier un nom de fichier d'entrée avec l'argument -f en ligne de commande.
Par défaut, pgtopo_import inclut dans le fichier SQL de sortie le code permettant de restaurer toutes les couches trouvées dans le dump.
Ceci peut être indésirable ou ne pas fonctionner si votre base de données cible a déjà des tables avec le même nom que celles dans le dump. Dans ce cas, vous pouvez demander à ignorer les couches avec l'argument --skip-layers et les traiter séparément (ou plus tard).
SQL pour charger et lier uniquement les couches à une topologie nommée peut être généré en utilisant l'argument --only-layers. Cela peut être utile pour charger des couches APRÈS avoir résolu les conflits de noms ou pour lier des couches à une topologie différente (par exemple une version spatialement simplifiée de la topologie de départ).
If the target topology already exists and you want it dropped upfront you can pass the --drop-topology switch (since PostGIS-3.6.0).