Come gestire il controllo delle versioni in OpenStreetMap?

L'argomento della gestione dei dati geospaziali in un senso più generale è emerso prima qui. Anche qui l'argomento del controllo delle versioni è stato menzionato, ma non è stato affrontato.

La raccolta e la manutenzione dei dati geospaziali tradizionali devono solo gestire le versioni internamente, poiché il database viene aggiornato solo dall'interno dell'organizzazione. Questo non è il caso di geodatabase di crowdsourcing come OpenStreetMap. Lì, chiunque può venire e aggiungere, modificare o eliminare oggetti. In OpenStreetMap questo viene gestito in modo rudimentale: ogni oggetto ha un numero di versione intero e solo l'oggetto con la versione più alta viene esposto nel database live. Il database utilizza il blocco ottimistico, quindi gli utenti devono risolvere tutti i conflitti che si verificano durante il caricamento manuale dei contributi.

Tutto funziona abbastanza bene fintanto che i contributi umani attraverso gli editor ( JOSM , Potlatch ) sono l'unica modalità di contributo, ma non lo sono. Sempre più spesso vengono condotte importazioni di dati aperti del settore pubblico. Ciò crea problemi di versioning più complessi. Considera il seguente scenario:

1. Un oggetto edificio viene importato da un set di dati del settore pubblico aperto
2. L'edificio riceve alcune modifiche dai contributori umani (attributi, geometria o entrambi)
3. Una nuova versione dei dati del settore pubblico diventa disponibile e viene importata.

Attualmente, nel passaggio 3. i contributi umani andrebbero persi, a meno che ogni edificio che ha ricevuto modifiche comunitarie sia unito manualmente alla nuova importazione.

Come può OpenStreetMap gestire questa situazione? Dobbiamo esaminare il controllo della versione distribuita nello sviluppo del software? Come possono essere adattati i metodi di DVC per gestire la manutenzione distribuita dei dati spaziali?

Ho sognato qualcuno che implementasse l'editing non distruttivo per i dati GIS. È ad alta intensità di calcolo ma non dovrebbe essere un attrezzo difficile in un RDBMS.

Inizia con un'istantanea dei dati. Eventuali modifiche vengono salvate come modifiche, i dati originali rimangono invariati. Nel tuo esempio, gli edifici provengono inizialmente dai dati del settore pubblico. Quando un utente effettua una modifica, la modifica o la differenza viene salvata in una tabella separata. Quando qualcuno visualizza la funzione, riceve l'originale più eventuali modifiche applicate. Le modifiche successive sono la differenza calcolata tra la nuova forma della funzione e l'originale più tutte le modifiche precedenti.

Questo ti dà la possibilità di annullare a un livello a grana fine. È essenzialmente ciò che fa il controllo della versione. Un buon esempio di editing non distruttivo è Aperture di Apple. Le immagini digitali importate in Aperture non vengono modificate direttamente. Cambiamenti nei livelli, nitidezza, sfocatura, ecc. Vengono memorizzati come modifiche e applicati al volo quando si lavora con un'immagine. Qualsiasi modifica può essere rimossa all'istante.

Ovviamente, si prenderebbero istantanee del DB per la distribuzione e l'uso negli ambienti di produzione. Questo sarebbe solo per lo sviluppo e la modifica.

Dai un'occhiata a Versioning PostGIS , pgVersion e Post Facto per idee e possibili soluzioni. Si tratta di sistemi di controllo versione implementati nei database PostgreSQL.

OSM utilizza Postgres e Postgis che mantiene un'istantanea del database.

Per implementarlo sul proprio server e database

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

Il database (plantet.osm) viene aggiornato settimanalmente http://wiki.openstreetmap.org/wiki/Planet_dump

L'osmosi è abituata"ha componenti per la lettura dal database e dal file, componenti per la scrittura nel database e nel file, componenti per derivare e applicare set di modifiche alle origini dati"

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

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

Ho pensato a questo problema e ho avuto un'idea, ma non l'ho provato. Potrebbe funzionare:

Usa il sistema di controllo versione come Mercurial o Git. Mercurial sarà più semplice, poiché consente di creare facilmente rami anonimi.

Ora, dalla revisione iniziale, avvia un ramo per le importazioni del set di dati pubblico. Quindi, ci saranno 2 rami:

1. mainline (OSM)
2. set di dati pubblico X

Un'importazione dal set di dati pubblico deve essere eseguita nel ramo 2, quindi unita nel ramo OSM.

Il tuo scenario potrebbe funzionare in questo modo:

• un oggetto non esisteva
• quindi viene importato e unito nel ramo 1
• quindi viene modificato nella linea principale, inclusa la geometria
• viene importato di nuovo nel ramo 2
• quando viene unito nel ramo 1, solo i dati che sono stati aggiornati nel ramo 2 vengono aggiornati nel ramo 1

Ciò potrebbe richiedere la suddivisione dei dati in più file, uno per oggetto e probabilmente in un formato come JSON, in modo che VCS possa facilmente gestire le modifiche agli attributi separati.

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

So che dividere un'informazione in un miliardo di file è troppo per qualsiasi sistema. Invece dovrebbe essere usato il nucleo di VCS e i dati OSM dovrebbero essere elaborati e inseriti in VCS in una versione versionabile. (O un filesystem può essere deriso).

Non posso garantire che funzionerà.