Implementando sistema de controle de versão para dados geoespaciais? [fechadas]

Não que eu precise imediatamente de uma resposta certa aqui, mas ultimamente tenho visto alguns esforços para introduzir o conceito de "sistemas de controle de versão (distribuídos)" para dados geográficos. Alguns exemplos (que eu conheço) são os três whitepapers da OpenGeo ( 1 , 2 e 3 ) e o projeto " Geosynkronisering (geosyncronization)" dos fornecedores noruegueses de software GIS e da Norwegian Mapping Agency. Também encontrei versionamento distribuído de dados geoespaciais? , que menciona o GeoGit (da OpenGeo) e Aplicando controle de versão aos modelos do ArcGIS ModelBuilder? sobre controle de versão no ArcGIS.

Como desenvolvedor, eu sei (pelo menos o suficiente para poder usá-los) como os sistemas de controle de versão para código-fonte (como SVN e Git) funcionam, e minha formação em geomática me diz que existem alguns desafios exclusivos com dados geográficos que tornam o abordagem não completamente semelhante à maneira como o código-fonte (que é basicamente texto) é tratado.

Quais são os desafios ao lidar com (d) VCSs para dados geográficos, como você os resolveria, precisamos deles e existem outras tentativas para resolver esses problemas além dos mencionados?

Sei que os documentos oficiais da OpenGeo responderão a algumas de minhas perguntas, mas o que realmente busco é uma resposta mais "pedagógica", no estilo de "diga-me como se eu tivesse 10 anos de idade", para que Posso encaminhar as pessoas para uma ótima explicação dos desafios e soluções que os dados geográficos trazem para o mix.

Espero que alguém com alguma visão leve algum tempo para fornecer algumas idéias sobre o assunto, pois eu disse que atualmente não estou procurando resolver um problema específico, mas esse tópico é do meu interesse.

Atualmente, estamos trabalhando em uma reformulação completa de nossos geodatastores. Devo dizer que a evolução deles levou mais de 20 anos até agora. Identificamos os seguintes recursos-chave no gerenciamento de dados geoespaciais:

• edição simultânea
• permissões para ler ou gravar partes de dados
• atualização quente durante a execução de serviços que dependem de dados (paradigma Transações e ACID)
• esquema interno e externo (a modificação do esquema interno não deve afetar os serviços)
• capacidade de armazenar e acessar grandes quantidades de dados (terabytes de varredura e centenas de gigabytes de dados vetoriais)
• consistência dos dados entre diferentes camadas (cada parcela pertence a um distrito e assim por diante)

Avaliamos as seguintes abordagens, eis o que posso dizer sobre elas:

1. Geodatabase ESRI Enterprise(ArcGIS 10.1); praticamente o mesmo que tínhamos antes (SDE), mas com o uso extensivo do recurso de controle de versão para lidar com transações. Mas simplesmente não é realmente um banco de dados corporativo corporativo; na minha opinião, a SDE funciona apenas em um grupo de trabalho como um servidor de dados geográficos, onde as pessoas trabalham das 8:00 às 20:00, e você pode colocá-lo offline para tarefas de manutenção, confirmação de transação (reconciliação de versão e postagem na fala ESRI), replicação, etc ... Se você criar serviços sobre esses dados, precisará lidar com um banco de dados intermediário (onde o trabalho é feito) e um banco de dados de produção replicado. É praticamente o mesmo que construir / testar e implantar na programação. Embora o pacote rico em recursos que o ESRI entregue seja bastante bom, ele não possui flexibilidade (alterações de esquema ou tarefas de manutenção enquanto as pessoas estão trabalhando, criação de índice, por exemplo).

