コンピュータビジョンで実現したOpenStreetMapの地図機能

 (blog.mozilla.ai)
3 ポイント 投稿者 GN⁺ 2025-03-24 | 2件のコメント | WhatsAppで共有
  • Mozilla.aiはOpenStreetMapのデータと衛星画像を結び付けて地図オブジェクトを見つけ、人間が検証したうえで再び貢献するOpenStreetMap AI Helper Blueprintを公開した
  • この方式ではLLM/VLMの代わりに、YOLOv11による物体検出とSAM2によるセグメンテーションを分離し、それぞれ位置特定とポリゴン輪郭の生成を担当させる
  • プールのマッピング例では、leisure=swimming_poolタグとMapboxタイルを使って学習データを作成し、結果をHugging Face Hubにアップロードする流れを示している
  • 推論プロセスでは、関心地点の周辺タイルを結合したあと既存のOpenStreetMapオブジェクトと比較し、重複候補を除外して新規候補だけを人間が確認する
  • 完全な手作業では1分あたりプール2〜3件程度だが、このBlueprintでは最適化されていないUXでも10〜15件まで処理でき、約5倍高速である

AIマッピングにOpenStreetMapデータを使う理由

  • Mozilla.aiは、オープンな協働コミュニティにおいてAIが反復的で遅い作業を減らせると考え、OpenStreetMap AI Helper Blueprintを公開した
  • 目標はAIがマッパーを置き換えることではなく、対象の発見やポリゴン描画にかかる時間を減らしつつ、最終段階として人間による検証を維持することにある
    • 人間が引き続き担うべき中核作業は、生成された地図データが実際に正しいかを確認する工程である
  • OpenStreetMapは、道路、遊歩道、カフェ、鉄道駅のようなデータをマッパーコミュニティが作成・維持するオープンな編集型地図である
  • OpenStreetMapは最も充実したオープン地図データベースの1つであり、衛星画像のような他のソースと組み合わせることでAIモデルの学習データとして活用できる

LLMではなく軽量なコンピュータビジョンモデルを選択

  • OpenStreetMapの多くのMap Featuresは、ポリゴン形状の領域として表現される
  • 人間がポリゴンを見つけて手で描く作業は時間がかかるが、十分なデータがあればコンピュータビジョンモデルをこの作業向けに学習させられる
  • Blueprintでは最新の非LLMモデルを2段階に分けて使用する
    • 物体検出: UltralyticsのYOLOv11が画像内で関連する地図機能の位置を見つける
    • セグメンテーション: MetaのSAM2が検出されたオブジェクトの正確な形状を輪郭として精緻化する
  • YOLOv11とSAM2は軽量かつ高速で、ローカル実行に適している
    • 2つのモデルを合わせた重みは250MB未満である
    • 比較対象として挙げられたSmolVLMは4.5GBである

Blueprintの3段階フロー

  • 1段階: OpenStreetMapから物体検出データセットを作る

    • OpenStreetMapデータを取得して衛星画像と組み合わせ、学習向けの形式に変換する
    • そのまま実行できるCreate Dataset Colabが提供されている
    • OpenStreetMapデータ収集には2つのAPIが使われる
      • Nominatim API: ユーザーが関心領域を柔軟に選べるようにする
      • Overpass API: 選択した領域内で特定のタグに該当するポリゴンをダウンロードする
    • プールの例では、学習にGalicia、検証にViana do Casteloを使用する
    • 対象タグはleisure=swimming_poolで、location=indoorが付いた対象は除外する
    • ポリゴンをダウンロードした後、zoom levelを選択し、そのズームレベルでポリゴンを含むタイルを特定する
    • MapboxのStatic Tiles APIでタイルを取得する
    • 緯度・経度座標のポリゴンは、各タイル基準のピクセル座標によるバウンディングボックスへ変換され、Ultralytics YOLO formatで保存される
    • 完成したデータセットはHugging Face Hubにアップロードされ、例のデータセットはmozilla-ai/osm-swimming-poolsである

  • 2段階: 物体検出モデルをファインチューニング

  • 3段階: OpenStreetMapへ貢献する

    • ファインチューニングした物体検出モデルで複数タイルに対して推論を実行する
    • そのまま実行できるRun Inference Colabが提供されている
    • 例のプール検出器はHuggingFace Demoで試せる
    • 推論プロセスにはいくつかの人間とのインタラクションが必要である
      • まず地図上で関心地点を選択する
      • 選択した地点の周辺について、margin引数に応じたバウンディングボックスが計算される
      • OpenStreetMapから既存の対象オブジェクトをダウンロードする
      • Mapboxからすべてのタイルを取得して結合し、スタック画像を作成する
      • スタック画像は重なりのあるタイルへ再分割される
    • 各タイルではYOLOv11の物体検出モデルが実行される
    • プールのような対象オブジェクトが検出されると、バウンディングボックスをSAM2に渡してセグメンテーションマスクを得る
    • 予測されたポリゴンは、OpenStreetMapから取得した既存ポリゴンと比較され、重複アップロードを回避する
    • 新規オブジェクトと判定された候補は1件ずつ表示され、ユーザーが手動で検証・フィルタリングする
    • ユーザーが保持すると選んだオブジェクトは、1つのchangesetとしてOpenStreetMapにアップロードされる

