OpenStreetMap'te sürüm oluşturma ile nasıl başa çıkılır?

Jeo-uzamsal verilerin daha genel anlamda yönetilmesi konusu burada daha önce ortaya çıkmıştır . Sürüm oluşturma konusu da burada belirtildi, ancak gerçekten ele alınmadı.

Geleneksel jeo-uzamsal veri toplama ve bakımının, yalnızca kurum içinde güncellenmesi nedeniyle, yalnızca dahili olarak sürüm oluşturmayla ilgilenmesi gerekir. Bu, OpenStreetMap gibi kitle kaynaklı coğrafi veri tabanlarında geçerli değildir. Orada, herkes gelip nesneleri ekleyebilir, değiştirebilir veya silebilir. OpenStreetMap'te bu temel bir şekilde ele alınır: her nesnenin bir tamsayı sürüm numarası vardır ve yalnızca en yüksek sürüme sahip nesne canlı veritabanında gösterilir. Veritabanı iyimser kilitleme kullanır, bu nedenle kullanıcılar katkıları manuel olarak yüklerken oluşan tüm çakışmaları çözmelidir.

Editörler aracılığıyla ( JOSM , Potlatch ) insan katkısı tek katkı tarzı olduğu sürece, tüm bunlar makul derecede işe yarıyor . Giderek, açık kamu sektörü verilerinin ithalatı yapılmaktadır. Bunlar daha karmaşık sürüm oluşturma sorunları yaratır. Aşağıdaki senaryoyu düşünün:

1. Bir bina nesnesi açık bir kamu sektörü veri kümesinden içe aktarılıyor
2. Bina, insan katkıda bulunanlar tarafından bazı değişiklikler alır (özellikler, geometri veya her ikisi)
3. Kamu sektörü verilerinin yeni bir sürümü kullanıma sunuldu ve içe aktarıldı.

Şu anda, 3. adımda, topluluk değişiklikleri alan her bina yeni içe aktarma ile manuel olarak birleştirilmedikçe, insan katkıları kaybedilecektir.

OpenStreetMap bu durumla nasıl başa çıkabilir? Yazılım geliştirmede dağıtılmış sürüm kontrolüne bakmamız gerekiyor mu? DVC yöntemleri dağıtılmış uzamsal veri bakımı için nasıl uyarlanabilir?

CBS verileri için tahribatsız düzenleme yapan birisini hayal ettim. Yoğun hesaplama gerektirir, ancak RDBMS'de uygulanması zor olmamalıdır.

Verilerin anlık görüntüsü ile başlayın. Değişiklikler düzenleme olarak kaydedilir, orijinal veriler değişmeden kalır. Örneğinizde, binalar başlangıçta kamu sektörü verilerinden gelir. Bir kullanıcı düzenleme yaptığında, değişiklik veya fark ayrı bir tabloya kaydedilir. Birisi özelliği görüntülediğinde orijinalin yanı sıra uygulanan düzenlemeler de verilir. Sonraki düzenlemeler, yeni özellik şekli ile orijinal ve önceki tüm düzenlemeler arasındaki hesaplanan farktır.

Bu, hassas bir düzeyde geri alma yeteneği sağlar. Aslında sürüm kontrolü bunu yapar. Tahribatsız düzenlemeye iyi bir örnek Apple'ın Diyafram açıklığıdır. Diyaframdaki içe aktarılan dijital görüntüler doğrudan değiştirilmez. Seviyelerde, keskinlikte, bulanıklıkta vb. Değişiklikler düzenleme olarak saklanır ve bir görüntüyle çalışırken anında uygulanır. Herhangi bir değişiklik anında kaldırılabilir.

Tabii ki, üretim ortamlarında dağıtım ve kullanım için DB'nin anlık görüntülerini alırsınız. Bu sadece geliştirme ve düzenleme içindir.

Bir göz atın Sürüm PostGIS , pgVersion ve Facto mesaj fikirler ve olası çözümler için. Bunlar PostgreSQL veritabanlarında uygulanan sürüm kontrol sistemleridir.

OSM, veritabanının anlık görüntüsünü tutan Postgres ve Postgis kullanır.

Bunu kendi sunucunuza ve veritabanınıza uygulamak için

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

Veritabanı (plantet.osm) haftalık olarak güncellenmektedir http://wiki.openstreetmap.org/wiki/Planet_dump

Osmoz ,"veritabanından ve dosyadan okuma bileşenleri, veritabanına ve dosyaya yazma bileşenleri, değişiklik kümelerinin türetilmesi ve veri kaynaklarına uygulanması için bileşenler"

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

Changsets: http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#Changeset_Derivation_and_Birleştirme

Bu sorun olsa ve bir fikrim vardı, ama test etmedi. Çalışabilir:

Mercurial veya Git gibi sürüm kontrol sistemini kullanın. Mercurial daha kolay olacaktır, çünkü anonim dalların kolayca oluşturulmasına izin verir.

Şimdi, ilk revizyondan sonra, kamu veri seti ithalatı için bir şube başlatın. Yani, 2 şube olacak:

1. ana hat (OSM)
2. kamu veri kümesi X

Genel veri kümesinden bir içe aktarma, şube 2'de yapılmalı ve sonra OSM dalıyla birleştirilmelidir.

Senaryonuz şöyle olabilir:

• bir nesne yoktu
• sonra ithal ve şube 1 birleştirilir
• sonra geometri de dahil olmak üzere ana hatta değiştirilir
• şube 2'ye tekrar aktarıldı
• şube 1 ile birleştirildiğinde, şube 2'de güncellenen veriler şube 1'de güncellenir

Bu, VCS'nin ayrı özniteliklerdeki değişikliklerle kolayca başa çıkabilmesi için verilerin nesne başına bir tane ve muhtemelen json gibi bir biçime bölünmesini gerektirebilir.

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

Bir milyar dosyaya bilgi bölünmesinin herhangi bir sistem için çok fazla olduğunu biliyorum. Bunun yerine VCS'nin çekirdeği kullanılmalı ve OSM verileri işlenmeli ve sürümlenebilir bir biçimde VCS'ye aktarılmalıdır. (Veya bir dosya sistemi alay edilebilir).

Bunun işe yarayacağını garanti edemem.