Implementazione del sistema di controllo versione per dati geospaziali? [chiuso]

Non che io abbia immediatamente bisogno di una risposta giusta qui, ma recentemente ho visto alcuni sforzi per introdurre il concetto di "sistemi di controllo della versione (distribuiti)" per i dati geografici. Alcuni esempi (di cui sono a conoscenza) sono i tre white paper di OpenGeo ( 1 , 2 e 3 ) e il progetto " Geosynkronisering ( geosyncronization )" dei venditori norvegesi di software GIS e della Norwegian Mapping Agency. Ho anche trovato il versioning distribuito dei dati geospaziali? , che menziona GeoGit (di OpenGeo) e l' applicazione del controllo versione ai modelli ArcGIS ModelBuilder? sul controllo della versione in ArcGIS.

Essendo uno sviluppatore, conosco (almeno abbastanza per essere in grado di usarli) come funzionano i sistemi di controllo versione per codice sorgente (come SVN e Git), e il mio background in geomatica mi dice che ci sono alcune sfide uniche con i dati geografici che rendono il approccio non completamente simile al modo in cui viene gestito il codice sorgente (che è fondamentalmente testo).

Quali sono le sfide nel trattare con (d) i VCS per i dati geografici, come li risolveresti, ne abbiamo bisogno e ci sono altri tentativi di risolvere questi problemi rispetto a quelli che ho citato?

So che i white paper di OpenGeo risponderanno ad alcune delle mie domande, ma quello che sto veramente cercando è una risposta più "pedagogica", nello stile di "dimmi come se avessi 10 anni", in modo che Posso rimandare le persone a una grande spiegazione delle sfide e delle soluzioni che i dati geografici portano al mix.

Spero che qualcuno con qualche intuizione impiegherà del tempo per fornire alcune riflessioni sulla questione, poiché ho detto che non sto attualmente cercando di risolvere un problema particolare, ma questo argomento è uno che mi interessa.

Attualmente stiamo lavorando ad una riprogettazione completa dei nostri geodatastores. Devo dire che la loro evoluzione ha richiesto più di 20 anni fino ad ora. Abbiamo identificato le seguenti funzionalità chiave nella gestione dei dati geospaziali:

• editing simultaneo
• autorizzazioni per leggere o scrivere porzioni di dati
• aggiornamento a caldo durante l'esecuzione di servizi che si basano sui dati (Transazioni e paradigma ACID)
• schema interno ed esterno (la modifica dello schema interno non dovrebbe influire sui servizi)
• capacità di memorizzare e accedere a grandi quantità di dati (terabyte di raster e centinaia di gigabyte di dati vettoriali)
• coerenza dei dati tra diversi livelli (ogni pacco appartiene a un distretto e così via)

Abbiamo valutato i seguenti approcci, ecco cosa posso dire al riguardo:

1. Geodatabase aziendale ESRI(ArcGIS 10.1); più o meno lo stesso di quello che avevamo prima (SDE), ma con un ampio uso della funzionalità di controllo delle versioni per gestire le transazioni. Ma semplicemente non è davvero un Geodatabase aziendale, a mio avviso SDE funziona solo in un gruppo di lavoro come server di geodati, dove le persone lavorano dalle 8:00 alle 20:00 e puoi metterlo offline per attività di manutenzione, commit delle transazioni (versioning riconciliare e pubblicare nel discorso ESRI), replica, ecc. Se si creano servizi sopra questi dati, è necessario gestire un database di gestione temporanea (dove viene svolto il lavoro) e un database di produzione replicato. Questo è praticamente lo stesso di build / test e deploy in programmazione. Sebbene il pacchetto ricco di funzionalità fornito da ESRI sia piuttosto interessante, manca di flessibilità (modifiche dello schema o attività di manutenzione mentre le persone lavorano, ad esempio la creazione di indici).

