Gestire grandi quantità di dati geospaziali? [chiuso]

Come gestite i vostri dati geospaziali? Ho terabyte di dati distribuiti su centinaia di set di dati e ho una soluzione ad-hoc che utilizza collegamenti simbolici all'interno di progetti che rimandano a una directory di archivio basata su nomi di dominio per ogni set di dati. Funziona principalmente, ma ha i suoi problemi.

Sono anche desideroso di sapere se qualcuno gestisce i propri dati geospaziali in un sistema di controllo delle revisioni; Attualmente ne uso uno per il mio codice e piccoli set di dati, ma non per i set di dati completi.

Penso che la risposta stock / ovvia sarebbe quella di utilizzare un database spaziale (PostGIS, Oracle, SDE, MSSQL Spatial, ecc.) Insieme a un server di metadati come GeoPortal di esri o l'applicazione GeoNetwork open source, e nel complesso penso che questo sia generalmente la migliore soluzione. Tuttavia, probabilmente avrai sempre bisogno di snapshot / rami / tag basati su progetto. Alcuni dei database più avanzati hanno modi di gestirli, ma generalmente non sono così facili da usare / gestire.

Per le cose che memorizzi al di fuori di un database (immagini di grandi dimensioni, file basati su progetti) penso che la chiave sia avere una convenzione di denominazione coerente e di nuovo un registro dei metadati (anche qualcosa di a bassa tecnologia come un foglio di calcolo) che ti consenta di rintracciarli e assicurarsi che siano gestiti correttamente. Ad esempio, nel caso di file basati su progetto, ciò può significare eliminarli quando la politica di gestione dei record lo richiede o arrotolarli nel repository centrale al completamento del progetto.

Ho visto alcune soluzioni interessanti però ...

Ai tempi in cui il Ministero dell'Ambiente della BC stava eseguendo le operazioni al di fuori delle coperture Arc / Info, avevano messo in atto un processo di sincronizzazione bidirezionale basato su rsync davvero interessante. Le coperture che erano sotto il controllo centrale venivano trasferite nelle regioni di notte e i dati regionali venivano reinseriti. Questo trasferimento differenziale a livello di blocco funzionava davvero bene, anche con oltre 56k collegamenti. Esistono processi simili per replicare i database degli attributi basati su Oracle, ma non credo che in genere abbiano funzionato troppo bene in dial-up :)

Il mio attuale posto di lavoro utilizza una soluzione ibrida simile. Ogni set di dati ha una sua copia autorevole (alcuni in Oracle, altri in MapInfo, altri in geodatabase personali) e questi sono cross-ETL di notte usando FME. C'è un po 'di spese generali piuttosto importanti qui quando si tratta di manutenzione; lo sforzo di creare qualsiasi nuovo set di dati e garantire che la visibilità dell'organizzazione sia notevolmente superiore a quanto dovrebbe essere. Stiamo elaborando una revisione intesa a trovare un modo per consolidare per evitare questo sovraccarico.

I metadati sono di gran lunga il problema più importante qui. Se i metadati rispondono a chi, quando, perché, dove è un record di metadati accettabile.

Avendo esperienza lavorativa in grandi aziende con solo pochi utenti GIS (circa 30), abbiamo avuto grossi problemi nel controllo dei dati, in particolare versioni e autorizzazioni. Un lato di questo può essere risolto con un'estesa documentazione dei dati (metadati) e gli altri problemi sono probabilmente risolti con un repository centrale, in cui PostGIS brilla.

GeoNetwork è un buon inizio per gestire i problemi relativi ai metadati. Risolvere il repository centrale è più complicato, perché potrebbe essere necessaria una persona specializzata per progettare / gestire il database.

Il problema complicato è chi sarà responsabile del QA / QC di questi set di dati e dei loro metadati. Sebbene i processi guidati dal computer funzionino alla grande, non possono essere rigorosi come un buon gestore di dati / detentore di dati, che è stato realizzato in questa azienda in cui ho lavorato. Ora c'è qualcuno esclusivamente lì per rivedere / eseguire il commit dei metadati e organizzare i dati geospaziali che non sono centralizzati in un DBMS.

Abbiamo utilizzato un file system organizzato gerarchicamente per: - estensione geografica (paese o continente) - fornitore di dati, licenziante - dominio / set di dati - data / versione

Successivamente abbiamo una politica per separare i dati di origine (nello stesso formato che era su qualunque CD / DVD che abbiamo ottenuto dal fornitore) da qualsiasi set di dati derivati ​​che abbiamo prodotto all'interno della nostra azienda.

Il file system semplifica l'immissione dei dati dal cliente e consente anche una certa flessibilità in termini di archiviazione fisica: manteniamo i nostri archivi su dischi più grandi e più lenti e disponiamo di file server speciali (collegati in modo trasparente nella gerarchia) per i set di dati utilizzati più frequentemente.

Per facilitare la gestione all'interno dei progetti, utilizziamo collegamenti simbolici. Manteniamo i nostri vettori in un database (Oracle) e rendiamo una regola avere almeno un'istanza di database per cliente (e diversi utenti / schemi per i progetti). Non abbiamo tenuto molti raster in un database, poiché tendono a occupare troppo spazio anche al di fuori di uno. Inoltre, ci piace mantenere le nostre istanze di database il più leggere possibile.

