Bagaimana cara berurusan dengan versi di OpenStreetMap?

Topik pengelolaan data geospasial dalam pengertian yang lebih umum telah dibahas sebelumnya di sini. Topik versi disebutkan di sana juga, tetapi tidak benar-benar ditangani.

Pengumpulan dan pemeliharaan data geospasial tradisional hanya perlu berurusan dengan versi secara internal, karena database hanya diperbarui dari dalam organisasi. Ini tidak terjadi di geodatabase crowdsourced seperti OpenStreetMap. Di sana, siapa saja dapat datang dan menambahkan, memodifikasi atau menghapus objek. Dalam OpenStreetMap ini ditangani dengan cara yang belum sempurna: setiap objek memiliki nomor versi integer, dan hanya objek dengan versi tertinggi yang diekspos dalam database langsung. Basis data menggunakan penguncian optimis, sehingga pengguna harus menyelesaikan semua konflik yang terjadi saat mengunggah kontribusi secara manual.

Ini semua berfungsi dengan baik selama kontribusi manusia melalui editor ( JOSM , Potlatch ) adalah satu-satunya mode kontribusi - tetapi mereka tidak. Semakin banyak, impor data sektor publik terbuka dilakukan. Ini membuat masalah pembuatan versi yang lebih kompleks. Pertimbangkan skenario berikut:

1. Objek bangunan sedang diimpor dari dataset sektor publik yang terbuka
2. Bangunan menerima beberapa modifikasi oleh kontributor manusia (atribut, geometri, atau keduanya)
3. Versi baru dari data sektor publik tersedia dan diimpor.

Saat ini, dalam langkah 3. kontribusi manusia akan hilang, kecuali setiap bangunan yang menerima modifikasi komunitas secara manual digabungkan dengan impor baru.

Bagaimana OpenStreetMap dapat menangani situasi ini? Apakah kita perlu melihat kontrol versi terdistribusi dalam pengembangan perangkat lunak? Bagaimana metode DVC dapat diadaptasi untuk menangani pemeliharaan data spasial terdistribusi?

Saya memimpikan seseorang yang menerapkan pengeditan non-destruktif untuk data GIS. Ini komputasi intensif tetapi seharusnya tidak sulit diimplementasikan dalam RDBMS.

Mulai dengan snapshot data. Setiap perubahan disimpan sebagai hasil edit, data asli tetap tidak berubah. Dalam contoh Anda, bangunan awalnya berasal dari data sektor publik. Saat pengguna mengedit, perubahan atau perbedaan disimpan dalam tabel terpisah. Ketika seseorang melihat fitur tersebut, mereka diberikan yang asli plus setiap pengeditan yang diterapkan. Pengeditan berikutnya adalah perbedaan yang dihitung antara bentuk fitur baru dan asli plus semua pengeditan sebelumnya.

Ini memberi Anda kemampuan untuk membatalkan pada tingkat yang halus. Pada dasarnya apa yang kontrol versi lakukan. Contoh bagus dari pengeditan non-destruktif adalah Aperture Apple. Gambar digital yang diimpor di Aperture tidak dimodifikasi secara langsung. Perubahan level, penajaman, keburaman, dll. Disimpan sebagai pengeditan dan diterapkan saat Anda bekerja dengan gambar. Perubahan apa pun dapat langsung dihapus.

Tentu saja, Anda akan mengambil snapshot dari DB untuk distribusi dan digunakan dalam lingkungan produksi. Ini hanya untuk pengembangan dan pengeditan.

Lihatlah Versioning PostGIS , pgVersion , dan Post Facto untuk ide dan solusi yang mungkin. Ini adalah sistem kontrol versi yang diterapkan dalam database PostgreSQL.

OSM menggunakan Postgres dan Postgis yang menyimpan snapshot dari database.

Untuk mengimplementasikan ini di server dan database Anda sendiri

http://wiki.openstreetmap.org/wiki/Databases#Choice_of_DBMS

Database (plantet.osm) diperbarui setiap minggu http://wiki.openstreetmap.org/wiki/Planet_dump

Osmosis digunakan untuk"Ini memiliki komponen untuk membaca dari database dan dari file, komponen untuk menulis ke database dan untuk file, komponen untuk menurunkan dan menerapkan set perubahan ke sumber data"

http://wiki.openstreetmap.org/wiki/Osmosis

Changsets: http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#Changeset_Derivation_and_Merging

Saya memikirkan masalah ini dan punya ide, tetapi tidak mengujinya. Mungkin berhasil:

Gunakan sistem kontrol versi seperti Mercurial atau Git. Mercurial akan lebih mudah, karena memungkinkan untuk dengan mudah membuat cabang anonim.

Sekarang, dari revisi awal, mulailah cabang untuk impor dataset publik. Jadi, akan ada 2 cabang:

1. arus utama (OSM)
2. dataset publik X

Impor dari dataset publik harus dilakukan di cabang 2, kemudian digabung ke cabang OSM.

Skenario Anda mungkin berfungsi seperti ini:

• sebuah objek tidak ada
• kemudian diimpor dan digabung menjadi cabang 1
• kemudian dimodifikasi di jalur utama, termasuk geometri
• itu diimpor lagi di cabang 2
• ketika digabung menjadi cabang 1, hanya data yang diperbarui di cabang 2 yang diperbarui di cabang 1

Ini mungkin memerlukan pemisahan data menjadi beberapa file, satu per objek dan mungkin ke dalam format seperti json, sehingga VCS dapat dengan mudah menangani perubahan pada atribut yang terpisah.

{
     id: 1357
     lat: 1,
     lon: 2,
     tags: {
          'building': 'entrance'
     }
     type: 'node',
}
{
     nodes: [
         1357,
         2468
     ],
     tags: {
         building: 'yes',
     }
     type: 'way',
}

Saya tahu bahwa membagi informasi dalam satu miliar file terlalu banyak untuk sistem apa pun. Sebaliknya inti dari VCS harus digunakan dan data OSM harus diproses dan dimasukkan ke dalam VCS dalam bentuk versi. (Atau sistem file dapat diejek).

Saya tidak dapat menjamin ini akan berhasil.