Qual é a diferença entre Coverage, Shapefiles e Geodatabases no ArcGIS?

Eu estava pensando sobre a diferença na metodologia de armazenamento de dados espaciais usada por Coverages, Shapefiles e Geodatabases no ArcGIS. A cobertura foi o formato inicial, seguido pelo Shape Files e agora Geodatabases. Então, o que melhorou nesses novos formatos de Shapefiles e Geodatabases?

Seria ótimo se alguém pudesse explicar isso com exemplos.

Essa é uma ótima pergunta. Coberturas, Shapefile e Geodatabases são fundamentalmente diferentes armazenamentos de dados geoespaciais do ponto de vista da implementação e do filosófico. Vou tentar resumir sem me aprofundar muito nisso.

1. Coberturas:

As coberturas são estruturas de dados geoespaciais interessantes . Eles se concentram no armazenamento da topologia. Então você verá que a ênfase está no armazenamento dos elementos da geometria primeiro, ou seja, nos nós, arestas que compõem todas as geometrias. Você verá um conjunto separado de tabelas que relacionam essas geometrias aos atributos (e, portanto, elas "se tornam" recursos).

Uma cobertura "limpa" garante certas regras, por exemplo, que existem nós em todas as intersecções, você não terá dois (ou mais) nós uns sobre os outros (ou mesmo a uma distância de tolerância difusa), que não há duas arestas umas sobre as outras etc. Eles também têm um senso de direção (de-> para) e podem distinguir entre o que está do lado esquerdo e direito.

As coberturas funcionam muito bem para edições que exigem conhecimento das relações topológicas (imagine editar um limite de parcela). Além disso, as coberturas são compactadas muito bem, pois removem a redundância geométrica por design. De fato, você verá que hoje em dia, formatos modernos como o TopoJSON começaram a usar as mesmas técnicas que aprendemos nas coberturas várias décadas atrás.

As coberturas podem ser um pouco mais complicadas de se trabalhar quando você está lidando com dados 3D (por exemplo, modelando uma ponte que tem um lado superior e um lado inferior logo abaixo) porque os algoritmos que usamos para lidar com eles eram inerentemente significados para matemática de gráfico planar 2D .

Então, por que nos afastamos disso? Isso exigiria uma resposta mais longa, mas talvez devêssemos explicar um pouco mais o que tornou os Shapefiles da ESRI populares primeiro.

2. Arquivos de forma ESRI:

Junto veio o Shapefile. Provavelmente a característica mais importante que possuía era o fato de ser / é uma especificação aberta que era (comparativamente) simples de implementar. Os atributos utilizaram os arquivos DBF , portanto, já havia muitas bibliotecas que implementavam grande parte das especificações. Não havia conceito de "limpo", o que significava que cada geometria individual só precisava se preocupar em se representar sem levar em consideração as geometrias ao seu redor ou que elas se cruzavam. Isso significava que não precisávamos fazer nenhuma matemática complicada para garantir que um shapefile estivesse correto (ao contrário do equivalente na cobertura).

Tem várias geometrias que se cruzam? Claro, por que não. Dois pontos um em cima do outro? Seja meu convidado.

Às vezes, o formato (melhor) (sem dúvida) "não" é o que vence, mas o que é adotado. Se um formato é fácil de implementar, ele tem melhores chances de ser adotado do que um formato complicado. Esse foi o Shapefile.

De repente, você tinha várias bibliotecas (de código aberto e proprietárias) e fornecedores de software que a apoiavam. Então tudo foi ótimo.

A questão óbvia é então - por que Geodatabases?

3. Banco de dados geográficos:

Acredito que os geodatabases são um dos repositórios de dados geoespaciais mais incompreendidos. As pessoas geralmente pensam neles apenas como "um formato geoespacial". Há alguns anos, alguém perguntou "O que são os geodatabases da ESRI?" . Em vez de repetir qual era a minha resposta então, desejo que você leia isso primeiro. Eu vou esperar :)

Agora que você leu a resposta e sabe o que é um Geodatabase, eu posso expandir um pouco mais sobre essa resposta. Na época, havia muita pesquisa otimizando o SQL e otimizadores de consulta de escrita que alavancavam índices, armazenamentos de colunas etc. (ainda existe). Ao criar o Geodatabase no topo de um armazenamento de dados SQL, podemos aproveitar toda essa pesquisa gratuitamente. Nós precisamos apenas nos concentrar nos conceitos geoespaciais e, à medida que os repositórios de dados SQL melhoram, o Geodatabase também melhora gratuitamente . Não é uma proposição ruim, hein?

Atualmente, existem várias especificações para dados geoespaciais que são lançados. O júri ainda está por aí sobre o que substituirá essas tecnologias (se houver). No entanto, se você estiver interessado neste tópico, recomendo ler a resposta para as perguntas feitas aqui no GIS.SE há alguns anos: "Existe alguma tentativa de substituir o arquivo de formas"

Eu espero que isso ajude!

