Organizacja i porządek wielu kopii warstw? [Zamknięte]

W czasach, gdy byłem na uniwersytecie, miałem problem z „organizacją i porządkiem” - byłem niezorganizowany i trzymałem swoje warstwy w różnych folderach bez odrębnych nazw, a zatem miałem wiele kopii każdej warstwy.

Odkąd zacząłem pracować, wiele się poprawiłem - przechowuję specjalne foldery ze specjalnymi podfolderami. Nazywam swoje warstwy zgodnie z systemem, który pozwala mi być trochę bardziej schludnym, ale ponieważ wciąż muszę zarządzać wieloma kopiami warstw (ponieważ Autocad i ArcGIS mają różnice w kontaktach z językami innymi niż łacińskie, muszę zachować kopię dostosowany do każdego programu), chciałbym usłyszeć o twoich doświadczeniach i być może nauczyć się od ciebie kilku wskazówek:

1. Jak organizujesz swoje warstwy? Jak je nazwać? Według nazwiska, daty, treści, klienta?
2. Jak organizujesz lub radzisz sobie z wieloma kopiami (dokładniej: w jaki sposób aktualizujesz kilka kopii jednocześnie)?

Uwaga: rozmawiam z analityka / DBA POV, a nie z POV programisty / webmagera (mówię o organizowaniu warstw dla siebie i być może dwóch innych pracowników GIS, nie więcej).

To zły problem . Wypróbowaliśmy różne systemy, z których wszystkie działały przez pewien czas w różnym stopniu, i ostatecznie nie wyrosły i zaczęły się rozpadać, gdy napotyka się coraz więcej przypadków, które nie do końca pasują. To powiedziawszy, każdy z używanych przez nas systemów jest znacznie lepszy niż nic, co dowodzi, że każdy system jest lepszy niż żaden system.

Oto przegląd naszej obecnej praktyki:

Umieść wszystko oprócz rastrów w geobazie pliku, im mniej, tym lepiej. Nie zagnieżdżaj klas obiektów w zestawach danych obiektów, chyba że są one w jakiś sposób powiązane (np. Hydro> strumienie, hydro> jeziora, hydro> mokradła itp.). To prowadzi do dużej, długiej listy na górze FGDB, ale jest to akceptowalne zło.

Twórz pliki warstw dla wszystkich klas elementów i organizuj je, co daje dużą swobodę nazywania w razie potrzeby przy użyciu nieobsługiwanych znaków itp. *, A także możliwość przenoszenia i zmiany nazwy w miarę zmiany okoliczności. Umożliwia także powielanie bez redundancji, na przykład jeden zestaw warstw pogrupowanych według skali nominalnej (50 tys., 250 tys.), Inny według regionu (AK, YT ...), trzeci według tematu (karibu, użytkowanie gruntów, transport ...) i czwarty przez klienta, podczas gdy sam magazyn danych pozostaje niezmieniony.

W przypadku duplikatów użyj skrótów zamiast samych plików warstw, w przeciwnym razie istnieje zbyt wiele rzeczy do zaktualizowania, gdy coś się zmieni. Skonfiguruj ArcCatalog, aby wyświetlał skróty: * Narzędzia> Opcje> typy plików: .lnk (Ograniczenia: podgląd i metadane nie działają, nie można podążać za skrótem do jego źródła w ArcCatalog. Można to naprawić za pomocą dowiązań symbolicznych zamiast skrótów , patrz Link Shell Extension )

* (wskazówka: dodaj folder Warstwy jako pasek narzędzi Menu Start, aby zawsze znajdowały się na wyciągnięcie ręki).

Z: \ Layers \
          Baza\
          Tematyczny\
          Odniesienie\
          All Dressed Base (250k) .lyr
          Granice administracyjne (1000k) .lyr
          ...
Z: \ Raster \
          Landsat \
          Orthos \
Z: \ Data \
        Foo_50k.gdb
        Foo_250k.gdb
        NoScale.gdb

