Menerapkan sistem kontrol versi untuk data geospasial? [Tutup]

Bukan berarti saya sangat membutuhkan jawaban yang tepat di sini, tetapi saya belakangan melihat beberapa upaya untuk memperkenalkan konsep "sistem kontrol versi" yang didistribusikan "untuk data geografis. Beberapa contoh (yang saya tahu) adalah tiga whitepaper dari OpenGeo ( 1 , 2 & 3 ) dan proyek " Geosynkronisering (geosyncronization)" oleh vendor Perangkat Lunak GIS Norwegia dan Badan Pemetaan Norwegia. Saya juga menemukan versi terdistribusi dari data geospasial? , yang menyebutkan GeoGit (oleh OpenGeo), dan Menerapkan kontrol versi ke model ArcGIS ModelBuilder? tentang kontrol versi di ArcGIS.

Menjadi seorang pengembang, saya tahu (setidaknya cukup untuk dapat menggunakannya) bagaimana sistem kontrol versi untuk kode sumber (seperti SVN dan Git) bekerja, dan latar belakang saya dalam geomatika memberi tahu saya bahwa ada beberapa tantangan unik dengan data geografis yang membuat Pendekatan tidak sepenuhnya mirip dengan cara kode sumber (yang pada dasarnya adalah teks) ditangani.

Apa tantangannya ketika berhadapan dengan (d) VCS untuk data geografis, bagaimana Anda akan mengatasinya, apakah kami membutuhkannya dan apakah ada upaya lain untuk menyelesaikan masalah ini daripada yang telah saya sebutkan?

Saya tahu bahwa whitepaper OpenGeo akan menjawab beberapa pertanyaan saya, tetapi apa yang saya cari sebenarnya adalah jawaban yang lebih "pedagogis", dengan gaya "beri tahu saya saya berumur 10 tahun", sehingga Saya bisa merujuk orang ke penjelasan yang bagus tentang tantangan dan solusi yang dibawa oleh data geografis.

Saya berharap bahwa seseorang dengan wawasan akan mengambil waktu untuk memberikan beberapa pemikiran tentang masalah ini, karena saya katakan saya saat ini tidak mencari untuk memecahkan masalah tertentu, tetapi topik ini adalah salah satu yang menarik minat saya.

Kami saat ini sedang mengerjakan desain ulang lengkap geodatastore kami. Saya harus mengatakan bahwa evolusi mereka membutuhkan lebih dari 20 tahun hingga sekarang. Kami mengidentifikasi fitur utama berikut dalam manajemen data geospasial:

• pengeditan simultan
• izin untuk membaca atau menulis bagian dari data
• pembaruan terbaru saat menjalankan layanan yang mengandalkan data (Transaksi dan paradigma ACID)
• skema internal dan eksternal (memodifikasi skema internal seharusnya tidak mempengaruhi layanan)
• kemampuan untuk menyimpan dan mengakses sejumlah besar data (terabyte raster dan hundrets gigabytes data vektor)
• konsistensi data antara lapisan yang berbeda (setiap paket milik sebuah kabupaten dan sebagainya)

Kami mengevaluasi pendekatan berikut ini, inilah yang dapat saya katakan tentang mereka:

1. ESRI Enterprise Geodatabase(ArcGIS 10.1); hampir sama dengan apa yang kita miliki sebelumnya (SDE), tetapi dengan penggunaan luas fitur versi untuk menangani transaksi. Tapi itu benar-benar bukan Enterprise Geodatabase, menurut saya SDE hanya bekerja di workgroup sebagai server geodata, di mana orang-orang bekerja dari jam 8 pagi sampai 8 malam, dan Anda bisa membuatnya offline lalu untuk tugas pemeliharaan, komitmen transaksi (versi mendamaikan dan memposting dalam pidato ESRI), replikasi, dll ... Jika Anda membangun layanan di atas data ini, Anda harus menangani database pementasan (di mana pekerjaan dilakukan) sebuah database produksi yang direplikasi. Ini hampir sama seperti build / test dan deploy dalam pemrograman. Meskipun paket kaya fitur yang ESRI berikan cukup bagus, namun tidak memiliki fleksibilitas (perubahan skema, atau tugas pemeliharaan saat orang-orang bekerja, pembuatan indeks misalnya).

