¿Cuál es la diferencia entre Cobertura, Shapefiles y Geodatabases en ArcGIS?

Me preguntaba sobre la diferencia en la metodología de almacenamiento de datos espaciales utilizada por Coberturas, Shapefiles y Geodatabases en ArcGIS. La cobertura fue el formato inicial, seguido de Shape Files y ahora Geodatabases. Entonces, ¿qué ha mejorado en estos nuevos formatos de Shapefiles y Geodatabases?

Sería genial si alguien pudiera explicarlo con ejemplos.

Esta es una gran pregunta. Coberturas, Shapefile y Geodatabases son almacenes de datos geoespaciales fundamentalmente diferentes desde el punto de vista de la implementación, así como desde el punto de vista filosófico. Trataré de resumir sin profundizar demasiado.

1. Coberturas:

Las coberturas son estructuras de datos geoespaciales interesantes . Se concentran en almacenar la topología. Entonces verá que el énfasis está en almacenar primero los elementos de geometría, es decir, los nodos, los bordes que componen todas las geometrías. Luego verá un conjunto separado de tablas que relacionan esas geometrías con los atributos (y, por lo tanto, se "convierten" en características).

Una cobertura "limpia" garantiza ciertas reglas, por ejemplo, que hay nodos en cada intersección de nodos, no tendrá dos (o más) nodos uno encima del otro (o incluso dentro de una distancia de tolerancia difusa), que no hay dos bordes uno encima del otro, etc. También tienen un sentido de dirección (de-> a) y pueden distinguir entre lo que está a su lado izquierdo y derecho.

Las coberturas funcionan muy bien para ediciones que requieren conocimiento de las relaciones topológicas (imagine editar un límite de parcela). Además, las coberturas se comprimen muy bien ya que eliminan la redundancia geométrica por diseño. De hecho, verá que hoy en día, los formatos modernos como TopoJSON comenzaron a usar las mismas técnicas que aprendimos de las coberturas varias décadas atrás.

Las coberturas pueden ser un poco más complicadas para trabajar cuando se trata de datos 3D (por ejemplo, modelar un puente que tiene un lado superior y un lado inferior justo debajo) porque los algoritmos que solíamos usar para tratar con ellos estaban inherentemente diseñados para matemática gráfica plana 2D .

Entonces, ¿por qué nos alejamos? Eso requeriría una respuesta más larga, pero quizás deberíamos explicar un poco más lo que hizo que los ESRI Shapefiles fueran populares primero.

2. ESRI Shapefiles:

A lo largo vino el Shapefile. Probablemente la característica más importante que tenía era que era / es una especificación abierta que era (comparativamente) fácil de implementar. Los atributos aprovecharon los archivos DBF , por lo que ya había muchas bibliotecas que implementaron una gran parte de la especificación. No existía el concepto de "limpio", lo que significaba que cada geometría individual solo tenía que preocuparse por representarse a sí misma sin tener en cuenta las geometrías a su alrededor o que se cruzaban. Esto significaba que no teníamos que hacer cálculos matemáticos complicados para asegurarnos de que un archivo de forma era correcto (a diferencia de la contraparte de cobertura).

¿Tiene múltiples geometrías que se cruzan entre sí? Seguro Por qué no. ¿Dos puntos uno encima del otro? Sé mi invitado.

A veces, el (posiblemente) formato "mejor" no es el que gana, sino el que se adopta. Si un formato es fácil de implementar, tiene más posibilidades de ser adoptado que uno complicado. Ese fue el Shapefile.

De repente, tenía varias bibliotecas (de código abierto y propietarias) y proveedores de software que lo respaldaban. Así que todo fue genial.

La pregunta obvia es entonces: ¿por qué las geodatabases?

3. Geodatabases:

Creo que las geodatabases son uno de los almacenes de datos geoespaciales más incomprendidos. La gente suele pensar en ellos como "un formato geoespacial". Hace un par de años, alguien preguntó "¿Qué son las geodatabases de ESRI?" . En lugar de repetir cuál fue mi respuesta entonces, le doy la bienvenida a leer eso primero. Esperaré :)

Ahora que leyó esa respuesta y sabe qué es una Geodatabase, puedo ampliar un poco más esa respuesta. En ese momento, hubo una gran cantidad de investigaciones que optimizaban SQL y escribían optimizadores de consultas que aprovechaban índices, almacenes de columnas, etc. (todavía lo hay). Al construir la Geodatabase sobre un almacén de datos SQL, podemos aprovechar toda esa investigación de forma gratuita. Solo necesitamos concentrarnos en los conceptos geoespaciales, y a medida que los almacenes de datos SQL mejoran, la Geodatabase también mejora, de forma gratuita . No es una mala propuesta ¿eh?

Hoy en día, existen varias especificaciones para los datos geoespaciales que salen. El jurado todavía está ahí afuera sobre lo que va a reemplazar estas tecnologías (si es que hay algo). Sin embargo, si está interesado en este tema, le recomiendo leer la respuesta a las preguntas que se hacen aquí en GIS. Algunos años atrás: "¿Hay algún intento de reemplazar el archivo de forma"?

¡Espero que esto ayude!