Kompozycje i wyniki map (pliki drukowane, pliki PDF, eksport itp.), Które z natury są bardziej dynamiczne, a zmienne są przechowywane i organizowane w inny sposób w innym miejscu. Ta część była dla nas trudniejsza. Obecnie używamy dedykowanego dysku z folderami o nazwach zgodnych z Zadaniem nr (robiąc to ponownie, zamiast tego użyłbym daty „2010-10-26” ) i podfolderami dla danych specyficznych dla projektu i wyników / celów. Indeks arkusza kalkulacyjnego zawiera wszystkie numery zadań (nazwy folderów), odpowiadające im tytuły map i klientów. Dawny:

W: \ Foo_0123 \
            Foobarmap_001.mxd
            Dokumenty \
                 ReadMe.doc
            Dane\
                 buffers_2000m.shp
                 gps_tracks.csv
            Wydajność\
                   Foobarmap_001.pdf
            Produkty

Utrzymywanie indeksu na bieżąco jest punktem krytycznym, ludzie nie lubią tego robić, unikają go i są niespójni z nazywaniem nazw itp. (Pomocne byłoby użycie bazy danych zamiast arkusza kalkulacyjnego). Użycie numerycznej konwencji nazw folderów bardzo utrudnia mapowanie projektu X bez indeksu, innego znaczącego źródła tarcia. Najlepiej byłoby, gdyby indeks był klikalną stroną HTML, która jest automatycznie generowana z aplikacji db. To jednak cały inny projekt.

Kluczowe zasady:

• oddzielić powoli zmieniające się i często ponownie używane rzeczy od dynamicznego i zmiennego i traktować je inaczej
• Nie powielaj niepotrzebnie, w miarę możliwości używaj plików warstw i skrótów / linków.
• nie zmieniaj systemów zbyt często, daj każdemu solidną szansę.

Z wielkim zadowoleniem przyjmuję przykłady innych struktur, ponieważ powiedziałem, że nie jesteśmy zadowoleni z tego, co mamy. :)

Jeśli inne osoby będą miały dostęp do danych w twoim systemie, nie możesz uczynić schematu organizacji znaczącym tylko dla siebie; musisz pamiętać o korzystaniu z systemu. Jeśli ich nie rozważysz, poświęcisz dużo czasu na odpowiadanie na pytania takie jak „gdzie są dane dotyczące użytkowania gruntów” i „dlaczego nie mogę znaleźć [wstawić tutaj zestaw danych]?”

W utrzymywaniu takiego systemu przez wiele lat, stwierdziliśmy, że ludzie nie mogą znaleźć dane, jeżeli jest to pierwszy organizowany przez źródła, np c:\CensusBureau\Roadsa c:\ESRI\Countries. Zamiast tego, polecam notować dane tematycznie, potem przez źródła w przypadku posiadania wielu źródeł, np c:\Roads\CensusBureaui c:\Roads\LocalGovt.

Podobnie nie podzieliłbym rastrów i wektorów na różne katalogi. Może być jednak konieczne podzielenie ich na różne dyski fizyczne lub logiczne, jeśli masz dużo danych rastrowych, które nie zmieściłyby się na jednym dysku.

Polecam następującą strukturę katalogów. Theme \ Source Rok, w którym Theme jest warstwą tematyczną, Source to skrócona nazwa źródła danych, a Year to rok, w którym dane reprezentują w terenie. W tym scenariuszu, tygrys Drogi z Census Bureau będzie znajdować się w \Roads\Census00i \Roads\Census10(lub zastąpić „Census” z „Tiger”).

Pamiętaj, że niektóre rozszerzenia w ArcGIS nie działają z nazwami plików dłuższymi niż 13 znaków. Nie pamiętam, które rozszerzenie, po prostu pamiętam, że to problem.

Pracujemy na poziomie projektu dla plików cad, sądzę, że to zależy od tego, jak skonfigurowany jest konkretny przepływ pracy, mamy nasz główny projekt roboczy, a następnie przygotowujemy z niego dodatkowe magazyny danych w skrypcie eksportowym na koniec sesji edycyjnej.

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

następnie każdy plik ma poziomy / warstwy / cechy o nazwie z identyfikacją
sewPipe
sewManhole
sewPit
...

Następnie eksportujemy wszystko do przestrzeni SQL zamiast odczytywać nasze działające pliki projektów, w których są wyświetlane użytkownikowi za pomocą Mapguide lub innej wymaganej aplikacji GIS.

Warstwy GIS są sortowane według nazwy obiektu z identyfikatorami i podobnym układem folderów, aby umożliwić sortowanie.