Principes de base d'une topologie

Cette rubrique s'applique uniquement à ArcEditor et ArcInfo.

La topologie représente un ensemble de règles qui, associées à un jeu d'outils et de techniques de mise à jour, permet à la géodatabase de modéliser plus précisément des relations géométriques. ArcGIS met en œuvre la topologie par l'intermédiaire d'un ensemble de règles qui définissent la manière dont les entités peuvent partager un espace géographique et une série d'outils de modification fonctionnant avec les entités partageant une géométrie de manière intégrée. Une topologie est stockée dans une géodatabase comme une ou plusieurs relations qui définissent la manière dont les entités d'une ou de plusieurs classes d'entités partagent la géométrie. Les entités participant à une topologie sont toujours des classes d'entités simples. Plutôt que de mettre à jour la définition de la classe d'entités, une topologie sert à décrire la façon dont les entités sont reliées spatialement.

Pourquoi utiliser une topologie ?

La topologie a longtemps été une exigence fondamentale SIG pour la gestion et l'intégrité des données. En général, un modèle de données topologique gère les relations spatiales en représentant les objets spatiaux (entités ponctuelles, linéaires et surfaciques) comme un graphique sous-jacent de primitives topologiques (nœuds, faces et limites). Ces primitives, combinées avec leurs relations mutuelles et leurs relations avec les entités dont elles représentent les limites, sont définies en représentant les géométries des entités dans un graphe planaire d'éléments topologiques.

La topologie est utilisée principalement pour garantir la qualité des données des relations spatiales et faciliter leur compilation. La topologie est également utilisée pour l'analyse des relations spatiales dans de nombreuses situations, telles que la fusion des limites entre polygones adjacents ayant des valeurs attributaires identiques ou le déplacement le long d'un réseau des éléments dans un graphe topologique.

La topologie permet également de modéliser la manière dont la géométrie de plusieurs classes d'entités peut être intégrée. Ceci est parfois appelé intégration verticale de classes d'entités.

Manières dont les entités partagent une géométrie dans une topologie

Des entités peuvent partager une géométrie dans une topologie. Voici quelques exemples concernant des entités adjacentes :

• Les entités surfaciques peuvent partager les limites (topologie de polygone).
• Les entités linéaires peuvent partager des extrémités (topologie limite-nœud).

En outre, une géométrie partagée peut être gérée entre des classes d'entités à l'aide d'une topologie de géodatabase. Par exemple :

• Les entités linéaires peuvent partager des segments avec d'autres entités linéaires. Par exemple, des parcelles peuvent être incluses dans des îlots :
• Les entités surfaciques peuvent rencontrer d'autres entités surfaciques.
• Les entités linéaires peuvent partager des sommets d'extrémité avec d'autres points (topologie de nœud).
• Les entités ponctuelles peuvent rencontrer des entités linéaires (événements ponctuels).

Remarque :

La gestion des parcelles repose généralement sur les classes d'entités simples et la topologie de géodatabase, afin que l'ensemble de classes d'entités permettant de modéliser des parcelles, les limites, les points d'angle et les points de contrôle obéissent aux règles de coïncidence requises. Les parcelles peuvent également être gérées à l'aide d'un atelier parcellaire, qui fournit automatiquement ces couches. L'atelier assure la gestion de sa topologie interne, sans besoin de gérer une topologie de géodatabase ou d'effectuer des modifications topologiques pour l'ensemble de couches utilisé par les parcelles.

Les parcelles modélisées en tant qu'entités simples et les parcelles dans un atelier présentent une différence essentielle : les limites des parcelles d'atelier ("lignes" dans un atelier) ne sont pas partagées. La limite de chaque parcelle comporte un ensemble complet de lignes et les lignes d'atelier des parcelles adjacentes sont superposées et coïncidentes.

Les ateliers parcellaires peuvent toujours participer à la topologie de géodatabase ; lorsque les lignes de limite superposées ont des géométries différentes, les lignes sont décomposées et le graphe topologique est créé de manière habituelle.

Deux vues : entités et éléments topologiques

L'illustration suivante montre comment une couche de polygones peut être décrite et utilisée :

• Comme des ensembles d'entités géographiques (points, lignes et polygones)
• En tant que graphe d'éléments topologiques (nœuds, limites, faces et leurs relations)