2. File Rata dan Sistem Kontrol Versikami memilih Git (Tidak tahu bahwa sudah ada GeoGit). Oh ya, beberapa teman saya dan saya sendiri juga berasal dari rekayasa perangkat lunak. Itu semua bisa sangat sederhana. Saya pikir itulah masalahnya: Ini seperti montir mobil yang membangun mobil. Akan mudah untuk merawatnya, tetapi juga akan mengganggu untuk dikendarai dan sangat jelek untuk melihatnya dengan pasti. Saya pikir itu juga memiliki beberapa kelemahan utama: Bagaimana cara mengontrol versi 2 TeraByte (atau bahkan lebih, biner) Rasterdataset? Dan dalam Format apa? Data vektor dapat dengan mudah dikontrol versi jika Anda menggunakan format berbasis teks (misalnya GML), tetapi juga sulit untuk bekerja dengan satu miliar baris dataset. Saya masih tidak yakin apakah kita bisa melakukan manajemen izin pengguna yang efektif, karena tidak semua orang boleh mengedit atau bahkan melihat semuanya. Dan bagaimana Anda menggabungkan dataset vektor yang telah diedit secara intensif oleh 4 pengguna secara bersamaan? Setidaknya Anda harus menjadi ilmuwan / programmer komputer nyata untuk melakukan semua ini secara efektif ... pengguna GIS kami adalah perencana, surveyour, geolog, dan sebagainya. Ini hanyalah masalah bagi mereka untuk memikirkan garis keturunan versi seperti yang dilakukan oleh programmer, atau menggunakan cara bercabang sebagaimana mestinya. Namun demikian, memikirkan datastore sebagai repo bersama adalah ide yang menarik.

3. Basis data dengan tabel datar sebagai wadah sederhana. Sama seperti SDE melakukannya, tetapi tanpa hal-hal SDE. Masih sulit dipertahankan, karena Anda sebenarnya tidak memanfaatkan kelebihan yang ditawarkan RDBMS kepada Anda. Ya itu sangat sederhana untuk hanya memuat semuanya dalam database, tapi itu bukan manajemen data sama sekali.

4. Bigdata dan NoSQL . Masalah yang sama seperti file datar dan tabel datar. Menurut pendapat saya API sistem file sederhana untuk digunakan di web. Ya itu bekerja dengan baik di web, dan ya itu mudah untuk hanya membuang dokumen Anda, tapi saya pikir jika saya ingin menyelesaikan analisis data spasial pada terabyte data (mungkin raster), saya ingin agar tidak serialisasi dan deserialized melalui antarmuka HTTP.

UPDATE 2018: Ada banyak hal baru yang menciptakan banyak momentum. Untuk beberapa nama:

• Penyimpanan blok cloud dan HDFS
• Stack Python / rupawan / Dask

• Apache Spark

  • GeoMesa / GeoWave untuk data Vektor
  • GeoTrellis untuk data raster

• dan banyak lagi

  5. Pemodelan basis data klasik yang komprehensif(dengan RDBMS). Masalah utama adalah, bahwa sulit untuk hanya membuang data di mana saja dan berharap itu sesuai dengan setiap kebutuhan di masa depan. Tetapi jika Anda menaruh sejumlah waktu untuk menentukan datamodel yang kuat (OSM juga melakukan ini sebenarnya) dalam database, Anda dapat menggunakan semua keuntungannya. Kami dapat mengedit dan memperbarui data dalam transaksi terdistribusi, kami juga dapat memodifikasi skema inti mereka, sementara layanan masih mengandalkan skema eksternal dari data yang sama, kami dapat mempertahankannya, kami dapat memeriksa konsistensinya, kami dapat mengizinkan dan menolak izin, kami mampu menyimpan data dalam jumlah yang sangat besar sementara kita masih dapat mengaksesnya dengan cepat, kita dapat membangun data historis dan memicunya secara transparan dan sebagainya. Karena kami menggunakan server sql, kami masih kekurangan tipe raster asli, tetapi vendor database lain sudah menawarkan ini.

Yah saya pikir model basis data relasional baru saja bangkit di dunia spasial dengan tipe data spasial dalam beberapa tahun terakhir (sebelum itu di mana BLOB Containers) dan masih merupakan bentuk penyimpanan data yang paling fleksibel dan profesional. Itu tidak berarti bahwa itu tidak harus dilengkapi dengan pendekatan VCS atau NoSQL tetapi saya melihat pendekatan ini lebih mungkin sebagai bentuk distribusi data dalam kelompok pengguna daripada sebagai bentuk manajemen data spasial terpusat profesional. OSM juga telah memusatkan banyak tugas, yang tidak dapat disediakan oleh kerumunan, seperti mengimpor data dalam jumlah besar (sebagian besar data OSM di Austria diimpor dalam satu hari, bukan crowdsourced) dan pembuatan ubin. Bagian kolaborasi (pencarian sumber) memang sangat penting, tetapi hanya setengah dari bisnis.

Saya pikir saya harus mengulangi banyak hal ini dan memberikan lebih banyak fakta. Pertanyaan seperti ini sulit dijawab secara komprehensif dalam beberapa jam, saya akan mencoba meningkatkan kualitas jawaban saya di hari-hari berikutnya