Ini adalah masalah yang jahat . Kami telah mencoba berbagai sistem, yang semuanya bekerja dengan tingkat yang berbeda-beda untuk suatu waktu, dan akhirnya tumbuh dengan susah payah dan mulai berantakan karena semakin banyak kasus tepi yang tidak pas ditemui. Yang mengatakan, masing-masing sistem yang kami gunakan jauh lebih baik daripada tidak sama sekali, membuktikan pepatah bahwa sistem apa pun lebih baik daripada tidak ada sistem.
Berikut ini gambaran umum praktik kami saat ini:
Masukkan semuanya kecuali raster ke dalam file geodatabase, semakin sedikit semakin baik. Jangan bersarang kelas fitur di bawah dataset fitur kecuali mereka terkait dalam beberapa cara (misalnya hidro> sungai, hidro> danau, hidro> lahan basah, dll.). Ini mengarah ke daftar panjang yang besar di bagian atas fgdb tetapi itu adalah kejahatan yang dapat diterima.
Buat file layer untuk semua kelas fitur dan atur sebagai gantinya, ini memberikan banyak kebebasan untuk memberi nama sesuai kebutuhan, menggunakan karakter yang tidak didukung, dll. *, Dan kemampuan untuk memindahkan dan mengganti nama ketika keadaan berubah. Ini juga memungkinkan duplikasi tanpa redundansi, misalnya satu set lapisan dikelompokkan berdasarkan skala nominal (50k, 250k ...), yang lain berdasarkan wilayah (AK, YT ...), yang ketiga berdasarkan tema (karibu, penggunaan lahan, transportasi ...), dan yang keempat oleh klien sementara datastore itu sendiri tidak berubah.
Untuk duplikat, gunakan pintasan alih-alih file layer itu sendiri, jika tidak, ada terlalu banyak hal untuk diperbarui ketika ada perubahan. Konfigurasikan ArcCatalog untuk menampilkan pintasan: * Alat> Opsi> tipe file: .lnk (Batasan: pratinjau & metadata tidak berfungsi, Anda tidak dapat mengikuti pintasan ke sumbernya di ArcCatalog. Ini dapat diperbaiki dengan menggunakan Symbolic Links, bukan pintasan. , lihat Tautan Ekstensi Shell )
* (tip: tambahkan folder Layers sebagai bilah alat Start Menu sehingga selalu ada di ujung jari Anda.)
Z: \ Layers \
Mendasarkan\
Tematik \
Referensi\
All Dressed Base (250k) .lyr
Batas Administrasi (1000k) .lyr
...
Z: \ Raster \
Landsat \
Orthos \
Z: \ Data \
Foo_50k.gdb
Foo_250k.gdb
NoScale.gdb
Komposisi dan keluaran peta (cetak file, pdf, ekspor, dll.) Yang pada dasarnya lebih dinamis dan variabel disimpan dan diatur secara berbeda di tempat lain. Ini adalah bagian yang lebih sulit bagi kami. Kami saat ini menggunakan drive khusus dengan folder yang dinamai sesuai dengan Job # (melakukannya lagi sebagai gantinya saya akan menggunakan date, '2010-10-26' ) dan sub folder untuk data dan hasil / hasil proyek tertentu. Indeks spreadsheet mencantumkan semua nomor pekerjaan (nama folder), judul peta dan klien yang sesuai. Ex:
W: \ Foo_0123 \
Foobarmap_001.mxd
Documents \
BacaMe.doc
Data\
buffers_2000m.shp
gps_tracks.csv
Keluaran\
Foobarmap_001.pdf
Kiriman
Menjaga indeks tetap terbaru adalah titik gesekan, orang tidak suka melakukannya, menghindarinya, dan tidak konsisten dengan penamaan dll. (Menggunakan database alih-alih spreadsheet akan membantu). Menggunakan konvensi nama folder numerik juga membuatnya sangat sulit untuk memetakan proyek X tanpa indeks, sumber gesekan penting lainnya. Idealnya indeks akan menjadi halaman html yang dapat diklik yang secara otomatis dihasilkan dari aplikasi db. Itu adalah proyek nother keseluruhan.
Prinsip-prinsip kunci:
- pisahkan barang-barang yang perlahan berubah dan sering digunakan kembali dari variabel dan dinamis, dan perlakukan secara berbeda
- Jangan menduplikasi secara tidak perlu, gunakan file layer dan pintasan / tautan jika memungkinkan.
- jangan terlalu sering mengubah sistem, cobalah masing-masing dengan solid.
Saya sangat menyambut contoh struktur lain, seperti yang saya katakan kami tidak puas dengan apa yang kami miliki. :)