Ceci signifie qu'il existe deux solutions pour utiliser des entités, une solution dans laquelle les entités sont définies par leurs coordonnées et un autre dans laquelle les entités sont représentées comme un graphe ordonné de leurs éléments topologiques.

Evolution de la topologie de géodatabase à partir de couvertures ArcInfo

Remarque :

Vous n'avez pas besoin de lire cette longue rubrique pour mettre en œuvre des topologies de géodatabase. Toutefois, vous pouvez consacrer un peu de temps à sa lecture si vous vous intéressez à l'évolution historique des topologies et aux motivations qui sous-tendent le mode de gestion d'une topologie dans la géodatabase.

Genèse des concepts arc-nœud et géorelationnel

Les utilisateurs de couverture ArcInfo ont une longue histoire derrière eux et savent apprécier le rôle que la topologie joue dans la gestion de l'intégrité spatiale de leurs données.

Voici les éléments du modèle de données de couverture ArcInfo.

Dans une couverture, les limites et les points d'entité étaient stockés dans quelques fichiers principaux gérés par ArcInfo Workstation et appartenant à ce dernier. Le fichier ARC contenait la géométrie linéaire ou de limite de polygone sous la forme de limites topologiques connus sous le nom d'arcs. Le fichier LAB contenait des emplacements de points utilisés comme des points d'étiquette pour les polygones ou comme entités ponctuelles individuelles, par exemple pour une couche d'entités de puits. D'autres fichiers permettaient de définir et de gérer les relations topologiques entre chaque limite et polygone.

Par exemple, un fichier appelé fichier PAL, acronyme de Polygon-arc list (liste des arcs de polygone), répertoriait l'ordre et la direction des arcs de chaque polygone. Dans ArcInfo, la logique logicielle était utilisée pour assembler les coordonnées de chaque polygone pour des opérations d'affichage, d'analyse et de requête. La liste ordonnée de limite dans le fichier PAL permettait de rechercher et d'assembler les coordonnées de limite contenues dans le fichier ARC. Les polygones étaient assemblés au cours de l'exécution si nécessaire.

Le modèle de couverture offrait plusieurs avantages :

• Il utilisait une structure simple pour gérer la topologie.
• Il permettait aux limites d'être numérisés et stockés une seule fois et d'être partagés par beaucoup d'entités.
• Il pouvait représenter des polygones très volumineux (avec des milliers de coordonnées) parce que les polygones étaient en réalité définis comme un ensemble ordonné de limites (arcs).
• La structure de stockage de topologie de la couverture était intuitive. Ses fichiers topologiques physiques étaient compris aisément par les utilisateurs ArcInfo.

Remarque :

Un fait historique intéressant : "Arc", accolé au nom du gestionnaire de tables "Info" est à l'origine du nom de produit ArcInfo, puis de tous les produits Arc ultérieurs de la famille de produits ESRI (ArcView, ArcIMS, ArcGIS, etc.).

Les couvertures présentaient également des inconvénients :

• Certaines opérations étaient lentes parce que beaucoup d'entités devaient être assemblées à la volée lorsqu'elles devaient être utilisées. Cela incluait tous les polygones et toutes les entités multi-parties, par exemple, les régions (le terme de couverture pour les polygones multi-parties) et les itinéraires (le terme pour les entités linéaires multi-parties).
• Les entités topologiques (telles que les polygones, les régions et les itinéraires) n'étaient pas prêtes à l'emploi tant que la topologie de couverture n'était pas créée. Si des limites étaient mises à jour, la topologie devait être recréée. (Remarque : un traitement partiel était enfin utilisé, qui nécessitait uniquement la recréation des portions modifiées de la topologie de couverture.) En général, lorsque des mises à jour étaient effectuées sur un jeu de données topologiques, un algorithme d'analyse géométrique devait être exécuté pour récréer les relations topologiques indépendamment du modèle de stockage.
• Les couvertures ne pouvaient être modifiées que par un seul utilisateur à la fois. Pour garantir la synchronisation du graphe topologique avec les géométries des entités, un seul utilisateur pouvait mettre à jour une topologie à la fois. Les utilisateurs tuilaient leurs couvertures et géraient une base de données tuilée pour la mise à jour. Cela permettait aux différents utilisateurs de verrouiller et de modifier une tuile à la fois. Pour l'utilisation et le déploiement des données générales, les utilisateurs ajoutaient des copies de leurs tuiles dans une couche de données mosaïquées. En d'autres termes, les jeux de données tuilés qu'ils mettaient à jour n'étaient pas utilisés directement dans l'organisation. Ils devaient être convertis, ce qui impliquait un travail et du temps supplémentaires.

