OSMの新しいファイル形式GOB、PBFより30%小さくインポートは5倍高速

 (community.openstreetmap.org)
2 ポイント 投稿者 GN⁺ 2025-10-26 | 1件のコメント | WhatsAppで共有
  • 世界規模で膨大な OpenStreetMap(OSM) データセットを、より高速かつ効率的に扱うための新しいファイル形式 GOB(Geo-Object Bundle) が導入された
  • GOB は既存の Geo-Object Library(GOL) の圧縮版で、インデックスを削除してサイズを縮小し、処理速度を高めた形式
  • GOB ファイルは PBFより平均30%小さく、GOL の半分程度で、インポート速度は5倍高速
  • タイルベース構造により地域単位での抽出と結合が容易で、低スペックなシステムでも高速に読み込み可能
  • メタデータや編集履歴は含まれないが、配布・保管用形式として高い実用性を示す

GOB形式の概要

  • GOB は OpenStreetMap(OSM) データをより小さく、より高速に扱うための新しいファイル形式
    • 従来の GOL の半分のサイズで、PBF より平均 30%小さい
    • 大容量データ処理のために 圧縮およびタイルベース構造を採用している
  • GOB は GeoDesk Toolkit の一部として、オープンソースで提供される
    • GOL Tool 2.1 バージョンで GOB の保存(save)と読み込み(load)をサポート

性能と効率

  • GOB は既存フォーマットよりインポート速度が 5倍高速
    • PBF から GOL を構築するのにかかる時間と比べて大幅に短縮される
    • 最新のシステムでは 地球全体のデータを3分で読み込む
    • 32GB 以下のメモリでも効率的に動作し、旧型ノートPCでも1時間以内に処理可能
  • サイズ比較の例 (PBF → GOB):
    • Planet: 65.4GB → 46.0GB (-29.7%)
    • France: 4.54GB → 2.84GB (-36.3%)
    • Japan: 2.13GB → 1.34GB (-37.0%)
  • データが高密度であるほど圧縮効率は高く、ブラジル・中国などデータ密度の低い地域では約23%減にとどまる

構造と活用方法

  • GOB は タイル単位で構成されており、地図タイルレンダラーのズーム構造 (zoom 6~12) を模倣している
    • 地球全体のデータは約 6万個のタイルで構成される
    • 地域別データをファイルコピー並みの速度で抽出・結合できる
  • この構造により、地域別の保管、配布、部分更新が容易になる

制約事項

  • GOB は メタデータ (編集者名、タイムスタンプなど) と 編集履歴を含まない
    • 編集用途ではなく、配布およびアーカイブ用途に最適化されている
    • 最新データを維持するには、新しい GOB スナップショットを再生成する必要がある

使用方法

  • GOB は GOL Tool 2.1 以降で利用可能
    • gol save <gol-file> [<gob-file>] コマンドで GOL を GOB に変換
    • gol load <gol-file> [<gob-file>] コマンドで GOB を GOL に読み込む
  • --area オプションを使うと、GeoJSON、WKT、座標で 特定地域だけをエクスポート/読み込みできる
    • 例: 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

提供データセットと今後の計画

  • Open Planet Data では、毎日更新される 世界全体の GOB ファイル (50GB未満) を配布している
  • 開発者はさらなる改善を進めている:
    • zlib 以外の 圧縮アルゴリズムも実験中 (zstd では有意な改善なし)
    • 今後 gol load に URL から直接 GOB を読み込む機能を追加予定
    • これにより「ダウンロードと並行したバックグラウンドビルド」で、実質0分インポートの実現を目指す

関連記事

1件のコメント

 
GN⁺ 2025-10-26
Hacker Newsのコメント

  • 新しい GOBフォーマットの仕様が気になって調べてみた。まだ公式仕様はないが、詳細を扱った スレッド がある。
    OSMに限定されず、空間インデクシングをサポートする 高性能な空間データフォーマット は、アプリの使い勝手と生産性に大きく影響する。
    たとえば、QGISで大きなデータをKMZ（zip化されたXML）で保存すると数分間フリーズするが、同じデータを flatgeobuf で保存すると即座に読み込まれる。

    • KMZは ストリーミング不可 なので、全体をメモリに載せてからQGIS内部構造に変換しなければならないのが違いだと思う。
      複雑なKMZ/KMLは、ほかのGISアプリでもうまく読み込めなかった経験がある。
      同じデータを GeoJSON で書いた場合はどうなるのか気になる。
    • QGISでは、データを Postgres に載せて使うほうが、性能面ではるかに良いと感じた。

  • このフォーマットが新しい OSMデータモデル を使っているのか気になる。
    関連資料として、データモデル研究レポート、GitHubリポジトリ、公式ブログのフィードバック募集記事 がある。
    現在のモデルでは、座標をノード参照に変換する処理が遅く、RAMを大量に消費 するため厄介だ。

  • GIS関連で質問がある。LIDARポイントクラウド をメッシュ化する良い方法を探している。
    建物の壁面のように垂直に近い場所ではデータが疎で、ポイント法線もないため、PoissonやBall Pivot、MeshlabのVCGのような一般的な方法では 破綻した結果 になったり、遅すぎたりする。
    樹冠や軒のせいで、単純なheightmapアプローチにも限界がある。
    およそ900億個のポイントを3,000万〜5,000万個の三角形に減らしたいが、カスタムパイプラインを何か月も開発せずに解決したい。

    • 3DBAGプロジェクト を試してみる価値がある。オランダの1,100万棟の建物をLiDARと建物外形線から再構成したオープンソースプロジェクトだ。
      GitHubリポジトリ と 再構成パイプライン も公開されている。
    • Meshroom は今ではLIDARデータを入力として受け取れる。
      以前、フォトグラメトリやVFX向けのカメラトラッキングで使ったことがあるが、この種の作業に非常に 堅牢なオープンソースツールセット だった。

  • 私の考えでは、libosmium と GDAL が対応しない限り、このフォーマットは依然として周辺的な存在にとどまりそうだ。

    • だからといって、彼らに対応しない理由があるわけではない。
      まだ完成した仕様ですらない アイデア段階 なので、すべての新しいフォーマットは最初はこういう状況だ。

  • これが osmium と互換性があるのか気になる。

    • まだない。導入されたばかりのフォーマットで、正式な仕様すらない。