2. Arquivos simples e um sistema de controle de versãoescolhemos Git (não sabia que já existe um GeoGit). Ah, sim, alguns de meus amigos e eu também somos da engenharia de software. Tudo poderia ser tão simples. Acho que esse é o seu problema: é como um mecânico de automóveis construindo um carro. Vai ser simples de manter para ele, mas também será chato dirigir e muito feio de se ter certeza. Eu acho que também tem algumas grandes desvantagens: Como controlar a versão de um Rasterdataset 2 TeraByte (ou até mais, binário)? E em qual formato? Os dados vetoriais podem ser facilmente controlados por versão se você usar formatos baseados em texto (GML, por exemplo), mas também é difícil trabalhar com um conjunto de dados de bilhões de linhas. Ainda não tenho certeza se podemos fazer um gerenciamento eficaz de permissão de usuário, porque nem todos devem ter permissão para editar ou até mesmo visualizar tudo. E como você mescla um conjunto de dados vetoriais que foi editado intensivamente por 4 usuários ao mesmo tempo? Pelo menos você precisa ser um cientista / programador de computador real para fazer tudo isso de forma eficaz ... nossos usuários de GIS são planejadores, topógrafos, geólogos e assim por diante. Simplesmente é um problema para eles pensarem em linhagens de versões como os programadores, ou usar ramificações da maneira que deveriam. No entanto, pensar nos datastores como repositórios compartilhados é uma ideia interessante.

3. Banco de dados com tabela plana como um contêiner simples. O mesmo que a SDE faz, mas sem as coisas da SDE. Ainda é difícil de manter, porque você realmente não aproveita as vantagens que um RDBMS oferece. Sim, é muito simples carregar apenas tudo em um banco de dados, mas isso não é gerenciamento de dados.

4. Bigdata e NoSQL . Mesmos problemas que arquivos simples e tabelas simples. Na minha opinião, uma API simples do sistema de arquivos para uso na web. Sim, ele funciona bem na Web, e sim, é fácil simplesmente inserir seus documentos, mas acho que se eu quiser realizar uma análise de dados espaciais em terabytes de dados (possivelmente rasterizados), eu gostaria que ele não fosse serializado e desserializado pela interface HTTP.

ATUALIZAÇÃO 2018: Aqui estão muitas coisas novas, criando muito impulso. Para nomear alguns:

• Armazenamento em bloco na nuvem e HDFS
• Python / bem torneado / Dask Stack

• Apache Spark

  • Dados GeoMesa / GeoWave for Vector
  • GeoTrellis para dados rasterizados

• e muito mais

  5. Modelagem de banco de dados clássica abrangente(com um RDBMS). O principal problema é que é difícil simplesmente soltar dados em qualquer lugar e esperar que eles se ajustem a todas as necessidades futuras. Porém, se você dedicar um tempo para especificar um modelo de dados robusto (o OSM também fez isso de fato) em um banco de dados, poderá usar todas as suas vantagens. Podemos editar e atualizar dados em transações distribuídas, também podemos modificar seu esquema principal, enquanto os serviços ainda contam com esquemas externos dos mesmos dados, podemos mantê-lo, podemos verificar sua consistência, podemos permitir e negar permissões, estamos capaz de armazenar quantidades muito grandes de dados enquanto ainda podemos acessá-los de maneira rápida, somos capazes de construir modelos de dados históricos e acioná-los de forma transparente e assim por diante. Como usamos o servidor sql, ainda não temos um tipo de varredura nativa, mas outros fornecedores de banco de dados já oferecem isso.

Bem, eu acho que o modelo de banco de dados relacional acaba de aparecer no mundo espacial com tipos de dados espaciais nos últimos dois anos (antes disso, onde BLOB Containers) e ainda é a forma mais flexível e profissional de armazenar dados. Isso não significa que não deva ser complementado com abordagens VCS ou NoSQL, mas vejo essas abordagens mais provavelmente como uma forma de distribuição de dados em grupos de usuários do que como uma forma de gerenciamento profissional centralizado de dados espaciais. Além disso, o OSM centralizou muitas tarefas, que a multidão simplesmente não pode fornecer, como importar grandes quantidades de dados (a maioria dos dados do OSM na Áustria foi importada em um dia, não com crowdsourcing) e geração de blocos. A parte colaborativa (crowdsourcing) é realmente muito importante, mas é apenas metade dos negócios.

Acho que preciso reformular muito isso e fornecer mais fatos. Uma pergunta como essa é difícil de responder de maneira abrangente em algumas horas. Tentarei melhorar a qualidade da minha resposta nos próximos dias.