OSM’nin yeni dosya biçimi GOB, PBF’den %30 daha küçük ve içe aktarma 5 kat daha hızlı

• Dünya çapında devasa OpenStreetMap (OSM) veri kümesini daha hızlı ve verimli işlemek için yeni dosya biçimi GOB (Geo-Object Bundle) kullanıma sunuldu
• GOB, mevcut Geo-Object Library (GOL) biçiminin sıkıştırılmış sürümü olup, indeksleri kaldırarak boyutu küçültür ve işlem hızını artırır
• GOB dosyaları PBF’den ortalama %30 daha küçük, GOL’ün ise yaklaşık yarısı boyutunda; içe aktarma hızı da 5 kat daha yüksek
• Karo tabanlı yapı sayesinde bölgesel çıkarma ve birleştirme kolaydır; düşük donanımlı sistemlerde bile hızlı yükleme mümkündür
• Meta veriler ve değişiklik geçmişi dahil değildir, ancak dağıtım ve arşivleme biçimi olarak yüksek kullanım değeri sunar

---

GOB biçimine genel bakış

• GOB, OpenStreetMap (OSM) verilerini daha küçük ve daha hızlı işlemek için tasarlanmış yeni bir dosya biçimidir
  • Mevcut GOL’ün yarısı kadar boyuta sahip, PBF’den ise ortalama %30 daha küçüktür
  • Büyük hacimli veri işleme için sıkıştırma ve karo tabanlı yapı kullanır
• GOB, GeoDesk Toolkit’in bir parçasıdır ve açık kaynak olarak sunulur
  • GOL Tool 2.1 sürümünde GOB kaydetme (save) ve yükleme (load) işlevleri desteklenir

Performans ve verimlilik

• GOB’un içe aktarma hızı mevcut biçimlere göre 5 kat daha hızlıdır
  • PBF’den GOL oluşturmak için gereken süreye kıyasla büyük ölçüde kısalır
  • Modern sistemlerde gezegenin tamamına ait veriler 3 dakikada yüklenebilir
  • 32 GB veya daha az bellekte de verimli çalışır; eski dizüstü bilgisayarlarda bile bir saat içinde işlenebilir
• Örnek boyut karşılaştırması (PBF → GOB):
  • Planet: 65.4GB → 46.0GB (-29.7%)
  • France: 4.54GB → 2.84GB (-36.3%)
  • Japan: 2.13GB → 1.34GB (-37.0%)
• Veri ne kadar yoğunsa sıkıştırma verimliliği o kadar yüksektir; Brezilya ve Çin gibi veri yoğunluğu düşük bölgelerde küçülme oranı yaklaşık %23 düzeyindedir

Yapı ve kullanım şekli

• GOB, karo birimleri halinde yapılandırılmıştır ve harita karo oluşturucularının yakınlaştırma yapısını (zoom 6~12) taklit eder
  • Gezegenin tamamına ait veri yaklaşık 60 bin karodan oluşur
  • Bölgesel veriler dosya kopyalama hızına yakın bir hızla çıkarılabilir ve birleştirilebilir
• Bu yapı sayesinde bölgesel saklama, dağıtım ve kısmi güncelleme kolaylaşır

Kısıtlamalar

• GOB, meta verileri (düzenleyici adı, zaman damgası vb.) ve değişiklik geçmişini içermez
  • Düzenleme amacıyla değil, dağıtım ve arşivleme amaçları için optimize edilmiştir
  • En güncel veriyi korumak için yeni bir GOB anlık görüntüsünün yeniden oluşturulması gerekir

Kullanım

• GOB, GOL Tool 2.1 ve sonrasında kullanılabilir
  • gol save <gol-file> [<gob-file>] komutuyla GOL, GOB’a dönüştürülür
  • gol load <gol-file> [<gob-file>] komutuyla GOB, GOL’e yüklenir
• --area seçeneği kullanılırsa GeoJSON, WKT veya koordinatlarla yalnızca belirli bir bölgeyi dışa aktarmak/yüklemek mümkündür
  • Örnek: gol save world bodensee -a 9.55,47.4,8.78,47.66,9.01,47.88,9.85,47.58,9.82,47.46

