Apa taksonomi atau konvensi penamaan yang baik untuk file dan folder yang berisi data GIS? [Tutup]


13

Perusahaan saya telah mengumpulkan sekitar 30 TB data GIS selama 8 tahun terakhir, dan saya selalu mendapati diri saya mengajukan pertanyaan berikut:

  1. Jenis data apa yang kita miliki untuk area geografis tertentu?
  2. Apa rincian tentang data itu (misalnya, resolusi dalam meter per piksel)?
  3. Di mana data ada pada hard drive sehingga saya benar-benar dapat menggunakannya?
  4. Sudahkah kami memproses data, atau apakah itu dalam bentuk yang tidak diubah dari sumber?

Hingga dan termasuk sekarang, saya telah berusaha untuk menjawab pertanyaan-pertanyaan ini dengan menyusun folder dan file taksonomi / hierarki yang sesuai. Adakah yang punya ide / saran tentang beberapa cara yang dapat dimengerti, bahkan mungkin standar untuk mengatur data GIS menggunakan file dan folder?

Saya juga terbuka untuk mempelajari lebih lanjut tentang bagaimana menggunakan basis data mungkin menguntungkan perusahaan saya; kami adalah pengembang perangkat lunak, bukan pakar GIS, jadi saya curiga kami sedikit di belakang kurva tentang cara terbaik untuk mendekati masalah penyimpanan / pengorganisasian data GIS untuk kemudahan penggunaan. Saya memang melihat pertanyaan Praktik terbaik untuk mengelola data geospasial tetapi hanya mampu menarik penggunaan marjinal dari jawaban karena saya sangat tidak terbiasa dengan geodatabases.

UPDATE: Minggu terakhir ini saya menghabiskan cukup banyak waktu membaca tentang database GIS, dan mulai membiasakan diri dengan PostGIS. Jangka panjang, saya pikir kita akhirnya akan bergerak ke arah penggunaan database ditambah server metadata seperti yang direkomendasikan oleh JasonBirch dalam Praktik terbaik untuk mengelola data geospasial .



Terima kasih, pertanyaan itu pasti terkait dan memberikan beberapa info latar belakang yang bagus.
Sipp

Jawaban:


2

Jika Anda benar-benar mencoba mengedit data atau mengembangkan peta, Anda harus menjaga data yang Anda kerjakan secara terpisah dari data yang Anda mulai. Ketika saya memulai sebuah proyek, saya membuat folder SourceData, dengan subdirektori yang diberi nama berdasarkan tipe data (DEM, Orthophoto, Hydrology, dll.) Ini akan menampung semua lapisan yang hanya saya gunakan untuk referensi. Setiap data yang saya kerjakan akan disalin ke folder lain yang disebut Bekerja. Folder yang berfungsi menyimpan data, MXD, dan apa pun yang saya modifikasi atau buat di subdirektori yang biasanya berkorelasi dengan fase proyek (MXD, RoadEdits, Pengiriman, dll.)

Selain data GIS yang sebenarnya, Anda harus membuat folder Komunikasi atau Spesifikasi untuk menyimpan dokumen apa pun dari klien / klien internal / profesor. Ini dapat berfungsi sebagai metadata ketika Anda kembali ke proyek di kemudian hari, serta membuat lokasi terpusat di mana orang lain dapat melihat apa yang seharusnya terjadi.


1
Poin bagus; perusahaan kami membuat peta yang digunakan perangkat lunak kami, dan kami telah mengembangkan skema folder untuk memisahkan data "mentah" dari data "yang berfungsi" dari data "yang difinalisasi". Salah satu masalah adalah melacak set data mentah apa yang digunakan sebagai dasar asli untuk peta akhir; Sepertinya saran Anda untuk folder "Spesifikasi" akan membahasnya. Untuk setiap peta yang kita buat, kita pasti akan mencatat sumber data mentah apa yang digunakan dalam pembuatan peta (sesuatu yang saat ini tidak kita lakukan). Terima kasih atas tipsnya!
Sipp

