Quelle est la différence entre la couverture, les fichiers de formes et les géodatabases dans ArcGIS?

Je m'interrogeais sur la différence de méthodologie de stockage de données spatiales utilisée par Coverages, Shapefiles et Geodatabases dans ArcGIS. La couverture était le format initial, suivi des fichiers de forme et maintenant des géodatabases. Qu'est-ce qui s'est amélioré dans ces nouveaux formats de fichiers de formes et de géodatabases?

Ce serait bien si quelqu'un pouvait l'expliquer avec des exemples.

C'est une si grande question. Les couvertures, les fichiers de formes et les géodatabases sont des magasins de données géospatiales fondamentalement différents du point de vue de la mise en œuvre et du point de vue philosophique. Je vais essayer de résumer sans aller trop loin.

1. Couverture:

Les couvertures sont des structures de données géospatiales intéressantes . Ils se concentrent sur le stockage de la topologie. Vous verrez donc que l'accent est mis d'abord sur le stockage des éléments géométriques, c'est-à-dire les nœuds, les arêtes qui composent toutes les géométries. Vous verrez alors un ensemble distinct de tables qui associent ces géométries aux attributs (et donc elles "deviennent" des entités).

Une couverture "propre" garantit certaines règles, par exemple, qu'il y a des nœuds à chaque intersection de nœuds, vous n'aurez pas deux nœuds (ou plus) l'un sur l'autre (ou même dans une distance de tolérance floue), qu'il n'y en a pas deux bords l'un sur l'autre, etc. Ils ont également un sens de direction (de-> à) et peuvent faire la distinction entre ce qui est à gauche et à droite.