Sunulan veri kümeleri ve gelecek planları

• Open Planet Data, her gün güncellenen küresel GOB dosyalarını (50 GB’tan küçük) dağıtır
• Geliştirici ek iyileştirmeler üzerinde çalışıyor:
  • zlib dışındaki sıkıştırma algoritmalarını denemek (zstd anlamlı bir iyileşme sağlamadı)
  • Gelecekte gol load için URL’den doğrudan GOB yükleme özelliği eklemek
  • Böylece “indirmeyle eşzamanlı arka plan derleme” ile fiilen 0 dakikalık içe aktarma hedefine ulaşmak

[GN⁺]

Hacker News yorumu

• Yeni GOB formatının spesifikasyonunu merak edip baktım. Henüz resmi bir spesifikasyon yok ama ayrıntıları ele alan bir başlık var
  Bu sadece OSM ile sınırlı değil; mekânsal indekslemeyi destekleyen yüksek performanslı mekânsal veri formatları, uygulamaların kullanılabilirliği ve üretkenliği üzerinde büyük etki yaratıyor
  Örneğin, QGIS'te büyük veriyi KMZ (zipped XML) olarak kaydedince birkaç dakika takılıyor, ama aynı veri flatgeobuf olarak kaydedildiğinde anında yükleniyor

  • Fark muhtemelen KMZ'nin streaming desteklememesi; bu yüzden tüm veriyi belleğe alıp sonra QGIS'in iç yapısına dönüştürmek gerekiyor
    Karmaşık KMZ/KML dosyalarının diğer GIS uygulamalarında da düzgün yüklenmediğini yaşamıştım
    Aynı veriyi GeoJSON olarak yazınca nasıl davrandığını merak ediyorum
  • QGIS'te veriyi Postgres'e yükleyip kullanmanın performans açısından çok daha iyi olduğunu hissetmiştim

• Bu formatın yeni OSM veri modelini kullanıp kullanmadığını merak ediyorum
  İlgili kaynaklar olarak veri modeli araştırma raporu, GitHub deposu ve resmi blogdaki geri bildirim çağrısı yazısı var
  Mevcut modelde koordinatları düğüm referanslarına dönüştürme süreci yavaş ve çok fazla RAM tüketiyor, bu da işleri zorlaştırıyor

• GIS ile ilgili bir sorum var. LIDAR nokta bulutunu mesh'e dönüştürmenin iyi bir yolunu arıyorum
  Bina duvarları gibi düşeye yakın bölgelerde veri seyrek, ayrıca nokta normalleri de yok; bu yüzden Poisson, Ball Pivot ya da Meshlab'ın VCG'si gibi yaygın yöntemler dejenere sonuçlar üretiyor veya fazla yavaş kalıyor
  Ağaç tepeleri ya da saçaklar nedeniyle basit bir heightmap yaklaşımının da sınırları var
  Yaklaşık 90 milyar noktayı 30 milyon ila 50 milyon üçgene indirmek istiyorum ama aylarca özel bir pipeline geliştirmeden bunu çözmek istiyorum

  • 3DBAG projesi denenmeye değer olabilir. Hollanda'daki 11 milyon binayı LiDAR ve bina dış hatlarıyla yeniden oluşturan açık kaynaklı bir proje
    GitHub deposu ve yeniden oluşturma pipeline'ı da açık durumda
  • Meshroom artık LIDAR verisini girdi olarak alabiliyor
    Eskiden bunu fotogrametri ve VFX için kamera takibinde kullanmıştım; bu tür işler için çok sağlam bir açık kaynak araç setiydi

• Bana göre libosmium ve GDAL desteklemezse bu format yine de çevresel bir şey olarak kalacak

  • Ama bunun, onların desteklememesi için bir sebep olduğu anlamına gelmiyor
    Henüz tamamlanmış bir spesifikasyon bile olmayan, fikir aşamasındaki bir çalışma; tüm yeni formatlar başlangıçta böyle olur

• Bunun osmium ile uyumlu olup olmadığını merak ediyorum

  • Henüz değil. Daha yeni tanıtılan bir format, resmi spesifikasyonu bile yok