Mengelola sejumlah besar data geospasial? [Tutup]

Bagaimana Anda mengelola data geospasial Anda? Saya memiliki terabyte data yang tersebar di ratusan kumpulan data, dan memiliki solusi ad-hoc menggunakan tautan simbolis dalam proyek yang menautkan kembali ke direktori arsip berbasis nama domain untuk setiap dataset. Ini bekerja sebagian besar, tetapi memiliki masalah sendiri.

Saya juga ingin mendengar jika ada yang mengelola data geospasial mereka dalam sistem kontrol revisi; Saat ini saya menggunakan satu untuk kode saya dan dataset kecil, tetapi tidak untuk dataset lengkap.

Saya pikir stock / jawaban yang jelas akan menggunakan database spasial (PostGIS, Oracle, SDE, MSSQL Spatial, dll) dalam hubungannya dengan server metadata seperti GeoPortal esri atau aplikasi open source GeoNetwork, dan secara keseluruhan saya pikir ini umumnya solusi terbaik. Namun, Anda cenderung selalu membutuhkan snapshot / cabang / tag berbasis proyek. Beberapa basis data yang lebih canggih memiliki cara mengelola ini, tetapi umumnya tidak semua mudah digunakan / dikelola pengguna.

Untuk hal-hal yang Anda simpan di luar basis data (gambar besar, file berbasis proyek) saya pikir kuncinya adalah memiliki konvensi penamaan yang konsisten dan sekali lagi registri metadata (bahkan sesuatu yang berteknologi rendah seperti spreadsheet) yang memungkinkan Anda untuk melacaknya dan memastikan bahwa mereka dikelola dengan baik. Misalnya, dalam kasus file berbasis proyek ini dapat berarti menghapusnya ketika catatan kebijakan manajemen menentukan, atau menggulungnya ke dalam repositori pusat pada penyelesaian proyek.

Saya telah melihat beberapa solusi menarik ...

Kembali ketika Kementerian Lingkungan Hidup BC menjalankan hal-hal dari cakupan Arc / Info, mereka memiliki proses sinkronisasi dua arah berbasis rsync yang benar-benar keren. Cakupan yang berada di bawah kendali pusat didorong ke daerah setiap malam, dan data regional didorong kembali. Transfer diferensial tingkat blok ini bekerja dengan sangat baik, bahkan di lebih dari 56 ribu tautan. Ada proses serupa untuk mereplikasi database atribut berbasis Oracle, tapi saya rasa mereka tidak melakukannya dengan baik melalui dial-up :)

Tempat kerja saya saat ini menggunakan solusi hybrid serupa. Setiap dataset memiliki salinan otoritatif (sebagian di Oracle, yang lain di MapInfo, yang lain di basis data pribadi) dan ini adalah lintas-ETL setiap malam menggunakan FME. Ada beberapa overhead yang cukup besar di sini dalam hal pemeliharaan; upaya untuk membuat set data baru dan memastikan visibilitas organisasi jauh lebih tinggi dari yang seharusnya. Kami sedang dalam proses peninjauan yang dimaksudkan untuk menemukan cara konsolidasi untuk menghindari overhead ini.

Metadata sejauh ini merupakan masalah terpenting di sini. Jika metadata menjawab siapa, kapan, mengapa, di mana itu adalah catatan metadata yang dapat diterima.

Memiliki pengalaman kerja di perusahaan besar dengan hanya beberapa pengguna GIS (sekitar 30) kami memiliki masalah besar untuk mengontrol data, khususnya versi dan izin. Satu sisi dari ini dapat diselesaikan dengan pendokumentasian data yang luas (metadata) dan masalah lainnya kemungkinan besar diselesaikan dengan repositori pusat, di mana PostGIS bersinar.

GeoNetwork adalah awal yang baik untuk menangani masalah metadata. Memecahkan repositori sentral lebih rumit, karena mungkin diperlukan orang khusus untuk mendesain / memelihara database.

Masalah yang rumit adalah siapa yang akan bertanggung jawab atas QA / QC set data ini dan metadata mereka. Meskipun proses yang digerakkan oleh komputer bekerja dengan sangat baik, mereka tidak dapat seketat manajer data / penyimpan data yang baik, yang dibuat di perusahaan tempat saya bekerja. Sekarang ada seseorang secara eksklusif di sana untuk meninjau / melakukan metadata dan mengatur data geospasial yang tidak terpusat dalam DBMS.

Kami telah menggunakan sistem file yang diatur secara hierarkis oleh: - luas geografis (negara atau benua) - penyedia data, pemberi lisensi - domain / dataset - tanggal / versi

Setelah itu kami memiliki kebijakan untuk memisahkan data sumber (dalam format yang sama dengan CD / DVD apa pun yang kami dapatkan dari penyedia) dari setiap set data turunan yang kami hasilkan di perusahaan kami.

Sistem file membuatnya sangat mudah untuk menelan data apa pun dari pelanggan dan juga memungkinkan fleksibilitas dalam hal penyimpanan fisik - kami menyimpan arsip kami pada disk yang lebih besar, lebih lambat dan kami memiliki server file khusus (secara transparan dihubungkan ke hierarki) untuk dataset lebih sering digunakan.

Untuk memfasilitasi manajemen dalam proyek, kami menggunakan tautan simbolis. Kami menyimpan vektor-vektor kami dalam database (Oracle) dan kami membuat aturan untuk memiliki setidaknya satu instance database per pelanggan (dan beberapa pengguna / skema untuk proyek-proyek). Kami belum menyimpan banyak raster dalam database, karena mereka cenderung mengambil terlalu banyak ruang bahkan di luar satu. Kami juga ingin membuat instance basis data kami seringan mungkin.

