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.
Le module sur la topologie de PostGIS existe dans les versions précédentes de PostGIS mais n'a jamais fait partie de la documentation officielle de PostGIS. Dans la version 2.0.0 de PostGIS, un grand nettoyage est en cours pour en éliminer l'utilisation de toutes les fonctions obsolètes, résoudre les problèmes d'utilisabilité connus, mieux documenter les caractéristiques et les fonctions, ajouter de nouvelles fonctions, et l'améliorer afin de mieux se conformer aux normes SQL-MM.
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.
Le support topologique est compilé par défaut à partir de PostGIS 2.0, et peut être désactivé en spécifiant l'option de configuration --without-topology au moment de la construction, comme décrit dans Chapter 2, Installation de PostGIS
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).