Fichier de formes et stockage de géométries simples

Au début des années 1980, les couvertures étaient considérées comme un progrès majeur par rapport aux systèmes plus anciens basés sur des polygones et lignes dans lesquels les polygones étaient contenus sous la forme de boucles complètes. Dans ces systèmes anciens, toutes les coordonnées pour une entité étaient stockées dans la géométrie de chaque entité. Avant l'arrivée des couvertures et d'ArcInfo, ces structures de polygone et de ligne simples étaient utilisées. Ces structures de données étaient simples, mais elles présentaient l'inconvénient d'entraîner des limites numérisées doubles. Autrement dit, deux copies des coordonnées des parties adjacentes de polygones avec des limites mitoyennes étaient contenues dans la géométrie de chaque polygone. L'inconvénient principal était que le logiciel SIG ne pouvait pas alors assurer l'intégrité des limites mitoyennes. En outre, les coûts de stockage étaient énormes et chaque octet de stockage était précieux. Au début des années 1980, un lecteur de disque de 300 Mo avait la taille d'une machine à laver et coûtait 30 000 $. Le stockage de plusieurs représentations de coordonnées représentait un coût important et les calculs prenaient trop de temps. Par conséquent, l'utilisation d'une topologie présentait de réels avantages.

Au milieu des années 1990, l'intérêt dans les structures géométriques simples s'est accru en raison de la diminution des coûts de l'espace disque et du matériel, et de l'augmentation de la vitesse de calcul. En même temps, les jeux de données SIG existants étaient disponibles plus aisément, et le travail des utilisateurs SIG évoluait. Les activités axées au départ principalement sur la compilation des données incluaient de plus en plus l'utilisation, l'analyse et le partage des données.

Les utilisateurs souhaitaient des performances plus rapides pour l'utilisation des données (par exemple, ne pas devoir consacrer du temps d'ordinateur pour dériver des géométries de polygone en cas de besoin, mais juste fournir les coordonnées d'entités de ces 1200 polygones aussi vite que possible). Le fait d'avoir la géométrie complète des entités disponible était plus efficace. Des milliers de systèmes d'information géographique étaient en cours d'utilisation, et les nombreux jeux de données étaient disponibles aisément.

Au même moment, ESRI développait et publiait son format de fichier de formes ESRI. Les fichiers de formes utilisaient un modèle de stockage très simple pour les coordonnées des entités. Chaque fichier de formes représentait une seule classe d'entités (ponctuelles, linéaires ou surfaciques) et utilisait un modèle de stockage simple pour les coordonnées des entités. Les fichiers de formes pouvaient être créés facilement à partir de couvertures ArcInfo et de nombreux autres systèmes d'information géographique. Les fichiers de formes ont été adoptés largement comme standard naturel et sont encore massivement utilisés et déployés à ce jour.

Quelques années plus tard, ArcSDE a innové avec un modèle de stockage simple similaire dans des tables de base de données relationnelles. Une table d'entités pouvait contenir une entité par ligne avec la géométrie dans l'une de ses colonnes avec d'autres colonnes d'attributs d'entité.

Un exemple de table d'entités de polygones d'état est illustrée ci-dessous. Chaque ligne représente un état. La colonne de forme (shape) contient la géométrie de polygone de chaque état.

Ce modèle d'entités simples est parfaitement adapté au moteur de traitement SQL. Par le biais de l'utilisation de bases de données relationnelles, les données SIG ont pu évoluer vers des tailles et des nombres d'utilisateurs inédits sans dégradation des performances. ESRI commençait à tirer parti des SGBDR pour la gestion de données SIG.

Les fichiers de formes sont devenus omniprésents et, grâce à ArcSDE, ce mécanisme d'entités simples est devenu le modèle fondamental du stockage d'entités dans les SGBDR. (Pour la prise en charge de l'interopérabilité, ESRI a été l'auteur principal de la spécification OGC et ISO relative aux entités simples.)

Le stockage d'entités simples présentait de nets avantages :