2. File flat e un sistema di controllo della versionescegliamo Git (non sapevo che esistesse già un GeoGit). Oh sì, alcuni dei miei amici e anche io provengono dall'ingegneria del software. Potrebbe essere tutto così semplice. Penso che sia il suo problema: è come un meccanico che costruisce un'auto. Sarà semplice da mantenere per lui, ma sarà anche fastidioso da guidare e dannatamente brutto da guardare con certezza. Penso che abbia anche alcuni importanti svantaggi: come controllare la versione di un Rasterdataset 2 TeraByte (o anche più, binario)? E in quale formato? I dati vettoriali possono essere facilmente controllati dalla versione se si utilizzano formati basati su testo (GML ad esempio), ma è anche difficile lavorare con un set di dati da un miliardo di righe. Non sono ancora sicuro che possiamo fare un'efficace gestione delle autorizzazioni degli utenti, perché non tutti dovrebbero essere autorizzati a modificare o persino visualizzare tutto. E come unire un set di dati vettoriali che è stato modificato in modo intensivo da 4 utenti contemporaneamente? Almeno devi essere un vero informatico / programmatore per fare tutto questo in modo efficace ... i nostri utenti GIS sono pianificatori, geometri, geologi e così via. È semplicemente un problema per loro pensare ai lignaggi delle versioni come fanno i programmatori o usare la ramificazione come dovrebbe. Tuttavia, pensare ai datastore come repository condivisi è un'idea interessante.

3. Database tabellare piatto come un semplice contenitore. Lo stesso di SDE, ma senza roba SDE. Ancora difficile da mantenere, perché in realtà non si utilizzano i vantaggi offerti da un RDBMS. Sì, è molto semplice caricare tutto in un database, ma non è affatto la gestione dei dati.

4. Bigdata e NoSQL . Stessi problemi di file flat e tabelle flat. A mio avviso, una semplice API del filesystem da utilizzare nel web. Sì, funziona bene nel Web, e sì, è facile inserire semplicemente i tuoi documenti, ma penso che se voglio realizzare un'analisi dei dati spaziali su terabyte di dati (possibilmente raster), mi piacerebbe che non fosse serializzato e deserializzato tramite l'interfaccia HTTP.

AGGIORNAMENTO 2018: ecco un sacco di novità che creano molto slancio. Per dirne alcuni:

• Cloud block storage e HDFS
• Python / shapely / Dask Stack

• Apache Spark

  • GeoMesa / GeoWave per dati vettoriali
  • GeoTrellis per dati raster

• e altro ancora

  5. Modellazione di database classica completa(con un RDBMS). Il problema principale è che è difficile semplicemente eliminare i dati ovunque e sperare che si adatti a tutte le esigenze future. Ma se si impiega molto tempo per specificare un modello di dati affidabile (in effetti anche OSM lo ha fatto) in un database, si è in grado di sfruttare tutti i suoi vantaggi. Possiamo modificare e aggiornare i dati nelle transazioni distribuite, possiamo anche modificare il loro schema principale, mentre i servizi si basano ancora su schemi esterni degli stessi dati, possiamo mantenerli, possiamo verificarne la coerenza, possiamo consentire e negare le autorizzazioni, siamo in grado di archiviare grandi quantità di dati mentre possiamo ancora accedervi in ​​modo rapido, siamo in grado di costruire modelli di dati storici e attivarli in modo trasparente e così via. Poiché utilizziamo il server SQL, ci manca ancora un tipo raster nativo, ma altri fornitori di database offrono già questo.

Bene, penso che il modello di database relazionale sia appena arrivato nel mondo spaziale con tipi di dati spaziali negli ultimi due anni (prima ancora che in BLOB Containers) ed è ancora la forma più flessibile e professionale di archiviazione dei dati. Ciò non significa che non dovrebbe essere integrato con approcci VCS o NoSQL, ma vedo questi approcci più probabilmente come una forma di distribuzione dei dati in gruppi di utenti che come una forma di gestione dei dati spaziali centralizzata professionale. Inoltre OSM ha centralizzato molte attività, che la folla non può proprio fornire, come l'importazione di grandi quantità di dati (la maggior parte dei dati OSM in Austria è stata importata in un giorno, non crowdsourcing) e la generazione di piastrelle. La parte collaborativa (crowdsourcing) è davvero molto importante, ma è solo metà degli affari.

Penso di dover riformulare molto questo e fornire ulteriori fatti. Una domanda come questa è difficile da rispondere in modo completo in un paio d'ore, cercherò di migliorare la qualità della mia risposta nei prossimi giorni