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