性能と実務的な含意

  • OpenStreetMap AI Helper Blueprintは、AIが人間の地図への貢献を強化しつつ、人間による検証を中心に据えられることを示している
  • 完全な手動プロセスでは、1分あたりプール2〜3件をマッピングできる
  • Blueprintを使うと、UXが最適化されていない状態でも同じ時間でプール10〜15件をマッピングでき、約5倍多い
  • 高品質なOpenStreetMapデータがあれば、YOLOv11のようなモデルを学習させて物体検出を行わせることができる
  • すべての問題にLLMを適用する必要はなく、地図機能の検出とポリゴン生成には軽量なコンピュータビジョンの組み合わせのほうが直接的な選択肢になりうる
  • 別の地図機能向けにモデルを学習させたり、リポジトリに貢献したりしたい場合は、OpenStreetMap AI Helper Blueprintを利用できる
  • 公開されている他のBlueprintはBlueprints Hubで確認できる

関連記事

2件のコメント

 
depth221 2025-03-24

調べてみると、Map Feature は通常、（地図の）地物と訳すことが多いようです。
 
GN⁺ 2025-03-24
Hacker News の意見

  • OpenStreetMap Foundation の立場としては、AI が検出した地物をデータベースに直接追加すべきではない。
    アルゴリズムには偽陽性の問題があり、最後から2番目のスクリーンショットのように、直線や長方形の物体を歪んだ形でマッピングしてしまう問題がある。
    見落とされた地物を見つける補助ツールとしては貴重だが、検出されたオブジェクトが正しく描かれているか確認するには、依然として人の介入が必要。
    参考: https://wiki.openstreetmap.org/wiki/Import/Guidelines および https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_...

    • デモアプリと提供されているコード例には、検出された地物を人が検証することを求めるステップが含まれている。
      ソースコードを変更しない限り自動アップロードはできず、ドキュメント、リンク先の記事、コードサンプル全体で人による検証を繰り返し強調している。
      地物を自動でアップロードしたことはなく、最初のバージョンを学習させる前にも、数百件のプールのサンプルを自分で編集しラベル付けした。
      地物の自動アップロードを防ぐために手順を改善するアイデアがあれば、聞いて実装したい。
      ツールをそもそも公開するなという反応もあるだろうが、AI を受け入れつつオープンに議論するより良い方法は可能だと考えている。
    • スクリーンショットの歪んだポリゴンは、画像の上に重ねるためにマスクとして描いた表示用ポリゴンだからそう見えるのであって、実際にアップロードされるポリゴンにはそのような歪みはない。
      予測ポリゴンが実際に歪む場合はあるため、そのような結果は捨てるよう推奨している。
      それでも最低限の品質に達したモデルの初版ができるまでは、このデモを公開しなかった。
      コードには、予測ポリゴンのノードが多くなりすぎないようにする形状の単純化ロジックも入っている。
    • 機械学習由来の地物にはタグを追加するとよさそう。
      こうしたツールはすでに半自動的に使われている可能性が高く、データベース全体が汚染される事態を減らす助けになり得る。

  • プール検出はよいし、太陽光発電の検出も試してみたいリストに入っている。
    ここでの反発のかなりの部分は、OSM は手作業のマッピングだけで成長できるという前提から来ているように感じる。
    しかし10年間で6万件の変更セットを作ってきた立場からすると、世界規模で地図データを圧倒的に有用にする水準まで、ボランティアの熱意だけでマッピングを「解決」することはできない。
    データの取り込みと保守のためのスケーラブルなフレームワークが必要だ。品質、出所、データソースのバグ報告先を注記として残す方法、そして利用者向けのガイドラインのようなものだ。
    例えば「過去1年以内に人がマッピングした X 種類の事業者」をクエリしたいなら、check date である程度は可能。
    だが、その属性がどれほど正確なのか、確認したマッパーが名称や位置のどちらか一面だけを見たのかは分かりにくい。
    alltheplaces の営業時間データを毎月自動で取り込んで維持するほうがよい場合もある。
    データ利用者の立場では、信頼する特定の出所だけをフィルタリングできたり、ポリゴンが完璧でなくても「AI で推論した関心地点」のような既知の制約を持つデータを活用できたりするほうが望ましいかもしれない。

  • 自動マッピングを実際に経験すると、極度に慎重になる。
    オートバイで南米を横断したが、OSM には自動と見られる編集が特にブラジルに多く、地域によってはほとんど使い物にならないほどだった。
    田舎道だけでなく、かなり大きな都市でもそうだった。

    • 机上のリモートマッピングは、いつでも悪い地図を作り得る。
      旅行時はたいてい mapwithme を使い、問題を説明する写真メモを残すようにしている。
      私はフェンスや遊び場の写真を撮ることが多く、ほかの人は風景写真を撮る。
      自動マッピングかもしれないが、自分のリモートマッピングも現地で確認してみるとかなりひどいことがある。
    • ブラジルのどの地域だったのか気になる。

  • 数年前にこの分野で作業したことがあるが、既存のモデル、データセット、ツールは非常に多い。
    https://github.com/satellite-image-deep-learning

    • すばらしい資料集だ。
      QGIS をいじりながら、公開・民間の衛星画像 API にいくつも登録してデータを取得し、実験していた。
      EU の宇宙機関には、ユーザーアカウントなしでも完全に公開アクセスできる優れたデータソースが多い。
      この新しい機械学習専用ツール集で作業してみるのが楽しみだ。

  • Google は認めないだろうが、Mapbox は非商用目的や OSM 用途であれば認めているようだ
    ただし、Mapbox のベクターデータではなく 衛星データを使う場合に限られる
    規約では、顧客がサービス提供物からコンテンツ・データ・情報をトレースしたり、派生・抽出したりしてはならないとされている一方で、衛星画像のみで構成された Mapbox Maps を Studio やサードパーティ製ソフトウェアでトレースして派生ベクターデータセットを作成できる例外があり、その目的は非商用目的または OpenStreetMap でなければならないとされている
    Mapbox はかなり寛大に対応してくれていると言える

  • 数か月前に似たようなものに取り組んでいた
    より小規模な地理データ向けだが https://github.com/uav4geo/GeoDeep

    • 素晴らしい取り組みで、協業のアイデアについて話してみたい

  • 衛星画像に見えるものをマッピングするのではなく、現地の事実があるものをマッピングすべきだ
    AI が幻覚したものは絶対に貢献してはならない

    • OSM でトレースの基準そのものが衛星画像であることは多い
      そのトレース品質は時に大きくばらつき、道路が海の上に置かれているような、奇妙にずれた海岸線を何度も直す必要があった
      このツールがある程度一貫しているなら、平均的な OSM 貢献者より良い可能性もある
      ただし、家・道路・水域をセグメンテーションし、現在のデータと比較して不一致を見つけ、修正対象として強調表示するところから始めるとよさそうだ

  • Mozilla は良いブラウザを作ることに集中してくれないのだろうか？

  • プールや太陽光発電アレイを検出するよう SAM/2 をファインチューニングする詳細をもっと見たい
    どちらも地域社会のレジリエンス・プロジェクトでマッピングされていれば非常に有用だが、SAM2 のファインチューニングは追うのが難しかった
    Yolov8 モデルで太陽光発電を見つけてセグメンテーションするのはかなりうまくいくが、エッジがあまりに乱れていて、整理に膨大な作業が必要になる
    学習済みの SAM2 の結果を見たが、はるかに良さそうだった
    正確性の問題があるので OSM には入れないだろうが、他の場所では十分使える

    • このプロジェクトには SAM2 のファインチューニングは含まれていない
      OSM のセグメンテーションデータは、セグメンテーションモデルを適切に学習させるほど品質が十分ではない
      ここでは境界ボックス予測に YOLO モデルを使用している
      OSM の境界ボックスはこの用途には十分で、各境界ボックスを SAM2 にプロンプトとして渡し、内部をセグメンテーションさせている
      ボックスの中心点を SAM にプロンプトとして渡す方法も試したが、結果はさらに悪かった

  • さまざまなフィードバックを反映して新しいリリースを出し、OSM に直接アップロードするコードはすべて OsmChange 形式でのエクスポートに置き換えた
    正しい方向への一歩であることを願っており、OSM フォーラムの専用スレッドで議論を続ける予定だ