Les couvertures fonctionnent très bien pour les modifications qui nécessitent une connaissance des relations topologiques (imaginez la modification d'une limite de parcelle). De plus, les couvertures se compressent très bien car elles suppriment la redondance géométrique par conception. En fait, vous verrez que de nos jours, les formats modernes comme TopoJSON ont commencé à utiliser les mêmes techniques que nous avons apprises des couvertures il y a plusieurs décennies.

Les couvertures peuvent être un peu plus compliquées à utiliser lorsque vous traitez des données 3D (par exemple, modéliser un pont qui a un côté supérieur et un côté inférieur juste en dessous) parce que les algorithmes que nous avons utilisés pour les traiter étaient intrinsèquement destinés pour les mathématiques de graphes planaires 2D .

Alors pourquoi nous en sommes-nous éloignés? Cela prendrait une réponse plus longue, mais peut-être devrions-nous expliquer un peu plus ce qui a rendu les Shapefiles ESRI populaires en premier.

2. Shapefiles ESRI:

Vint le Shapefile. Probablement la caractéristique la plus importante qu'elle avait était qu'il s'agissait / est une spécification ouverte qui était (comparativement) simple à mettre en œuvre. Les attributs exploitaient les fichiers DBF , il y avait donc déjà de nombreuses bibliothèques qui implémentaient une grande partie de la spécification. Il n'y avait pas de concept de "propre", ce qui signifiait que chaque géométrie individuelle n'avait qu'à se soucier de se représenter elle-même sans prendre en considération les géométries qui les entouraient ou qu'elles se recoupaient. Cela signifiait que nous n'avions pas à faire de calculs compliqués pour nous assurer qu'un fichier de formes était correct (contrairement à la contrepartie de couverture).

Vous avez plusieurs géométries qui se croisent? Bien sûr, pourquoi pas. Deux points l'un sur l'autre? Soit mon invité.

Parfois, le (sans doute) «meilleur» format n'est pas celui qui gagne, mais celui qui est adopté. Si un format est facile à mettre en œuvre, il a de meilleures chances d'être adopté qu'un format compliqué. C'était le Shapefile.

Tout d'un coup, plusieurs bibliothèques (open source et propriétaires) et des fournisseurs de logiciels l'ont pris en charge. Donc tout était super.

La question évidente est alors - pourquoi les géodatabases?

3. Géodatabases:

Je pense que les géodatabases sont l'un des magasins de données géospatiales les plus mal compris. Les gens les considèrent généralement comme «un format géospatial». Il y a quelques années, quelqu'un a demandé "Que sont les géodatabases ESRI?" . Au lieu de répéter ma réponse, je vous invite à le lire en premier. J'attendrai :)

Maintenant que vous avez lu cette réponse et que vous savez ce qu'est une géodatabase, je peux développer un peu plus cette réponse. À l'époque, il y avait beaucoup de recherches pour optimiser SQL et écrire des optimiseurs de requêtes qui exploitaient les index, les magasins de colonnes, etc. (il y en a toujours). En créant la géodatabase au-dessus d'un magasin de données SQL, nous pouvons tirer parti de toutes ces recherches gratuitement. Nous devons seulement nous concentrer sur les concepts géospatiaux, et à mesure que les magasins de données SQL s'améliorent, la géodatabase s'améliore aussi, gratuitement . Pas une mauvaise proposition hein?

De nos jours, il existe plusieurs spécifications pour les données géospatiales qui sortent. Le jury est toujours là sur ce qui va remplacer ces technologies (le cas échéant). Néanmoins, si vous êtes intéressé par ce sujet, je vous recommande de lire la réponse à une question posée ici dans GIS.SE il y a quelques années: "Y a-t-il des tentatives de remplacement du fichier de forme"

J'espère que ça aide!

La plupart des informations se trouvent dans l'aide d'Esri et dans certaines recherches, je viens donc de compiler quelques bonnes lectures.

Comment les couvertures sont-elles stockées? Puisqu'il s'agit d'un format propriétaire, vous ne trouverez aucune spécification technique sur la façon dont les algorithmes sont mis en œuvre (à moins que @Vince ne fasse la lumière).

Les fichiers de formes sont venus plus tard et ont été mis en œuvre en tant que norme offrant un certain niveau d'interopérabilité. La description technique du fichier ESRI Shapefile contient une description complète.

Les géodatabases ont été introduites ultérieurement. Les premières géodatabases personnelles sont arrivées (MS Access), puis les géodatabases fichier (format crypté binaire) et les géodatabases d'entreprise (ou ArcSDE) qui ont profité des technologies ArcSDE et SGBD. Vous pouvez en savoir plus sur les géodatabases ici: Types de géodatabases et L'architecture d'une géodatabase .

Une bonne lecture sur GIS.SE: Que ce soit pour utiliser la géodatabase fichier (* .gdb), la géodatabase personnelle (* .mdb) ou les fichiers de formes?

Concernant les performances, de nombreux benchmarks ont été réalisés et les géodatabases fichier se révèlent être les plus rapides en termes de lecture / écriture d'informations. Les géodatabases personnelles et les fichiers de formes sont de loin plus lents et la seule raison de les utiliser est de prendre en charge des systèmes plus anciens qui ont été construits avec une logique métier MS Access ou une lecture / conversion de fichiers de formes à l'esprit.

La géodatabase basée sur ArcSDE fonctionne souvent presque aussi bien que les géodatabases fichier lorsque le SGBD est réglé, mais tout dépend du type de données stockées, des réseaux et du matériel. Pour plus d'informations sur les benchmarks, reportez-vous aux ressources sur les stratégies de conception de systèmes Esri (et ici ).

La principale différence entre ces formats est la façon dont les entités sont liées aux géométries. À l'époque des couvertures, le langage de codage était FORTRAN, ce qui signifiait des tailles de tampon fixes dans les blocs COMMUNS. Le plus restrictif d'entre eux était 500 sommets par ligne primitive ("arc"). Cette restriction a introduit le concept de "pseudo-nœuds" (endroits où les arcs se joignent à un seul autre arc) et a compliqué de nombreuses autres opérations d'accès aux données.

Le modèle de couverture utilise une "liste d'arc de polygone" (PAL) pour décrire les polygones, ce qui nécessite un algorithme d'ombrage de polygone pour lire un fichier pour obtenir la liste des arcs, puis lire les arcs eux-mêmes pour obtenir le nombre de sommets, puis allouer suffisamment de RAM pour stockez tous les sommets, puis revenez en arrière pour lire à nouveau les arcs, cette fois en copiant les sommets en avant ou en arrière pour assembler un polygone complet. Ce n'est qu'après deux visites dans le fichier ARC que le polygone a pu être décrit de manière adéquate, puis il faudrait accéder à plusieurs des mêmes arcs (dans une direction opposée) pour ombrer les voisins du polygone.

Par comparaison, le fichier de formes et les différents formats de géodatabase stockent la géométrie complète en tant qu'objet unique (avec divers détails d'implémentation sur la façon dont l'objet est physiquement implémenté). Cela présente des inconvénients lorsque vous essayez de modifier des limites partagées, mais cette opération est beaucoup moins fréquente que l'ombrage de polygone.

Le modèle de stockage "forme entière" est la principale différence entre le format de couverture et les nouveaux, et cette différence est si fondamentale qu'il est difficile de voir une réelle différence entre le fichier de formes et les différents formats de géodatabase. En fait, le format de fichier de formes a été utilisé pour accéder aux géométries FGDB via l'API FGDB, même si FGDB n'utilise pas ce format exact, simplement parce qu'il était plus simple que d'introduire une nouvelle disposition de sommet.

Une autre différence entre les formats est qu'une géodatabase peut modéliser les relations entre les classes d' entités . Comme l'a noté Ragi,

Les couvertures fonctionnent très bien pour les modifications qui nécessitent une connaissance des relations topologiques (imaginez la modification d'une limite de parcelle).

Mais cette prise de conscience n'existe que dans une seule couverture - si vous souhaitez modéliser les relations entre 2 ou plusieurs couvertures, il est de votre responsabilité d'écrire le code qui vérifie les relations topologiques "illégales".

Par exemple, si les polygones de parcelles ne peuvent pas avoir de lacunes et que les limites des parcelles doivent s'aligner exactement avec les routes, avec les couvertures ou les fichiers de formes, c'est à vous de vérifier que c'est le cas et de corriger manuellement les erreurs lorsque ces règles ne sont pas respectées.

Une géodatabase peut éventuellement prendre en charge un objet Topologie , ce qui vous permet de définir les règles topologiques autorisées pour vos données. Il est important de noter que ces règles peuvent se produire à l' intérieur et entre les classes d'entités dans votre géodatabase.

Les outils de modification de la topologie dans ArcMap vous aident à trouver les violations topologiques et, dans certains cas, à les corriger automatiquement .

Avant l'introduction de la topologie de géodatabase («le bon vieux temps»), il était courant d'écrire des scripts AML longs et compliqués pour détecter les violations topologiques, puis d'éditer manuellement les couvertures dans ArcEdit (pas tellement amusant).