Dan ya, kami memiliki seseorang yang bertanggung jawab untuk 'menjaga' semuanya agar tidak berantakan.

Masalah terbesar yang kami miliki dengan pengaturan ini saat ini adalah tidak adanya antarmuka pengguna yang bagus yang akan membantu kami memiliki gambaran umum yang lebih baik tentang semuanya, dan kami telah merencanakan untuk menyertakan penyimpanan metadata di atas semua itu. Kami masih mempertimbangkan opsi kami di sini.

Kami menggunakan kontrol versi untuk kode kami dan kami telah menggunakannya untuk dokumen, tetapi ternyata kontrol versi tidak benar-benar dibuat untuk kumpulan data besar, terutama jika kebanyakan file biner, jadi saya tidak akan merekomendasikan itu , kecuali jika Anda berurusan dengan GML atau sesuatu yang mirip teks (masalah termasuk overhead besar pada penggunaan disk sisi server serta klien macet ketika memeriksa repositori besar).

Seperti @JasonBirch katakan, kontrol versi adalah masalah besar.

Kami juga menemukan bahwa alur kerja yang tepat sangat penting. Misalnya saat kami mengumpulkan data lapangan, kami cenderung menggunakan basis data staging di mana data lapangan bisa QA sebelum digabungkan ke dalam master dataset. Tergantung pada berapa banyak data yang perlu QA, ini akan selalu membuat beberapa overhead.

Juga, jika Anda belum melihatnya saya sarankan untuk melihat Geo-komunikasi dan desain informasi ebook oleh Lars Brodersen, setidaknya untuk beberapa apa yang dia katakan tentang pemodelan data.

Postgres seperti yang dikatakan orang lain, namun jika Anda ingin tetap portabel dan mudah dipindah, maka Anda selalu dapat melihat menggunakan SQLite + ekstensi Spatialite.

Tidak semudah menggunakan Postgres dalam hal alat manajemen, tetapi QGis BISA berbicara langsung ke Database GIS yang diaktifkan secara spasial tanpa masalah.

Saya benar-benar menggunakan SQLite + Spatialite untuk cadangan, saya memiliki layanan windows yang berjalan di latar belakang (Custom tertulis) yang memonitor instance PGSql saya, dan mirror GIS Data saya ke berbagai SQLite DB's yang berada pada drive USB eksternal.

Satu tip lagi dengan PG juga, gunakan skema

Banyak orang yang saya kenal hanya membuang semuanya di "publik" dan selesai dengan itu, tetapi jika Anda mengatur database Anda dengan benar itu membuat dunia berbeda.

Misalnya, database "Ordnance_Survey" saya memiliki skema untuk VectormapDistrict VectormapLocal Topo50 LookupGrids CodePointWithPolygons CodePointOpen

tempat saya menyimpan semua data yang terkait.

Sementara itu tabel metadata, seperti kolom geometri dll, semua hanya tinggal di Publik, ekstensi Postgis juga hanya diaktifkan pada skema publik, tetapi dapat diakses dari semua skema lain yang digunakan.

Seperti yang disebutkan pada posting sebelumnya, DB spasial dan server metadata adalah pengaturan yang biasa. Saya pikir satu hal penting untuk diingat adalah bahwa 'satu ukuran tidak cocok untuk semua'. Anda akan berakhir dengan data yang paling cocok di Oracle, server file, server SQL, apa pun. Saya sudah mencoba mengubah semua kebutuhan data menjadi satu solusi dan biasanya gagal.

Berharap untuk menggunakan solusi yang berbeda yang sesuai dengan data dan rencanakan untuk mereka. Di sinilah Geo-portal (server metadata) benar-benar masuk.

Saya harus setuju dengan 'George' di atas bahwa metadata harus memainkan peran besar dalam mengelola data geospasial. Sungguh dengan data digital apa pun, metadata adalah kunci - pikirkan seorang fotografer yang mencoba mengelola file foto digitalnya tanpa metadata yang tepat. Hidup jadi jauh lebih mudah jika Anda menandai hal-hal secara religius, dan memiliki perangkat lunak yang baik yang dapat memanfaatkan data. Sekarang pertanyaan awal tentang 'kelola data geospasial' cukup luas - ini bisa berupa format data untuk disimpan, penamaan konvensi, hierarki kumpulan data dan fitur, peran pengeditan dan hak istimewa, dll. Dll. Dll.

Pola penyimpanan untuk data geospasial tergantung pada bagaimana Anda ingin menanyakannya / apa yang ingin Anda lakukan dengannya. Berikut ini beberapa alat yang dapat Anda pertimbangkan:

Postgres + PostGIS: Mendukung indeks geospasial dan segala macam pertanyaan yang dapat Anda bayangkan. Untuk mengelola terabyte data Anda, Anda perlu menerapkan sharding, optimisasi kueri, dll. Jika beban penulisan Anda berat maka saya tidak akan merekomendasikan ini.

MongoDB: Ini mendukung sejumlah besar data. Sangat cocok untuk penyimpanan sederhana, pengambilan, dan permintaan geospasial yang terbatas.

Penyimpanan file: Jika Anda benar-benar hanya sebuah sistem kearsipan dan hanya menggunakan beberapa bagian dari data untuk query, mungkin akan lebih ekonomis untuk menyimpan data Anda sebagai file. Persyaratan kontrol versi Anda mungkin cukup puas dengan ini.

Redis: Anda dapat menggabungkan salah satu opsi di atas dengan dukungan Redis Geo untuk menyimpan sejumlah kecil data 'panas' dalam redis yang perlu sering Anda akses. Anggap ini sebagai cache Anda.