La mayor parte de la información se puede encontrar en la Ayuda de Esri y algunas búsquedas, por lo que acabo de compilar algunas buenas lecturas.

¿Cómo se almacenan las coberturas? Dado que es un formato propietario, no encontrará ninguna especificación técnica sobre cómo se implementan los algoritmos (a menos que @Vince arroje algo de luz).

Los archivos de forma llegaron más tarde y se implementaron como un estándar que proporcionaba un cierto nivel de interoperabilidad. La descripción técnica de ESRI Shapefile contiene una descripción completa.

Las geodatabases se introdujeron más adelante. Primero llegaron las geodatabases personales (MS Access), luego las geodatabases de archivos (formato cifrado binario) y las geodatabases corporativas (o ArcSDE) que aprovecharon la tecnología ArcSDE y DBMS. Puede leer más sobre geodatabases aquí: Tipos de geodatabases y La arquitectura de una geodatabase .

Una buena lectura sobre GIS.SE: ¿ Se debe utilizar la Geodatabase de archivos (* .gdb), la Geodatabase personal (* .mdb) o los archivos de forma?

Con respecto al rendimiento, se realizaron muchos puntos de referencia y las geodatabases de archivos mostraron ser las más rápidas en términos de lectura / escritura de información. Las geodatabases personales y los archivos de forma son mucho más lentos y probablemente la única razón para usarlos es admitir sistemas más antiguos que se construyeron teniendo en cuenta la lógica de negocios de MS Access o la lectura / conversión de archivos de forma.

La geodatabase basada en ArcSDE a menudo funciona casi tan bien como las geodatabases de archivos cuando se ajusta el DBMS, pero todo depende del tipo de datos almacenados, redes y hardware. Para obtener más información sobre los puntos de referencia, consulte los recursos de estrategias de diseño del sistema Esri (y aquí ).

La principal diferencia entre estos formatos es la forma en que las características se relacionan con las geometrías. En el apogeo de las coberturas, el lenguaje de codificación era FORTRAN, que significaba tamaños de búfer fijos en bloques COMUNES. El más restrictivo de estos fue 500 vértices por línea primitiva ("arco"). Esta restricción introdujo el concepto de "pseudo-nodos" (lugares donde los arcos se unen con solo otro arco), y complicó muchas otras operaciones de acceso a datos.

El modelo de cobertura utilizó una "lista de arcos de polígonos" (PAL) para describir los polígonos, que requerían un algoritmo de sombreado de polígonos para leer un archivo para obtener la lista de arcos, luego leer los arcos mismos para obtener el conteo de vértices, luego asignar suficiente RAM a almacene todos los vértices, luego vuelva a leer los arcos nuevamente, esta vez copiando los vértices en orden hacia adelante o hacia atrás para ensamblar un polígono completo. Solo después de dos visitas al archivo ARC podría describirse adecuadamente el polígono, y luego sería necesario acceder a muchos de los mismos arcos (en una dirección opuesta) para sombrear los vecinos del polígono.

En comparación, el shapefile y varios formatos de geodatabase almacenan la geometría completa como un solo objeto (con varios detalles de implementación sobre cómo se implementa físicamente el objeto). Esto tiene inconvenientes cuando se intenta editar límites compartidos, pero esa operación es significativamente menos frecuente que el sombreado de polígonos.

El modelo de almacenamiento de "forma completa" es la diferencia clave entre el formato de cobertura y los nuevos, y esta diferencia es tan fundamental que es difícil ver una diferencia real entre el archivo de forma y los diversos formatos de geodatabase. De hecho, el formato de archivo de forma se utilizó para acceder a las geometrías de FGDB a través de la API de FGDB, a pesar de que FGDB no usa ese formato exacto, simplemente porque era más simple que introducir un nuevo diseño de vértice.

Una diferencia más entre los formatos es que una geodatabase puede modelar relaciones entre clases de entidad . Como señaló Ragi,

Las coberturas funcionan muy bien para ediciones que requieren conocimiento de las relaciones topológicas (imagine editar un límite de parcela).

Pero esta conciencia existe solo dentro de una sola cobertura : si desea modelar las relaciones entre 2 o más coberturas, es su responsabilidad escribir el código que verifica las relaciones topológicas "ilegales".

Por ejemplo, si los polígonos de parcela no pueden tener huecos, y los límites de la parcela deben alinearse exactamente con las carreteras, con coberturas o archivos de forma, depende de usted verificar que este sea el caso y corregir manualmente cualquier error donde estas reglas no se cumplan.

Una geodatabase puede admitir opcionalmente un objeto de topología , que le permite definir las reglas topológicas permitidas para sus datos. Es importante destacar que estas reglas pueden ocurrir tanto dentro como entre clases de entidad en su geodatabase.

Las herramientas de edición de topología dentro de ArcMap lo ayudan a encontrar violaciones topológicas y, en algunos casos, a corregirlas automáticamente .

Antes de la introducción de la topología de la geodatabase ("los viejos tiempos"), era común escribir secuencias de comandos AML largas y complicadas para detectar violaciones topológicas, luego editar las coberturas manualmente en ArcEdit (no es muy divertido).