Questo è un problema malvagio . Abbiamo provato vari sistemi, che hanno funzionato tutti in misura diversa per un certo periodo, e alla fine sono cresciuti in modo ingombrante e hanno iniziato a crollare quando si incontrano altri casi limite che non si adattano perfettamente. Detto questo, ognuno dei sistemi che abbiamo usato è molto meglio di niente, dimostrando la massima che qualsiasi sistema è migliore di nessun sistema.
Ecco una panoramica in miniatura della nostra pratica attuale:
Metti tutto tranne i raster in un file geodatabase, meno è, meglio è. Non nidificare le classi di entità geografiche nei set di dati delle caratteristiche a meno che non siano correlate in qualche modo (ad es. Idro> torrenti, idro> laghi, idro> zone umide, ecc.). Questo porta a un lungo elenco in cima a fgdb ma è un male accettabile.
Crea file di livello per tutte le classi di caratteristiche e organizza invece ciò, offrendo così molta libertà di nominare secondo necessità, usando caratteri non supportati ecc. *, E la possibilità di spostarsi e rinominare quando le circostanze cambiano. Consente inoltre la duplicazione senza ridondanza, ad esempio un insieme di livelli raggruppati in base alla scala nominale (50k, 250k ...), un altro per regione (AK, YT ...), un terzo per tema (caribù, uso del suolo, trasporto ...) e un quarto per client mentre lo stesso archivio dati rimane invariato.
Per i duplicati usa le scorciatoie invece dei file dei layer stessi, altrimenti ci sono troppe cose da aggiornare quando le cose cambiano. Configura ArcCatalog per mostrare le scorciatoie: * Strumenti> Opzioni> tipi di file: .lnk (Limitazioni: anteprima e metadati non funzionano, non puoi seguire il collegamento alla sua fonte in ArcCatalog. Puoi rimediare usando i collegamenti simbolici invece delle scorciatoie , vedi Link Shell Extension )
* (suggerimento: aggiungi la cartella Livelli come barra degli strumenti del menu Start in modo che siano sempre a portata di mano.)
Z: \ \ Layers
Base\
Tematico\
Riferimento\
All Dressed Base (250k) .lyr
Confini amministrativi (1000k) .lyr
...
Z: \ Raster \
Landsat \
Orthos \
Z: \ Data \
Foo_50k.gdb
Foo_250k.gdb
NoScale.gdb
Composizioni e output delle mappe (file di stampa, pdf, esportazioni, ecc.) Che per natura sono più dinamici e variabili vengono archiviati e organizzati in modo diverso altrove. Questa è la parte che è stata più dura per noi. Al momento utilizziamo un'unità dedicata con cartelle denominate in base al Job # (facendo di nuovo utilizzerei invece la data, "2010-10-26" ) e le sottocartelle per dati specifici di progetto e risultati / deliberabili. Un indice del foglio di calcolo elenca tutti i numeri dei lavori (nome della cartella), i titoli delle mappe corrispondenti e il client. Ex:
W: \ Foo_0123 \
Foobarmap_001.mxd
Documenti \
ReadMe.doc
Dati\
buffers_2000m.shp
gps_tracks.csv
Produzione\
Foobarmap_001.pdf
Risultati finali
Mantenere aggiornato l'indice è un punto di attrito, alle persone non piace farlo, evitarlo e non sono coerenti con la denominazione ecc. (L'uso di un database invece del foglio di calcolo sarebbe di aiuto). L'uso di una convenzione di nome di una cartella numerica rende anche molto difficile la mappa per il progetto X senza l'indice, un'altra notevole fonte di attrito. Idealmente l'indice sarebbe una pagina html cliccabile che viene generata automaticamente da un'applicazione db. Questo è comunque un altro progetto.
Principi chiave:
- separare le cose che cambiano lentamente e spesso riutilizzate da quelle dinamiche e variabili e trattarle in modo diverso
- Non duplicare inutilmente, utilizzare file di livello e collegamenti / collegamenti ove possibile.
- non cambiare i sistemi troppo frequentemente, provalo a fondo.
Accolgo con grande favore esempi di altre strutture, poiché ho detto che non siamo contenti di ciò che abbiamo. :)