Organisation und Ordnung von mehreren Layerkopien? [geschlossen]

In den Tagen, als ich an der Universität war, hatte ich ein Problem mit der "Organisation und Ordnung" - ich war unorganisiert und hielt meine Ebenen in verschiedenen Ordnern ohne eindeutige Namen und hatte daher mehrere Kopien jeder Ebene.

Seit ich arbeite, habe ich mich sehr verbessert - ich behalte spezielle Ordner mit speziellen Unterordnern. Ich benenne meine Layer nach einem System, mit dem ich etwas ordentlicher vorgehen kann, aber da ich immer noch mehrere Kopien von Layern verwalten muss (Da Autocad und ArcGIS ihre Unterschiede im Umgang mit nicht-lateinischen Sprachen haben, muss ich eine Kopie behalten Ich würde gerne von Ihren Erfahrungen hören und vielleicht ein paar Tipps von Ihnen lernen:

1. Wie organisieren Sie Ihre Ebenen? Wie nennt man sie? Nach Name, Datum, Inhalt, Kunde?
2. Wie organisieren Sie mehrere Kopien oder wie gehen Sie mit ihnen um (genauer: wie aktualisieren Sie mehrere Kopien gleichzeitig)?

Hinweis: Ich spreche vom Analysten / DBA POV und nicht vom POV eines Webentwicklers / Webmanagers (ich spreche davon, die Ebenen für mich selbst und möglicherweise zwei weitere GIS-Mitarbeiter zu organisieren, nicht mehr).

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. :)

Wenn andere Personen auf die Daten in Ihrem System zugreifen, können Sie das Organisationsschema nicht nur für sich selbst aussagekräftig machen. Sie müssen die Verwendung des Systems im Auge behalten. Wenn Sie sie nicht berücksichtigen, verbringen Sie viel Zeit mit der Beantwortung von Fragen wie "Wo sind die Landnutzungsdaten?" Und "Warum kann ich den [Datensatz hier einfügen] nicht finden?"

Bei der jahrelangen Pflege eines solchen Systems stellte ich fest, dass Menschen keine Daten finden können, wenn sie zuerst nach Quelle geordnet sind, z . B. c:\CensusBureau\Roadsund c:\ESRI\Countries. Stattdessen empfehle ich, die Daten zuerst thematisch und dann nach Quelle aufzulisten, falls Sie mehrere Quellen haben, z . B. c:\Roads\CensusBureauund c:\Roads\LocalGovt.

Ebenso würde ich keine Raster und Vektoren in verschiedene Verzeichnisse aufteilen. Es kann jedoch erforderlich sein, sie auf verschiedene physische oder logische Laufwerke aufzuteilen, wenn Sie viele Rasterdaten haben, die nicht auf ein Laufwerk passen.

Ich empfehle folgende Verzeichnisstruktur. Thema \ QuelleJahr, wobei Thema die thematische Ebene ist, Quelle ein abgekürzter Name für die Datenquelle ist und Jahr das Jahr ist, das die Daten vor Ort darstellen. In diesem Szenario befinden sich TIGER Roads vom Census Bureau in \Roads\Census00und \Roads\Census10(oder ersetzen "Census" durch "TIGER").

Beachten Sie, dass bestimmte Erweiterungen in ArcGIS nicht mit Dateinamen funktionieren, die länger als 13 Zeichen sind. Ich kann mich nicht erinnern, welche Erweiterung ich gewählt habe. Ich erinnere mich nur, dass dies ein Problem war.

Wir arbeiten auf Projektebene für CAD-Dateien. Es hängt davon ab, wie Ihr bestimmter Arbeitsablauf eingerichtet ist. Wir lassen unser Master-Arbeitsprojekt am Ende der Editiersitzung zusätzliche Datenspeicher daraus in einem Exportskript vorbereiten.

datadir \ cad \ cadastre.dgn
datadir \ srv \ fuel.dgn
datadir \ srv \
sewerage.dgn datadir \ map \ base.dgn
datadir \ map \ printsets.dgn
...

Dann hat jede Datei Ebenen / Ebenen / Merkmale, die mit einem Bezeichner "
sewPipe
sewManhole
sewPit
..." benannt sind.

Anschließend exportieren wir alles in SQL Spatial, anstatt unsere Arbeitsprojektdateien zu lesen, wo es dem Benutzer über Mapguide oder eine beliebige andere GIS-App angezeigt wird.

Die GIS-Ebenen sind nach Funktionsnamen mit Bezeichnern und ähnlichem Ordnerlayout sortiert, um das Sortieren zu ermöglichen.