A maioria das informações pode ser encontrada na Ajuda da Esri e em algumas pesquisas, então eu apenas compilei algumas boas leituras.

Como as coberturas são armazenadas? Como é um formato proprietário, você não encontrará especificações técnicas sobre como os algoritmos são implementados (a menos que o @Vince mostre alguma luz).

Os shapefiles vieram mais tarde e foram implementados como um padrão que fornecia um certo nível de interoperabilidade. A Descrição Técnica do ESRI Shapefile contém uma descrição completa.

Os bancos de dados geográficos foram introduzidos posteriormente. Primeiro vieram os bancos de dados pessoais (MS Access), depois os bancos de dados de arquivos (formato criptografado binário) e os bancos de dados corporativos (ou ArcSDE), que aproveitaram a tecnologia ArcSDE e DBMS. Você pode ler mais sobre bancos de dados geográficos aqui: Tipos de bancos de dados geográficos e A arquitetura de um banco de dados geográficos .

Uma boa leitura sobre o GIS.SE: se você deseja usar o geodatabase de arquivo (* .gdb), o geodatabase pessoal (* .mdb) ou os shapefiles?

Em relação ao desempenho, foram realizados muitos benchmarks e os bancos de dados geográficos de arquivos mostraram ser os mais rápidos em termos de leitura / gravação de informações. Os bancos de dados geográficos e shapefiles pessoais são muito mais lentos e provavelmente a única razão para usá-los é oferecer suporte a sistemas mais antigos, construídos com lógica de negócios do MS Access ou leitura / conversão de shapefile em mente.

O geodatabase baseado em ArcSDE costuma ter um desempenho quase tão bom quanto o de geodatabases quando o DBMS é ajustado, mas tudo depende do tipo de dados armazenados, redes e hardware. Para obter mais informações sobre benchmarks, consulte os recursos das estratégias de design do sistema Esri (e aqui ).

A principal diferença entre esses formatos é a maneira como os recursos se relacionam às geometrias. No auge das coberturas, a linguagem de codificação era FORTRAN, o que significava tamanhos de buffer fixos em blocos COMMON. O mais restritivo deles foram 500 vértices por linha primitiva ("arco"). Essa restrição introduziu o conceito de "pseudo-nós" (locais onde os arcos se juntam a apenas um outro arco) e complicou muitas outras operações de acesso a dados.

O modelo de cobertura usou uma "lista de arco de polígonos" (PAL) para descrever polígonos, o que exigia um algoritmo de sombreamento de polígono para ler um arquivo para obter a lista de arcos, depois ler os próprios arcos para obter a contagem de vértices e alocar RAM suficiente para armazene todos os vértices e volte a ler os arcos novamente, desta vez copiando os vértices na ordem direta ou inversa para montar um polígono completo. Somente após duas visitas ao arquivo ARC o polígono poderia ser descrito adequadamente e, em seguida, muitos dos mesmos arcos precisariam ser acessados ​​(em uma direção oposta) para sombrear os vizinhos do polígono.

Por comparação, o shapefile e vários formatos de geodatabase armazenam a geometria completa como um único objeto (com vários detalhes de implementação sobre como o objeto é fisicamente implementado). Isso tem desvantagens ao tentar editar limites compartilhados, mas essa operação é significativamente menos frequente que o sombreamento de polígono.

O modelo de armazenamento "formato completo" é a principal diferença entre o formato de cobertura e os novos, e essa diferença é tão fundamental que é difícil ver qualquer diferença real entre o shapefile e os vários formatos de banco de dados geográficos. De fato, o formato shapefile foi usado para acessar as geometrias do FGDB por meio da API do FGDB, embora o FGDB não use esse formato exato, apenas porque era mais simples do que a introdução de um novo layout de vértice.

Mais uma diferença entre os formatos é que um geodatabase pode modelar relacionamentos entre classes de recursos . Como Ragi observou,

As coberturas funcionam muito bem para edições que exigem conhecimento das relações topológicas (imagine editar um limite de parcela).

Mas essa conscientização existe apenas dentro de uma única cobertura - se você deseja modelar os relacionamentos entre 2 ou mais coberturas, é sua responsabilidade escrever o código que verifica se existem relacionamentos topológicos "ilegais".

Por exemplo, se os polígonos das parcelas não podem ter lacunas, e os limites das parcelas devem se alinhar exatamente com as estradas, com coberturas ou arquivos de forma, você deve verificar se é esse o caso e corrigir manualmente os erros onde essas regras não são respeitadas.

Um geodatabase pode opcionalmente suportar um objeto Topology , o que permite definir as regras topológicas permitidas para seus dados. É importante ressaltar que essas regras podem ocorrer dentro e entre as classes de recursos no seu geodatabase.

As ferramentas de edição de topologia no ArcMap ajudam a encontrar violações topológicas e, em alguns casos, corrigi-las automaticamente .

Antes da introdução da topologia de geodatabase ("os bons e velhos tempos"), era comum escrever scripts AML longos e complicados para detectar violações topológicas e editar as coberturas manualmente no ArcEdit (não muito divertido).