• La géométrie complète pour chaque entité était contenue dans un enregistrement. Aucun assemblage n'était requis.
• La structure de données (structure physique) était très simple, rapide et modulable.
• Il était facile pour les programmeurs d'écrire des interfaces.
• Cette méthode était interopérable. De nombreuses personnes ont écrit des convertisseurs simples pour transférer les données entre ces géométries simples et maints autres formats. Les fichiers de formes étaient largement appliqués en tant que format d'utilisation et d'échange des données.

Ils avaient comme inconvénient que la gestion de l'intégrité des données qui était fournie aisément par la topologie n'était pas aussi facile à mettre en œuvre pour les entités simples. Par conséquent, les utilisateurs appliquaient un modèle de données pour la mise à jour et la gestion (par exemple, des couvertures) et utilisaient un autre modèle pour le déploiement (par exemple, des fichiers de formes ou des couches ArcSDE).

Les utilisateurs ont commencé à utiliser cette approche hybride pour la mise à jour et le déploiement des données. Par exemple, les utilisateurs modifiaient leurs données en couvertures, en fichiers DAO ou en d'autres formats. Ensuite, ils convertissaient leurs données en fichiers de formes pour le déploiement et l'utilisation. Par conséquent, même si la structure d'entités simples constituait un format d'utilisation direct très pratique, elle ne prenait pas en charge la mise à jour topologique et la gestion des données de géométrie partagée. L'utilisation directe de bases de données reposait sur des structures simples, mais un autre format topologique était utilisé pour la mise à jour. Cela présentait des avantages pour le déploiement. Mais l'inconvénient était que les données devenaient obsolètes et devaient être actualisées. Cela fonctionnait mais il y avait un décalage pour la mise à jour des informations. Pour résumer, il manquait la topologie.

Ce dont les SIG avaient besoin et que le modèle de topologie de géodatabase met en œuvre actuellement est un mécanisme qui stocke des entités à l'aide de la géométrie d'entités simples, mais qui permet d'utiliser des topologies sur cette structure de données simple et ouverte. Cela signifie que les utilisateurs peuvent profiter des deux univers, un modèle de données transactionnelles permettant des requêtes topologiques, la mise à jour de géométries partagées, une modélisation de données sophistiquée et l'intégrité des données, mais également un mécanisme de stockage des données simple, extrêmement évolutif, basé sur une géométrie d'entités simple et ouverte.

Ce modèle de données d'utilisation directe est rapide, simple et efficace. Il peut également être mis à jour et géré directement par tout nombre d'utilisateurs à la fois.

Structure de topologie dans ArcGIS

En réalité, la topologie est considérée comme plus qu'une solution au problème du stockage des données. La solution complète inclut les éléments suivants :