E sì, abbiamo qualcuno incaricato di "sorvegliare" l'intera cosa in modo che non diventi troppo disordinato.

Il problema più grande che abbiamo attualmente con questa configurazione è la mancanza di una bella interfaccia utente che ci aiuterebbe a avere una visione d'insieme migliore dell'intera cosa e abbiamo in programma di includere uno spazio di archiviazione dei metadati. Stiamo ancora considerando le nostre opzioni qui.

Stiamo usando il controllo della versione per il nostro codice e l'abbiamo usato per i documenti, ma risulta che il controllo della versione non è realmente realizzato per set di dati di grandi dimensioni, soprattutto se si tratta principalmente di file binari, quindi non consiglierei , tranne se hai a che fare con GML o qualcosa di simile a un testo (i problemi includono enormi spese generali sull'utilizzo del disco sul lato server e client che si arrestano in modo anomalo durante il check out di enormi repository).

Come ha detto @JasonBirch, il controllo della versione è un grosso problema.

Inoltre abbiamo scoperto che un flusso di lavoro appropriato è estremamente importante. Ad esempio, quando stiamo raccogliendo dati di campo, tendiamo a utilizzare database di gestione temporanea in cui è possibile eseguire il QA dei dati di campo prima di essere uniti nel set di dati principale. A seconda della quantità di dati che devono essere sottoposti al QA, ciò creerà comunque comunque delle spese generali.

Inoltre, se non l'hai visto, ti consiglio di dare un'occhiata all'ebook di geo-comunicazione e progettazione delle informazioni di Lars Brodersen, almeno per alcune delle sue affermazioni sulla modellazione dei dati.

Postgres come hanno già detto altri, tuttavia se vuoi mantenerlo portatile e facile da spostare, puoi sempre guardare usando SQLite + l'estensione Spatialite.

Non è così facile da usare come Postgres in termini di strumenti di gestione, ma QGis PU talk parlare direttamente con un database GIS abilitato alla spazialità senza problemi.

In realtà utilizzo SQLite + Spatialite per il backup, ho un servizio di Windows che viene eseguito in background (scritto su misura) che monitora la mia istanza PGSql e rispecchia i miei dati GIS in vari DB SQLite che risiedono su unità USB esterne.

Un altro consiglio anche con PG, usa gli schemi

Molte persone che conosco semplicemente lasciano tutto in "pubblico" e hanno finito con esso, ma se organizzi correttamente il tuo database fa la differenza.

Ad esempio, il mio database "Ordnance_Survey" ha schemi per VectormapDistrict VectormapLocal Topo50 LookupGrids CodePointWithPolygons CodePointOpen

dove conservo tutti i dati associati.

Nel frattempo le tabelle dei metadati, come le colonne della geometria ecc., Vivono tutte in pubblico, anche l'estensione Postgis è abilitata solo sullo schema pubblico, ma è accessibile da tutti gli altri schemi in uso.

Come menzionato nel post precedente, i DB spaziali e un server di metadati sono la solita installazione. Penso che una cosa fondamentale da ricordare sia che "una taglia non va bene per tutti". Ti ritroverai con i dati che si adattano meglio a Oracle, file server, server SQL, qualunque cosa. Ho provato a scarpare tutti i dati necessari in un'unica soluzione e di solito fallisce.

Aspettati di utilizzare diverse soluzioni che si adattino ai dati e pianifichino per loro. È qui che entra in gioco il Geo-portal (server dei metadati).

Devo concordare con "George" sopra che i metadati dovrebbero svolgere un ruolo importante nella gestione dei dati geospaziali. In realtà con qualsiasi dato digitale, i metadati sono la chiave: pensate a un fotografo che cerca di gestire i suoi file di foto digitali senza metadati adeguati. La vita diventa molto più semplice se tagghi le cose religiosamente e disponi di un buon software in grado di utilizzare i dati. Ora la domanda originale su "gestire i dati geospaziali" è piuttosto ampia: potrebbero essere formati di dati in cui archiviare, convenzioni di denominazione, gerarchia di set di dati e funzionalità, ruoli e privilegi di modifica, ecc. Ecc. Ecc.

Il modello di archiviazione per i dati geospaziali dipende da come si desidera interrogarli / cosa si desidera farne. Di seguito sono riportati alcuni strumenti che è possibile prendere in considerazione:

Postgres + PostGIS: supporta gli indici geospaziali e tutti i tipi di query che puoi immaginare. Per gestire i tuoi terabyte di dati dovrai applicare il sharding, l'ottimizzazione delle query, ecc. Se il tuo carico di scrittura è pesante, non lo consiglierei.

MongoDB: supporta grandi quantità di dati. Ottimo per archiviazione semplice, recupero e query geospaziali limitate.

Archiviazione dei file: se sei davvero solo un sistema di archiviazione e utilizzi solo una parte dei dati per l'interrogazione, potrebbe essere economico archiviare i tuoi dati come file. Il requisito di controllo della versione potrebbe essere soddisfatto.

Redis: è possibile combinare una qualsiasi delle opzioni precedenti con il supporto Redis Geo per archiviare in redis una piccola quantità di dati "caldi" a cui è necessario accedere frequentemente. Pensa a questo come alla tua cache.