Das ist ein böses Problem . Wir haben verschiedene Systeme ausprobiert, die alle eine Zeit lang in unterschiedlichem Maße funktionierten und schließlich unhandlich wurden und auseinanderzufallen begannen, als mehr und Randfälle auftraten, die nicht ganz passen. Trotzdem ist jedes der Systeme, die wir verwendet haben, weitaus besser als nichts und beweist die Maxime, dass jedes System besser ist als kein System.
Hier eine kleine Übersicht unserer aktuellen Praxis:
Fügen Sie alles außer Rastern in eine File-Geodatabase ein. Je weniger, desto besser. Verschachteln Sie Feature-Classes nicht unter Feature-Datasets, es sei denn, sie hängen in irgendeiner Weise zusammen (z. B. Flüsse, Seen, Feuchtgebiete usw.). Dies führt zu einer langen Liste an der Spitze der fgdb, aber das ist ein akzeptables Übel.
Erstellen Sie Ebenendateien für alle Feature-Classes und ordnen Sie diese so an, dass Sie bei Bedarf sehr frei benennen und nicht unterstützte Zeichen verwenden können. Es ermöglicht auch eine redundanzfreie Vervielfältigung, z. B. eine Gruppe von Ebenen, die nach Nominalskala (50.000, 250.000 ...) gruppiert sind, eine andere nach Region (AK, YT ...), eine dritte nach Thema (Karibus, Landnutzung, Transportwesen) ...) und ein viertes vom Client, während der Datenspeicher selbst unverändert bleibt.
Verwenden Sie für Duplikate Verknüpfungen anstelle der Ebenendateien selbst, da sonst zu viele Dinge aktualisiert werden müssen, wenn sich etwas ändert. Konfigurieren Sie ArcCatalog so, dass Verknüpfungen angezeigt werden: * Extras> Optionen> Dateitypen: .lnk (Einschränkungen: Vorschau und Metadaten funktionieren nicht. Sie können der Verknüpfung zu ihrer Quelle in ArcCatalog nicht folgen. Dies kann mithilfe von symbolischen Verknüpfungen anstelle von Verknüpfungen behoben werden (siehe Link Shell Extension )
* (Tipp: Fügen Sie den Ordner "Ebenen" als Symbolleiste für das Startmenü hinzu, damit Sie ihn immer zur Hand haben.)
Z: \ Ebenen \
Base\
Thematische \
Referenz\
Alle Dressed Base (250k) .lyr
Verwaltungsgrenzen (1000 KB) .lyr
...
Z: \ Raster \
Landsat \
Orthos \
Z: \ Daten \
Foo_50k.gdb
Foo_250k.gdb
NoScale.gdb
Kartenkompositionen und -ausgaben (Druckdateien, PDFs, Exporte usw.), die von Natur aus dynamischer und variabler sind, werden anderswo gespeichert und organisiert. Dies ist der Teil, der für uns schwieriger war. Derzeit verwenden wir ein dediziertes Laufwerk mit Ordnern, die nach Job-Nr. Benannt sind (wobei ich stattdessen das Datum "2010-10-26" verwenden würde ) und Unterordnern für projektspezifische Daten und Ergebnisse / Überlegungen. Ein Tabellenkalkulationsindex listet alle Auftragsnummern (Ordnernamen), die entsprechenden Kartentitel und den Client auf. Ex:
W: \ Foo_0123 \
Foobarmap_001.mxd
Dokumente \
ReadMe.doc
Daten\
buffers_2000m.shp
gps_tracks.csv
Ausgabe\
Foobarmap_001.pdf
Liefergegenstände
Der Index auf dem neuesten Stand zu halten, ist ein Problem, das die Leute nicht gerne tun, vermeiden und mit der Benennung usw. unvereinbar sind (die Verwendung einer Datenbank anstelle einer Tabellenkalkulation würde helfen). Die Verwendung einer numerischen Ordnernamenskonvention erschwert es außerdem sehr, die Zuordnung für Projekt X ohne den Index, eine weitere bemerkenswerte Reibungsquelle, vorzunehmen. Im Idealfall ist der Index eine anklickbare HTML-Seite, die automatisch aus einer Datenbankanwendung generiert wird. Das ist aber ein ganz anderes Projekt.
Grundprinzipien:
- Trennen Sie die sich langsam verändernden und oft wiederverwendeten Inhalte von den dynamischen und variablen und behandeln Sie sie unterschiedlich
- Duplizieren Sie nicht unnötigerweise, verwenden Sie nach Möglichkeit Ebenendateien und Verknüpfungen / Links.
- Wechseln Sie das System nicht zu häufig, probieren Sie es gründlich aus.
Ich begrüße Beispiele für andere Strukturen sehr, da ich sagte, dass wir mit dem, was wir haben, nicht zufrieden sind. :)