• Un modèle de données complet (des objets, des règles d'intégrité, des outils de mise à jour et de validation, une topologie et un moteur de géométrie pouvant traiter des jeux de données de toute taille et complexité, et un jeu complet d'opérateurs topologiques, ainsi que des outils d'affichage cartographique et de requête)
• Un format de stockage ouvert utilisant un ensemble de types d'enregistrements pour les entités simples et une interface topologique pour interroger les entités simples, extraire des éléments topologiques et parcourir leurs relations spatiales (par exemple, rechercher des zones adjacentes et leur limite partagée et se déplacer le long de lignes connectées).
• La capacité de fournir les entités (points, lignes et polygones) ainsi que les éléments topologiques (nœuds, limites et faces) et leurs relations mutuelles
• Un mécanisme pouvant prendre en charge les éléments suivants :
  • Des jeux de données extrêmement volumineux avec des millions d'entités
  • La possibilité pour de nombreux éditeurs d'exécuter simultanément des opérations de mise à jour et de gestion
  • Des géométries d'entités prêtes à l'emploi et toujours disponibles
  • Une prise en charge pour l'intégrité et le comportement topologiques
  • Un système rapide et modulable pour beaucoup d'utilisateurs et d'éditeurs
  • Un système flexible et simple
  • Un système qui tire parti du moteur SQL et de l'infrastructure de transaction du SGBDR
  • Un système qui peut prendre en charge plusieurs éditeurs, des transactions longues, l'archivage historique et la réplication

Dans une topologie de géodatabase, le processus de validation identifie des coordonnées partagées entre des entités (à la fois dans la même classe d'entités et dans les différentes classes d'entités). Un algorithme d'agrégation est utilisé pour garantir que les coordonnées partagées ont le même emplacement. Ces coordonnées partagées sont stockées dans le cadre de la géométrie simple de chaque entité.

Cela permet une recherche très rapide et modulable d'éléments topologiques (nœuds, limites et faces). En outre, cela présente l'avantage de très bien fonctionner et de pouvoir évoluer avec le moteur SQL et l'infrastructure de transaction du SGBDR.

Pendant la mise à jour, au fur et à mesure que des entités sont ajoutées, celles-ci sont directement utilisables. Les zones mises à jour sur la carte (zones à valider) sont marquées et suivies pendant que des mises à jour sont effectuées sur chaque classe d'entités. A tout moment, les utilisateurs peuvent choisir d'analyser topologiquement et de valider les zones à valider pour générer une topologie propre. Seule la topologie des zones à valider doit être recréée, ce qui permet d'économiser du temps de traitement.

Il en résulte que les primitives topologiques (nœuds, limites, faces), ainsi que leurs relations mutuelles et leurs entités peuvent être découvertes et assemblées efficacement. Cela présente plusieurs avantages :

• Le stockage de géométries d'entités simples est utilisé pour les entités. Ce modèle de stockage est ouvert et efficace et peut évoluer pour accepter des tailles élevées et un grand nombre d'utilisateurs.
• Ce modèle de données d'entités simples est transactionnel et multi-utilisateurs. A l'inverse, les modèles de stockage topologiques plus anciens n'étaient pas modulables et avaient du mal à prendre en charge plusieurs transactions d'éditeur et de nombreux autres workflows de gestion de données SIG.
• Les topologies de géodatabase prennent en charge complètement toutes les transactions longues et les fonctions de versionnement de la géodatabase. Les topologies de géodatabase n'ont pas besoin d'être tuilées, et beaucoup d'utilisateurs peuvent modifier simultanément la base de données topologique, même leurs versions individuelles des mêmes entités si nécessaire.
• Les classes d'entités peuvent croître jusqu'à n'importe quelle taille (centaines de millions d'entités) avec des performances très élevées.
• Cette mise en œuvre de topologie est additive. Vous pouvez par exemple l'ajouter à une structure existante de classes d'entités reliées spatialement. L'autre solution consiste à redéfinir et convertir toutes vos classes d'entités existantes vers de nouvelles structures de données contenant les primitives topologiques.
• Vous n'avez besoin que d'un seul modèle de données pour la mise à jour de géométrie et l'utilisation des données.
• Cette solution est interopérable puisque tout le stockage des géométries des entités est conforme aux spécifications publiées par Open Geospatial Consortium et ISO en matière d'entités simples.
• La modélisation de données est plus naturelle parce qu'elle est basée sur des entités d'utilisateur (telles que des parcelles, des rues, des types de sol et des bassins versants) et non sur des primitives topologiques (telles que des nœuds, des limites et des faces). Les utilisateurs vont commencer à réfléchir sur les règles d'intégrité et le comportement de leurs entités réelles et non sur les règles d'intégrité des primitives topologiques. Par exemple, comment est-ce que les parcelles se comportent ? Cela permet une modélisation plus puissante pour tous les types d'entités géographiques. Cela va améliorer notre conception des rues, des types de sol, des unités de recensement, des bassins versants, des systèmes ferroviaires, de la géologie, des peuplements forestiers, des terrains, des entités physiques, etc.
• Les topologies de géodatabase fournissent les mêmes informations que les implémentations topologiques gérées. Vous stockez une courbe topologique et découvrez la géométrie des entités (comme les couvertures ArcInfo) ou vous stockez la géométrie des entités et découvrez les éléments et les relations topologiques (comme les géodatabases).

Dans les cas où les utilisateurs souhaitent stocker les primitives topologiques, il est facile de créer et de réinjecter des topologies et leurs relations dans des tables à différentes fins analytiques et d'interopérabilité (par exemple, des utilisateurs voulant réinjecter leurs entités dans un entrepôt Oracle Spatial stockant des tables de primitives topologiques).

A un niveau pragmatique, la mise en œuvre de la topologie d'ArcGIS fonctionne. Elle permet d'évoluer vers des géodatabases extrêmement volumineuses et des systèmes multi-utilisateurs sans perte de performances. Elle inclut des outils de validation et de mise à jour pour la création et la gestion des topologies dans les géodatabases. Elle comprend des outils de modélisation de données puissants et flexibles qui permettent aux utilisateurs d'assembler des systèmes pratiques fonctionnant sur des systèmes de fichiers, dans toute base de données relationnelles, et sur tout nombre de structures.