- Untuk menangani dataset OpenStreetMap (OSM) yang sangat besar di seluruh dunia dengan lebih cepat dan efisien, diperkenalkan format file baru GOB (Geo-Object Bundle)
- GOB adalah versi terkompresi dari Geo-Object Library (GOL) yang sudah ada, dengan indeks dihapus untuk mengurangi ukuran dan meningkatkan kecepatan pemrosesan
- File GOB rata-rata 30% lebih kecil daripada PBF, sekitar setengah ukuran GOL, dan kecepatan impornya 5x lebih cepat
- Dengan struktur berbasis tile, ekstraksi dan penggabungan per wilayah menjadi mudah, serta memungkinkan pemuatan cepat bahkan pada sistem berspesifikasi rendah
- Meskipun tidak menyertakan metadata dan riwayat perubahan, format ini menunjukkan utilitas tinggi untuk distribusi dan arsip
Gambaran umum format GOB
- GOB adalah format file baru untuk menangani data OpenStreetMap (OSM) dengan ukuran lebih kecil dan lebih cepat
- Ukurannya setengah dari GOL yang ada, dan rata-rata 30% lebih kecil daripada PBF
- Mengadopsi kompresi dan struktur berbasis tile untuk pemrosesan data skala besar
- GOB merupakan bagian dari GeoDesk Toolkit dan tersedia sebagai open source
- Versi
GOL Tool 2.1 mendukung fungsi menyimpan (save) dan memuat (load) GOB
Performa dan efisiensi
- GOB memiliki kecepatan impor 5x lebih cepat dibanding format yang ada
- Waktu yang dibutuhkan jauh lebih singkat dibanding membangun GOL dari PBF
- Pada sistem modern, seluruh data planet dapat dimuat dalam 3 menit
- Bekerja efisien bahkan dengan memori di bawah 32GB, sehingga dapat diproses dalam waktu kurang dari satu jam pada laptop lama
- Contoh perbandingan ukuran (PBF → GOB):
- Planet: 65.4GB → 46.0GB (-29.7%)
- France: 4.54GB → 2.84GB (-36.3%)
- Japan: 2.13GB → 1.34GB (-37.0%)
- Semakin padat datanya, semakin tinggi efisiensi kompresinya; wilayah dengan kepadatan data rendah seperti Brasil dan China mengalami pengurangan sekitar 23%
Struktur dan cara pemanfaatan
- GOB disusun dalam unit tile, meniru struktur zoom (zoom 6~12) dari renderer tile peta
- Seluruh data planet terdiri dari sekitar 60 ribu tile
- Data per wilayah dapat diekstrak dan digabungkan dengan kecepatan setara penyalinan file
- Berkat struktur ini, penyimpanan per wilayah, distribusi, dan pembaruan parsial menjadi lebih mudah
Keterbatasan
- GOB tidak menyertakan metadata (nama editor, timestamp, dll.) maupun riwayat perubahan
- Dioptimalkan untuk tujuan distribusi dan arsip, bukan untuk penyuntingan
- Untuk mempertahankan data terbaru, snapshot GOB baru harus dibuat ulang
Cara penggunaan
- GOB dapat digunakan pada
GOL Tool 2.1 atau lebih baru
- Konversi GOL ke GOB dengan perintah
gol save <gol-file> [<gob-file>]
- Muat GOB ke GOL dengan perintah
gol load <gol-file> [<gob-file>]
- Dengan opsi
--area, pengguna dapat mengekspor/memuat hanya wilayah tertentu melalui GeoJSON, WKT, atau koordinat
- Contoh:
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
Dataset yang tersedia dan rencana ke depan
- Open Planet Data mendistribusikan file GOB global yang diperbarui setiap hari (di bawah 50GB)
- Pengembang sedang melanjutkan perbaikan tambahan:
- Bereksperimen dengan algoritme kompresi selain zlib (zstd tidak menunjukkan peningkatan berarti)
- Ke depannya,
gol load direncanakan menambahkan kemampuan memuat GOB langsung dari URL
- Melalui ini, mereka menargetkan impor efektif 0 menit dengan “background build sambil mengunduh”
1 komentar
Komentar Hacker News
Saya penasaran dengan spesifikasi format GOB yang baru, jadi saya mencarinya. Belum ada spesifikasi resmi, tetapi ada thread yang membahas detailnya
Bukan hanya terbatas pada OSM, format data spasial berkinerja tinggi yang mendukung pengindeksan spasial sangat memengaruhi kegunaan dan produktivitas aplikasi
Misalnya, jika data besar disimpan sebagai KMZ (XML terkompresi) di QGIS, aplikasi bisa macet selama beberapa menit, tetapi data yang sama jika disimpan sebagai flatgeobuf akan dimuat seketika
Saya juga pernah mengalami KMZ/KML yang kompleks sulit dimuat dengan baik di aplikasi GIS lain
Saya penasaran bagaimana hasilnya jika data yang sama ditulis sebagai GeoJSON
Saya penasaran apakah format ini menggunakan model data OSM yang baru
Sebagai referensi, ada laporan studi model data, repositori GitHub, dan postingan blog resmi yang meminta masukan
Pada model saat ini, proses mengubah koordinat menjadi referensi node lambat dan banyak menghabiskan RAM, sehingga merepotkan
Saya punya pertanyaan terkait GIS. Saya sedang mencari cara yang bagus untuk mengubah point cloud LIDAR menjadi mesh
Area yang mendekati vertikal seperti dinding bangunan memiliki data yang jarang, dan juga tidak ada normal point, sehingga metode umum seperti Poisson, Ball Pivot, atau VCG milik Meshlab menghasilkan hasil yang terdegradasi atau terlalu lambat
Kanopi pepohonan atau tepian atap juga membuat pendekatan heightmap sederhana punya keterbatasan
Saya ingin mengurangi sekitar 90 miliar titik menjadi 30 juta~50 juta segitiga, tetapi ingin menyelesaikannya tanpa harus mengembangkan pipeline kustom selama berbulan-bulan
Repositori GitHub dan pipeline rekonstruksi-nya juga tersedia secara publik
Dulu saya memakainya untuk photogrammetry dan camera tracking untuk VFX, dan itu adalah toolset open source yang sangat solid untuk pekerjaan seperti ini
Menurut saya, jika libosmium dan GDAL tidak mendukungnya, format ini kemungkinan akan tetap menjadi sesuatu yang pinggiran
Ini masih dalam tahap ide dan bahkan belum ada spesifikasi yang matang, jadi semua format baru awalnya memang berada di situasi seperti ini
Saya penasaran apakah ini kompatibel dengan osmium