Che cos'è una buona tassonomia o convenzione di denominazione per file e cartelle contenenti dati GIS? [chiuso]

La mia azienda ha raccolto circa 30 TB di dati GIS negli ultimi 8 anni e mi trovo sempre a porre le seguenti domande:

1. Che tipo di dati disponiamo per una determinata area geografica?
2. Quali sono i dettagli di tali dati (ad es. Risoluzione in metri per pixel)?
3. Dove sono i dati sul disco rigido in modo che io possa effettivamente usarli?
4. Abbiamo già elaborato i dati o sono in una forma inalterata dalla fonte?

Fino ad ora compreso, ho tentato di rispondere a queste domande inventando una cartella e una tassonomia / gerarchia di file appropriate. Qualcuno ha idee / suggerimenti su alcuni modi comprensibili, forse anche standard di organizzare i dati GIS utilizzando file e cartelle?

Sono anche aperto a saperne di più su come l'utilizzo di un database potrebbe essere vantaggioso per la mia azienda; siamo sviluppatori di software, non esperti di GIS, quindi sospetto di essere un po 'indietro rispetto alla curva su come affrontare al meglio il problema della memorizzazione / organizzazione dei dati GIS per facilità d'uso. Ho visto la domanda Best practice per la gestione dei dati geospaziali, ma sono stato in grado di trarre un uso marginale dalle risposte solo perché non ho familiarità con i database geografici.

AGGIORNAMENTO: L'ultima settimana ho trascorso un bel po 'di tempo a leggere sui database GIS e ho iniziato a familiarizzare con PostGIS. A lungo termine, penso che finiremo per orientarci verso l'impiego di un database più un server di metadati come raccomandato da JasonBirch in Best practice per la gestione dei dati geospaziali .

Se stai effettivamente cercando di modificare i dati o sviluppare una mappa, dovrai tenere separati i dati su cui stai lavorando attivamente da quelli con cui hai iniziato. Quando avvio un progetto, creo una cartella SourceData, con sottodirectory denominate dal tipo di dati (DEM, Orthophoto, Hydrology, ecc.). Conterranno tutti i livelli che sto semplicemente usando come riferimento. Tutti i dati a cui sto lavorando verranno copiati in una cartella diversa denominata Working. La cartella di lavoro contiene dati, MXD e qualsiasi altra cosa che modifico o creo in sottodirectory che di solito sono correlate a una fase del progetto (MXD, RoadEdits, Delivery, ecc.)

Oltre ai dati GIS effettivi, è necessario creare una cartella Comunicazioni o Specifiche per contenere tutti i documenti del cliente / cliente interno / professore. Questo può servire come metadata quando torni al progetto in un secondo momento, oltre a creare una posizione centralizzata in cui chiunque può vedere cosa dovrebbe accadere.

Mi sembra che sia necessario un set di metadati per archiviare queste informazioni e un sistema di recupero che utilizza i metadati per consentire di estrarre i dati sulla base delle informazioni.

Penso che vorresti una soluzione che supportasse un servizio catalogo OGC, per la massima interoperabilità. Ho visto i colleghi usare Deegree , anche se ovviamente ci sono altre soluzioni da verificare.

Ecco un esempio di come abbiamo collegato Deegree al nostro software (la demo live è in manutenzione per il momento - non lo sapresti! - ma dovrebbe essere di nuovo la prossima settimana)

Per quanto riguarda la denominazione dei file, se si dispone di un servizio di catalogo e di un meccanismo di consegna, il problema riguarda la denominazione dei file e la loro posizione. Altrimenti penso che dipenda da come cerchi i dati. Per prima cosa restringi l'area geografica o il tipo di dati? Ciò determinerà se la gerarchia inizia dividendo i dati in riquadri, quindi i tipi di dati per riquadro; o suddividendolo in tipi di dati, ognuno dei quali ha una serie di riquadri.

Ovviamente con un database spaziale non si hanno gli stessi problemi riguardo alla divisione dei dati in riquadri, quindi questo è spesso un metodo preferenziale, a condizione che l'applicazione finale supporti l'applicazione usando quel tipo di dati.

Vorrei scegliere SpatiaLite che è un database a un file in cui è possibile inserire tutti i file di forma, i raster e le tabelle. Quindi, come database SQL relazionale, hai la potenza delle query SQL a tua disposizione per fare tutte le azioni necessarie (unire, selezionare, unire, unire, dividere ecc.) Tra attributi e file.

SpatiaLite è accessibile anche da linguaggi di programmazione come Python per un maggior grado di automazione. Il cielo è il limite.

Documentazione ed esercitazioni di SpatiaLite

Trovo utile creare documenti di Word dal titolo "Nome o tema della mappa - Commenti sui metadati.doc". Documentare le principali modifiche e flussi di lavoro in ordine cronologico (AAAA-MM-GG) per ogni tema di mappe e / o set di dati. Se è necessario capire la cronologia di un set di dati: i) Includere la data modificata / data di creazione dei file correlati che sono utili come riferimenti storici o potenziali file di origine. Includi un breve riepilogo del contenuto di ciascun file (nomi dei layer, numero di record) prestando attenzione a somiglianze o differenze generali (ovvero le novità di ciascuna versione di una mappa o set di dati). Conserva il file "- Commenti sui metadati" nella stessa cartella di lavoro della versione più recente della mappa o del set di dati. Inserisci le versioni precedenti della mappa o dei dati in una sottocartella Archivio. Il processo in tre fasi funziona bene per lo sviluppo del software, sviluppo del database e gestione dei file: 1) Sviluppo (e documento); 2) Test (e documento); 3) Pubblica (compresi i metadati). 1) Cartella di lavoro; 2) Sottocartella archivio; 3) Versione pubblicata.