Como lidar com o versionamento no OpenStreetMap?

O tópico de gerenciamento de dados geoespaciais em um sentido mais geral já foi abordado aqui. O tópico do versionamento também foi mencionado lá, mas não foi realmente tratado.

A coleta e manutenção de dados geoespaciais tradicionais só precisam lidar com o controle de versão internamente, pois o banco de dados é atualizado apenas de dentro da organização. Esse não é o caso de bancos de dados geográficos de fontes múltiplas, como o OpenStreetMap. Lá, qualquer pessoa pode aparecer e adicionar, modificar ou excluir objetos. No OpenStreetMap, isso é tratado de maneira rudimentar: cada objeto possui um número de versão inteiro e apenas o objeto com a versão mais alta é exposto no banco de dados ativo. O banco de dados usa bloqueio otimista, portanto, os usuários devem resolver todos os conflitos que ocorrem ao fazer upload de contribuições manualmente.

Tudo isso funciona razoavelmente bem, desde que as contribuições humanas através dos editores ( JOSM , Potlatch ) sejam o único modo de contribuição - mas não são. Cada vez mais, as importações de dados abertos do setor público são realizadas. Isso gera problemas de versão mais complexos. Considere o seguinte cenário:

1. Um objeto de construção está sendo importado de um conjunto de dados aberto do setor público
2. O edifício recebe algumas modificações de colaboradores humanos (atributos, geometria ou ambos)
3. Uma nova versão dos dados do setor público fica disponível e é importada.

Atualmente, na etapa 3. as contribuições humanas seriam perdidas, a menos que cada edifício que recebeu modificações na comunidade seja mesclado manualmente com a nova importação.

Como o OpenStreetMap pode lidar com essa situação? Precisamos examinar o controle de versão distribuído no desenvolvimento de software? Como os métodos de DVC podem ser adaptados para lidar com a manutenção de dados espaciais distribuídos?

Eu sonhei com alguém implementando edição não destrutiva para dados GIS. É intensivo em computação, mas não deve ser difícil de implementar em um RDBMS.

Comece com uma captura instantânea dos dados. Quaisquer alterações são salvas como edições, os dados originais permanecem inalterados. No seu exemplo, os prédios vêm inicialmente dos dados do setor público. Quando um usuário faz uma edição, a alteração ou diferença é salva em uma tabela separada. Quando alguém visualiza o recurso, recebe o original mais as edições aplicadas. As edições subsequentes são a diferença calculada entre a nova forma do recurso e o original mais todas as edições anteriores.

Isso permite que você desfaça em um nível refinado. É essencialmente o que o controle de versão faz. Um bom exemplo de edição não destrutiva é o Aperture da Apple. As imagens digitais importadas no Aperture não são modificadas diretamente. Alterações nos níveis, nitidez, desfoque, etc. são armazenadas como edições e aplicadas em tempo real quando você trabalha com uma imagem. Qualquer alteração pode ser removida instantaneamente.

Obviamente, você tiraria instantâneos do banco de dados para distribuição e uso em ambientes de produção. Isso seria apenas para desenvolvimento e edição.

Dê uma olhada no Versioning PostGIS , pgVersion e Post Facto para obter idéias e possíveis soluções. Estes são sistemas de controle de versão implementados nos bancos de dados PostgreSQL.

O OSM usa Postgres e Postgis, que mantém um instantâneo do banco de dados.

Para implementar isso em seu próprio servidor e banco de dados

http://wiki.openstreetmap.org/wiki/Databases#Choice_of_DBMS

O banco de dados (plantet.osm) é atualizado semanalmente http://wiki.openstreetmap.org/wiki/Planet_dump

Osmose é usada para"possui componentes para leitura do banco de dados e do arquivo, componentes para gravação no banco de dados e no arquivo, componentes para derivar e aplicar conjuntos de alterações às fontes de dados"

http://wiki.openstreetmap.org/wiki/Osmosis

Changsets: http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#Changeset_Derivation_and_Merging

Eu pensei neste problema e tive uma idéia, mas não testei. Pode funcionar:

Use o sistema de controle de versão como Mercurial ou Git. O Mercurial será mais fácil, pois permite criar facilmente ramificações anônimas.

Agora, a partir da revisão inicial, inicie uma ramificação para as importações públicas de conjuntos de dados. Então, haverá 2 ramos:

1. linha principal (OSM)
2. conjunto de dados público X

Uma importação do conjunto de dados público deve ser feita na ramificação 2 e depois mesclada na ramificação OSM.

Seu cenário pode funcionar assim:

• um objeto não existia
• depois é importado e mesclado na filial 1
• então é modificado na linha principal, incluindo a geometria
• é importado novamente na filial 2
• quando é mesclado na ramificação 1, apenas os dados que foram atualizados na ramificação 2 são atualizados na ramificação 1

Isso pode exigir a divisão dos dados em vários arquivos, um por objeto e provavelmente em um formato como json, para que o VCS possa lidar facilmente com as alterações nos atributos separados.

{
     id: 1357
     lat: 1,
     lon: 2,
     tags: {
          'building': 'entrance'
     }
     type: 'node',
}
{
     nodes: [
         1357,
         2468
     ],
     tags: {
         building: 'yes',
     }
     type: 'way',
}

Eu sei que dividir uma informação em um bilhão de arquivos é demais para qualquer sistema. Em vez disso, o núcleo do VCS deve ser usado e os dados OSM devem ser processados ​​e alimentados no VCS em um formato com versão. (Ou um sistema de arquivos pode ser ridicularizado).

Não posso garantir que isso funcione.