Bu kötü bir sorundur . Hepsi bir dereceye kadar değişen derecelerde çalışan ve sonunda kararsız bir şekilde büyüyen ve ayrılmaya başlayan ve tam olarak uymayan son durumlarla karşılaşan çeşitli sistemleri denedik. Bu, kullandığımız sistemlerin her birinin hiç yoktan iyidir, herhangi bir sistemin hiçbir sistemden daha iyi olmadığını kanıtlar .
İşte şu andaki uygulamamıza genel bir bakış:
Rasterler dışındaki her şeyi bir dosya coğrafi veritabanına yerleştirin, ne kadar az olursa o kadar iyi. Özellik sınıflarını, belirli bir şekilde ilişkili olmadıkça (örn. Hidro> akışlar, hidro> göller, hidro> sulak alanlar vb.) Özellik veri kümelerinin altına yerleştirmeyin. Bu, fgdb'nin tepesinde büyük ve uzun bir listeye yol açıyor ancak bu kabul edilebilir bir kötülük.
Tüm özellik sınıfları için katman dosyaları oluşturun ve bunları düzenleyin; bunun yerine, desteklenmeyen karakterleri vb. * Kullanarak gereken şekilde adlandırma özgürlüğü ve koşullar değiştikçe hareket etme ve yeniden adlandırma yeteneği verir. Ayrıca artıklık olmadan çoğaltmaya da izin verir, örneğin nominal ölçeğe göre (50k, 250k ...) sınıflandırılmış bir katman seti, bir başka bölgeye göre (AK, YT ...), üçüncü bir temaya göre (karibu, arazi kullanımı, ulaşım) ...) ve müşteri tarafından dördüncü sırada, veri deposunun kendisi değişmeden kalır.
Çoğaltmalar için katman dosyalarının yerine kısayolları kullanın, aksi halde işler değiştiğinde güncellenecek çok fazla şey vardır. Kısayolları göstermek için ArcCatalog'u yapılandırın: * Araçlar> Seçenekler> dosya türleri: .lnk (Sınırlamalar: önizleme ve meta veriler çalışmıyor, ArcCatalog'daki kaynağının kısayolunu izleyemezsiniz. Bu, kısayollar yerine Sembolik Bağlantılar kullanılarak düzeltilebilir. , bkz. Bağlantı Kabuğu Uzantısı )
* (ipucu: Katmanlar klasörünü Başlat Menüsü araç çubuğu olarak ekleyin, böylece her zaman parmaklarınızın ucunda olurlar.)
Z: \ Katmanlar \
Baz \
Tematik \
Referans\
Tüm Giyimli Taban (250k) .lyr
Yönetim Sınırları (1000k) .lyr
...
Z: \ Raster \
Landsat \
Orthos \
Z: \ Data \
Foo_50k.gdb
Foo_250k.gdb
NoScale.gdb
Doğası gereği daha dinamik ve değişken olan harita kompozisyonları ve çıktıları (baskı dosyaları, pdf'ler, ihracatlar vb.) Başka bir yerde farklı depolanır ve düzenlenir. Bu bizim için daha zor olan kısım. Şu anda, İş #'a göre adlandırılmış klasörleri olan bir sürücü (tekrar kullanıyoruz, '2010-10-26' yerine tarih kullanırım ) ve projeye özgü veriler ve sonuçlar / tartışmalar için alt klasörler kullanıyoruz. Bir e-tablo dizini, tüm iş numaralarını (klasör adı), karşılık gelen harita başlıklarını ve istemciyi listeler. Ör:
B: \ Foo_0123 \
Foobarmap_001.mxd
Dokümanlar \
ReadMe.doc
Veri\
buffers_2000m.shp
gps_tracks.csv
Çıktı\
Foobarmap_001.pdf
Teslim
Dizini güncel tutmak bir sürtünme noktasıdır, insanlar bunu yapmaktan hoşlanmaz, bundan kaçınır ve isimlendirmeyle vb. Tutarsızdır (elektronik tablo yerine veritabanı kullanmak yardımcı olur). Sayısal bir klasör adı kuralı kullanmak, X kaygısı için haritaya, diğer bir önemli sürtünme kaynağı olan haritayı zorlaştırır. İdeal olarak, dizin otomatik olarak bir db uygulamasından oluşturulan tıklanabilir bir html sayfası olacaktır. Bu tamamen 'başka bir proje değil.
Anahtar ilkeler:
- yavaş değişen ve sıklıkla kullanılan şeyleri dinamik ve değişkenden ayırın ve farklı davranın
- Gereksiz yere kopyalamayın, mümkün olduğunca katman dosyaları ve kısayollar / bağlantılar kullanın.
- sistemleri çok sık değiştirmeyin, her birine sağlam bir deneme yapın.
Sahip olduklarımızdan memnun olmadığımızı söylediğim gibi, diğer yapıların örneklerini çok hoş geldiniz. :)