1

Menurut saya, Anda memerlukan seperangkat metadata untuk menyimpan informasi ini, dan sistem pengambilan yang menggunakan metadata untuk memungkinkan Anda mengekstrak data berdasarkan informasi tersebut.

Saya pikir Anda menginginkan solusi yang mendukung Layanan Katalog OGC, untuk interoperabilitas maksimum. Saya telah melihat rekan kerja menggunakan Deegree - meskipun tentu saja ada solusi lain yang harus Anda periksa.

Berikut adalah contoh bagaimana kami mengikat Deegree ke dalam perangkat lunak kami (demo langsung sedang dalam perbaikan saat ini - tidakkah Anda tahu! - tetapi akan kembali lagi minggu depan)

Adapun penamaan file, jika Anda memiliki layanan katalog dan mekanisme pengiriman, maka ada sedikit masalah tentang apa nama file dan di mana mereka. Kalau tidak, saya pikir itu tergantung pada bagaimana Anda mencari data. Apakah Anda pertama kali memulai dengan mempersempit area geografis, atau tipe data? Itu akan menentukan apakah hierarki dimulai dengan memecah data menjadi ubin, lalu jenis data per ubin; atau dengan memecahnya menjadi tipe data, yang masing-masing memiliki satu set ubin.

Tentu saja dengan basis data spasial Anda tidak memiliki masalah yang sama tentang membagi data menjadi ubin, sehingga seringkali merupakan metode preferensial - menyediakan aplikasi penggunaan akhir mendukung menggunakan jenis data tersebut.


Terima kasih atas sarannya Mark. Tampaknya Anda menyarankan bahwa ada beberapa komponen yang berperan di sini: metadata itu sendiri (misalnya, file XML), sistem pengambilan (Deegree?) Yang tahu bagaimana menemukan data berdasarkan permintaan metadata tertentu dari pengguna, dan komponen penyimpanan backend (misalnya, PostGIS?) yang menyimpan data dan metadata. Apakah itu akurat?
Sipp

1

Saya akan memilih SpatiaLite yang merupakan database satu-file di mana Anda dapat memasukkan semua shapefile, raster, dan tabel Anda. Kemudian sebagai database SQL relasional, Anda memiliki kekuatan kueri SQL yang Anda inginkan untuk melakukan semua tindakan yang diperlukan (bergabung, pilih, gabungkan, persatukan, pisahkan dll) antara atribut dan file.

SpatiaLite juga dapat diakses dari bahasa pemrograman seperti Python untuk otomatisasi tingkat yang lebih besar. Langit adalah batasnya.

Dokumentasi dan tutorial SpatiaLite


0

Saya merasa berguna untuk membuat dokumen Word berjudul "Nama atau tema peta - Metadata comments.doc". Dokumentasikan pengeditan dan alur kerja utama dalam urutan kronologis (YYYY-MM-DD) untuk setiap peta dan / atau tema kumpulan data. Jika Anda perlu mencari tahu sejarah kumpulan data: i) Sertakan tanggal yang dimodifikasi / tanggal yang dibuat dari file terkait yang berguna sebagai referensi historis atau file sumber potensial. Sertakan ringkasan singkat dari konten setiap file (nama layer, # catatan) sambil memperhatikan persamaan atau perbedaan umum (yaitu apa yang baru di setiap versi peta atau kumpulan data). Simpan file "- Komentar metadata" di folder yang berfungsi sama dengan versi terbaru dari set peta atau data. Tempatkan versi peta atau data yang lebih lama di dalam sub-folder Arsip. Tiga langkah proses bekerja dengan baik untuk pengembangan perangkat lunak, pengembangan basis data dan manajemen file: 1) Kembangkan (& dokumen); 2) Uji (& dokumen); 3) Publikasikan (termasuk metadata). 1) Folder yang berfungsi; 2) Arsipkan sub-folder; 3) Versi yang diterbitkan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.