Overture Mapsで始める道路分析基盤

Transcript

1. Overture Mapsで始める 道路分析基盤 Mobility Night #6 | 2026-07-29 ⾕本 晋⼀ ※ 機密‧専有情報 株式会社Luupによる個別の明⽰的な承諾を得ることなく、この資料を使⽤することを固く禁じます。 © all rights reserved Luup, Inc.
2. Who Am I? · ⾕本 晋⼀ · 2026年1⽉にLuupにjoin · 空間情報‧位置情報関連の分析および 基盤整備に従事 © all rights reserved Luup, Inc.2
3. ⽬次 · 道路分析基盤を作るモチベーション · Overture Mapsとは何か‧なぜ Overture Maps なのか · Overture Mapsを使ってどう基盤構築するか · Overture Mapsのハマリポイント · まとめ © all rights reserved Luup, Inc.3 3
4. ⽬次 · 道路分析基盤を作るモチベーション · Overture Mapsとは何か‧なぜ Overture Maps なのか · Overture Mapsを使ってどう基盤構築するか · Overture Mapsのハマリポイント · まとめ © all rights reserved Luup, Inc.4 4
5. Luupの事業課題 · どの道路がよく通過されるか? · ⾃治体の都市計画への協⼒ · どの道路がスムーズに通れるか? · 移動時間の⾒積もり、UX改善 ※ このヒートマップはダミーデータから作成しました © all rights reserved Luup, Inc.5 5
6. ⾛⾏ログだけでは答えが出ない ‧GPS⾛⾏ログは緯度経度の点列でしかなく、「どの道路にいるか」という情報を持たない ‧道路データに紐づける計算（マップマッチング）をして初めて「道路単位」の集計ができる マップマッチング 図: GPSの点列（左）を道路に紐づけると、道路単位の通過数‧通過時間が集計できる（右） ※ ⾛⾏データは統計処理した匿名データとして扱っています © all rights reserved Luup, Inc.6
7. 道路データを選ぶための軸 · 低コストで始められること · 始められるなら、すぐに始めたい。成功も失敗も早く経験して、知⾒を貯めたい · 効果が⾒えるまで、⼩さく検証できる⾦額で始めたい · 商⽤データは契約や⼿続きにも時間がかかり、「まず試す」の速度が出ない · 道路データの更新時に、マップマッチ後のデータを楽にメンテナンスできること · 道路は変わり続ける。新しい道ができ、交差点の形も変わる · 道路データは更新していく必要がある · 道路データの更新に伴い、マップマッチをやり直す必要があるが、必要なところだけ計算し 直したい（変更があった道路を通過する⾛⾏ログについてだけやる） · 全ての⾛⾏ログに対してやり直しは時間とインフラコストがかかる ‧軸は「保守を⾒据えて、低コストで貯め始められるか」 © all rights reserved Luup, Inc.7 7
8. ⽬次 · 道路分析基盤を作るモチベーション · Overture Mapsとは何か‧なぜ Overture Maps なのか · Overture Mapsを使ってどう基盤構築するか · Overture Mapsのハマリポイント · まとめ © all rights reserved Luup, Inc.8 8
9. Overture Mapsとは ‧AWS / Meta / Microsoft / TomTom による共同のオープン地図プロジェクト ‧ Linux Foundation傘下（2022年〜） https://overturemaps.org/ ‧無料‧商⽤利⽤可 ‧ ほぼ毎⽉リリース。DuckDBを使ってダウンロード可能。 ‧Transportation（道路）のほか、Places（POI）や建物などのテーマも同梱 ‧Transportation（道路）は OpenStreetMap‧TomTom等のデータをベースに整理さ れたもの ‧ ※ ⽇本の道路データの実態は後述（弱みのスライドで） ‧道路1本1本に、版をまたいで維持される永続ID（GERS ID）が付く © all rights reserved Luup, Inc.9 9
10. なぜ Overture Maps なのか（他の地図データとの⽐較） 導⼊コストと、地図更新時のデータメンテの楽さで選定。 ◎の数ではなく、軸に効く⾏で選ぶ。 導⼊コスト‧速度 更新時のデータメンテ 商⽤（ゼンリン等） OpenStreetMap (OSM) Overture Maps 当社の⽤途では初期コスト‧ ⼿続きが重い 無料‧今⽇から試せる 無料‧今⽇から試せる −（契約前に分からない） △ どのデータをメンテナンスすべきか はdiff logから⾃前で特定する必要あり ◦ change logが整備されておりどの データをメンテナンスすべきか すぐわかる ◎ 整備されている △ ⾃由⽂字列タグ ◎ 公式スキーマとして整備 契約条件による ODbL ODbL（OSMと同じ） 決め⼿ → 次の[強み]で解説 属性の整備 → [強み]スキーマ ライセンス 差がつかない → 注意点の章で ※ ⾏（切り⼝）は選定の軸から: ①低コストで始める ②更新時もデータを楽にメンテして⻑く貯める。ライセンスは選定では差がつかないため後半で扱う © all rights reserved Luup, Inc. 10 10
11. [強み] 変更点リスト（changelog）を公式がほぼ毎⽉配布 ‧Overture Maps は公式がどの道路がどう変わったかをまとめて配布している。 ‧参照が簡単なので、対応するべき道路がすぐにわかる。 取得コードの例（Python） import duckdb con = duckdb.connect() con.execute("INSTALL httpfs; LOAD httpfs; SET s3_region='us-west-2';") df = con.execute(""" SELECT id, change_type, columns_changed FROM read_parquet( 's3://overturemaps-us-west-2/changelog/2026-07-22.0/theme=transportation/type=segment/change_type=*/*.parquet', hive_partitioning=1) WHERE bbox.xmin >= 122.75 AND bbox.xmax <= 146.1 -- ⽇本のおおよそのbbox AND bbox.ymin >= 24.0 AND bbox.ymax <= 45.7 AND ( change_type = 'removed' OR (change_type = 'data_changed' AND list_has_any(columns_changed, ['geometry', 'connectors'])) ) """).df() ※ changelogは直前リリース との差分（遡り⽅はAppendix 参照） print(len(df)) # 2026-06版→07版において⽇本の道路データで対応が必要な件数 187,048件(全体の1~2%ほど) © all rights reserved Luup, Inc. 11 11
12. [強み] 属性フォーマットが公式スキーマとして整備 ‧OSMの⾃由⽂字列タグと違い型付き。データ加⼯時の⼊⼒値チェックと整合性取りに 時間を⾷わなくて済む。 ‧形式が整備されているだけで、中⾝が充⾜されているとは限らない（後半で） OSM: ⾃由⽂字列タグ Overture: 型付きスキーマ tags: map<string, string> speed_limits: ARRAY<STRUCT> max_speed.value: INTEGER (30) max_speed.unit: VARCHAR ("km/h") between: [0.0, 0.6] ← 区間付き(LRS) maxspeed = "30" maxspeed = "30km/h" maxspeed = "walk" ← 全部あり得る LRS = 道路の始点からの位置を0〜1で表し「この区間だけ30km/h」を表現する⽅式 公式スキーマ仕様: https://docs.overturemaps.org/schema/reference/transportation/segment/ © all rights reserved Luup, Inc. 12 12
13. [弱み] 属性の充実度合いはOSMと同等 ‧公式にはTomTom等のデータも統合とあるが、⽇本の道路データの出典を調べてみると 100% OSMだった → OSMより属性が充実しているわけではない。 ⽇本の道路segmentの出典元別件数（Overture Maps 2026-07-22.0版‧全国 約1,600万本‧筆者調べ） データの出典 OpenStreetMap 道路データ件数 全道路データの中の割合 16,176,414 100% TomTom 0 0% その他 0 0% ※集計コードはAppendix参照 © all rights reserved Luup, Inc. 13 13
14. ⽬次 · 道路分析基盤を作るモチベーション · Overture Mapsとは何か‧なぜ Overture Maps なのか · Overture Mapsを使ってどう基盤構築するか · Overture Mapsのハマリポイント · まとめ © all rights reserved Luup, Inc. 14 14
15. ⾛⾏ログ→道路単位の統計量計算の処理フロー ‧新しく登録された⾛⾏ログのフロー ダウンロード済 み Overture Maps 走行ログ データ 処理 マップマッチエ ンジン用 地図データ への変換 マップマッチエ ンジン用 地図データ マップマッチ エンジンによる マップマッチ処理 マップマッチ 後ログ 「Valhalla」はOverture Mapsを直接読 み込めないので事前にValhallaが扱える 地図データに変換 通過数:よく通る道路はどれか? 平均通過時間: スムーズに通れる道路は？ の答えになる 道路単位の 統計処理 道路ごとの 通過数 平均通過時間 OSSエンジン「Valhalla」を利⽤ https://valhalla.github.io/valhalla/ © all rights reserved Luup, Inc. 15 15
16. 地図データ更新時の再計算フロー Overture Maps Change log ① change log から、変更の あった道路IDを取得 ② マップマッチ済みログ （更新前）を①のIDで検索 し、その道路を通過した⾛ ⾏ログを特定 走行ログ 再マップマッチ対象と なる走行ログ を抽出 マップマッチ後 ログ (更新前) 再計算対象走 行ログ一覧 対象走行ログに対す る再マップマッチ処理 再計算対象でないデータは そのままコピー。 データ統合 マップマッチ後 ログ (更新後) 再マップマッチ 後ログ ※このフローは設計段階 © all rights reserved Luup, Inc. 16 16
17. ⽬次 · 道路分析基盤を作るモチベーション · Overture Mapsとは何か‧なぜ Overture Maps なのか · Overture Mapsを使ってどう基盤構築するか · Overture Mapsのハマリポイント · まとめ © all rights reserved Luup, Inc. 17 17
18. ハマリ：Valhalla は Overture Maps をそのまま使えない なぜ使えないか ‧Valhalla はOSM形式の道路データを前提とする ‧単純に形式変換すると、Valhallaが内部で切った後の道路と、元の道路の対応が取れない → マッチ結果を分 析にもメンテにも使えない どう回避したか ‧道路を交差点で分解し元の道路IDを引き継いだIDを振る → OSM形式に変換して Valhalla に渡す ‧交差点の位置は道路属性に⼊っているので、それを使って分解できる © all rights reserved Luup, Inc. 18 18
19. ハマリ：値がほぼ⼊っていない属性が存在する 型は整っていても、その値が埋まっているとは限らない ※ 出典元であるOpenStreetMapにそもそもデータが⼊っていないことに由来する データがほとんど⼊っていない データが全く⼊っていない (スキーマの定義すらない) 0.54% 標⾼ 幅員（道幅）の充⾜率（全国‧実測） 坂道の分析に必須なのに、項⽬が存在しない 対策: 必要なデータは外部ソースで補う前提で設計する。特に標⾼はDEM（国⼟地理院等）で補完でき る。 ※ 実測条件: Overture Maps 2026-07版 transportation segment（⽇本全国）をLRS区間で按分して集計（筆者調べ）。標⾼はスキーマにフィールド⾃体が無い（level_rulesは⽴体交差の上下関係⽤） © all rights reserved Luup, Inc. 19 19
20. 注意：Overture Maps 道路データはODbLライセンス ‧OSMと同じODbL。 ‧https://opendatacommons.org/licenses/odbl/ ‧統計値を紐づけたデータを外部に渡すと、NDA等で第三者への再共有を制限できなくなり得る ◦ 内部でのみ活⽤する 「配布」に当たらないため、基本的に問題になりにくい ◦ 集計し可視化した画像を渡す 地図画像などのレンダリング結果は「Produced Work」の典型 ＝ 帰属表⽰のみで提供できる⽅向 表記例: © OpenStreetMap contributors (ODbL) / Overture Maps Foundation × ジオメトリやIDを含むデータのまま外部に渡す 「派⽣データベース」に該当し得る。該当すると、渡すデータ⾃体にODbLの条件（相⼿の再共有を 制限できない‧出典表⽰など）が付き得る ⚠ 外に出す判断で迷ったら、OSMFライセンスガイドラインと法務への確認を！ © all rights reserved Luup, Inc. 20 20
21. ⽬次 · 道路分析基盤を作るモチベーション · Overture Mapsとは何か‧なぜ Overture Maps なのか · Overture Mapsを使ってどう基盤構築するか · Overture Mapsのハマリポイント · まとめ © all rights reserved Luup, Inc. 21 21
22. まとめ ‧低コストで始めたい、そして「メンテのしやすさを重視するなら、Overture Maps は選 択肢の⼀つとしてお薦めできる 選ぶ 作る ‧軸は「保守を⾒据えて、低コストで貯め始められるか」 ‧マップマッチはOSSのValhalla ‧決め⼿は地図更新時のデータメンテの楽さ ‧公式change log で「どこが変わったか」がわかる 気をつける ‧運⽤は2場⾯ ‧新規ログはそのままマッチ ‧地図更新時はchangelogで対象を絞って再マッチ ‧Valhalla は Overture Mapsを直接読めない ‧交差点で分解→OSM形式へ変換 ‧データがほぼ⼊っていない属性がある ‧外部ソースで補完前提 ‧配布時はライセンスに注意 ‧渡すなら画像で © all rights reserved Luup, Inc. 22 22
23. 街じゅうを ｢駅前化」する インフラをつくる ご清聴ありがとうございました 質問は懇親会にて
24. Appendix：参考⽂献 Overture Maps 周辺ツール‧ライセンス‧補完データ ‧公式サイト https://overturemaps.org/ ‧Valhalla（OSSマップマッチエンジン） https://valhalla.github.io/valhalla/ ‧GERS changelog（変更点リスト） https://docs.overturemaps.org/gers/changelog/ ‧OSM Wiki: Key:maxspeed（タグ表記の実態） https://wiki.openstreetmap.org/wiki/Key:maxspeed ‧transportation segment スキーマ仕様 https://docs.overturemaps.org/schema/reference/transportation/segment/ ‧ODbL 1.0（ライセンス原⽂） https://opendatacommons.org/licenses/odbl/ ‧データ取得ガイド（S3/Azure/CLI） https://docs.overturemaps.org/getting-data/ ‧OSMF Licence/Community Guidelines https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines ‧overturemaps-py（公式CLI） https://github.com/OvertureMaps/overturemaps-py ‧国⼟地理院 基盤地図情報（数値標⾼モデル） https://fgd.gsi.go.jp/download/ © all rights reserved Luup, Inc. 24
25. Appendix：⽇本の道路データ全体をダウンロード 最短: 公式CLI（1コマンド） pip install overturemaps overturemaps download --bbox=122.75,24.0,146.1,45.7 \ -f geoparquet --type=segment -o japan_segments.parquet 列を絞りたいとき: DuckDBでS3から直接 import duckdb con = duckdb.connect() con.execute("INSTALL httpfs; LOAD httpfs; SET s3_region='us-west-2';") con.execute(""" COPY ( SELECT id, subtype, class, connectors, geometry FROM read_parquet( 's3://overturemaps-us-west-2/release/2026-07-22.0/' 'theme=transportation/type=segment/*.parquet', hive_partitioning=1) WHERE bbox.xmin >= 122.75 AND bbox.xmax <= 146.1 -- ⽇本のおおよそのbbox AND bbox.ymin >= 24.0 AND bbox.ymax <= 45.7 ) TO 'japan_segments.parquet' (FORMAT PARQUET); """) ※ リリース名（2026-07-22.0 の部分）は最新版を公式ドキュメントで確認して差し替える © all rights reserved Luup, Inc. 25
26. Appendix：道路データを交差点の位置で分解する 交差点の位置は connectors 属性（道路始点からの相対位置 0〜1）に⼊っている。そこで切るだけ from shapely.ops import substring def split_at_intersections(seg): # seg["connectors"] = [{"connector_id": ..., "at": 0.0〜1.0}, ...] # at = 交差点の位置。両端(0.0 / 1.0)も含まれる ats = sorted(c["at"] for c in seg["connectors"]) edges = [] for i, (a, b) in enumerate(zip(ats, ats[1:])): edges.append({ "edge_id": f"{seg['id']}_{i}", # 元のIDを保持して採番 "geometry": substring(seg["geometry"], a, b, normalized=True), }) return edges ポイント: 分解後のIDに元のIDを含めておくと、集計結果からいつでもOverture側の属性‧changelogに戻れる © all rights reserved Luup, Inc. 26
27. Appendix：BigQueryに取り込むときのTips 前提: 公式のBQ公開データセット bigquery-public-data.overture_maps もある（最新リリースに同期） ただし版の固定ができないため、changelogでの局所メンテ運⽤をするなら⾃前ロードになる。そのとき踏むのが以下の2 つ ① enable_list_inference を指定しないと、ARRAY<STRUCT>属性（speed_limits等）が正しく読めない parquet_options = bigquery.format_options.ParquetOptions() parquet_options.enable_list_inference = True job_config = bigquery.LoadJobConfig( source_format="PARQUET", parquet_options=parquet_options) ② LRS属性の between は NULL があり得る（NULL＝道路全体に適⽤）— 補完はビューに閉じ込める CREATE VIEW ds.speed_limits_expanded AS SELECT s.id AS segment_id, sl.max_speed.value AS speed_kmh, COALESCE(sl.between[OFFSET(0)], 0.0) AS from_at, COALESCE(sl.between[OFFSET(1)], 1.0) AS to_at FROM ds.transportation_segment AS s, UNNEST(s.speed_limits) AS sl WHERE sl.max_speed.unit = 'km/h'; © all rights reserved Luup, Inc. 27
28. Appendix：道路データの出典元を集計するコード 本編[弱み]の「出典は100% OSM」の測定コード。1リリース分‧全国約1,600万segmentをS3から直接集計 import duckdb con = duckdb.connect() con.execute("INSTALL httpfs; LOAD httpfs; SET s3_region='us-west-2';") df = con.execute(""" SELECT src.dataset, count(*) AS n_source_records, count(DISTINCT id) AS n_segments FROM ( SELECT id, unnest(sources) AS src FROM read_parquet( 's3://overturemaps-us-west-2/release/2026-07-22.0/' 'theme=transportation/type=segment/*.parquet') -- 2⾏はSQLの⽂字列連結（カンマ不要） WHERE bbox.xmin >= 122.75 AND bbox.xmax <= 146.1 -- ⽇本のおおよそのbbox AND bbox.ymin >= 24.0 AND bbox.ymax <= 45.7 ) GROUP BY src.dataset ORDER BY n_source_records DESC """).df() print(df) # dataset n_source_records n_segments # 0 OpenStreetMap 19920734 16176414 ← OSM以外は1行も出ない メモ: 1segmentが複数のsource⾏を持つため n_source_records > n_segments。 © all rights reserved Luup, Inc. 28
29. Appendix：changelogでN世代前との差分を作る changelogは“直前リリースとの差分”のみ。だがS3に全世代分が残っているので、直近N個を連結しid単位で畳み込めば任意期間の差分を再構成できる import duckdb, pandas as pd N = 3 # 何世代前まで遡るか con = duckdb.connect() con.execute("INSTALL httpfs; LOAD httpfs; SET s3_region='us-west-2';") # ① S3に残るchangelogのリリース⼀覧（昇順‧全24世代）→ 直近N個で「N世代前→最新」をカバー releases = [r[0] for r in con.execute(""" SELECT DISTINCT regexp_extract(file, 'changelog/([^/]+)/', 1) AS release FROM glob('s3://overturemaps-us-west-2/changelog/*/theme=transportation/' 'type=segment/change_type=added/*.parquet') ORDER BY release""").fetchall()] # ② 直近N個のchangelogを連結（⽇本‧トポロジー変化のみ） changes = pd.concat([con.execute(f""" SELECT '{rel}' AS release, id, change_type FROM read_parquet('s3://overturemaps-us-west-2/changelog/{rel}/' 'theme=transportation/type=segment/change_type=*/*.parquet', hive_partitioning=1) WHERE bbox.xmin >= 122.75 AND bbox.xmax <= 146.1 AND bbox.ymin >= 24.0 AND bbox.ymax <= 45.7 AND (change_type IN ('added','removed') OR (change_type = 'data_changed' AND list_has_any(columns_changed, ['geometry','connectors'])))""").df() for rel in releases[-N:]]) # ③ id単位でN世代分のライフサイクルを畳み込む（GERS IDが世代をまたいで安定だから可能） def net_change(types): first, last = types[0], types[-1] if last == 'removed': return 'added_then_removed' if first == 'added' else 'removed' return 'added' if first == 'added' else 'data_changed' net = changes.groupby('id')['change_type'].agg(list).map(net_change) 実測（N=3: 2026-04-15→2026-07-22.0‧⽇本）: data_changed 298,865 / added 266,608 / removed 139,611 / added_then_removed 2,067（ユニーク 707,151件） ※ 期間内に複数回変わる道路は約1.6%のみ（畳み込みは軽い）。パッチリリース（2025-03-19.1等）も1世代として数える。N≦23（全24世代） © all rights reserved Luup, Inc. 29
30. Appendix：Q&A Q. GERS IDはどれくらい安定？ Q. データの社外提供はどこまでOK？ A. best effort（100%保証ではない）。分割等で変わることはあるが、変更は changelogで追跡できる A. 可視化した“画像”（Produced Work）が現実解。データのまま渡す場合は OSMFガイドライン＋法務確認を前提に Q. ルーティング（経路探索）にも使える？ Q. 商⽤データとの併⽤は？ A. 今回の割り切り変換はマッチ専⽤で不可。右左折禁⽌等まで真⾯⽬にOSM変 換すれば可能だが難度が⾼い A. 第三者への再配布要件がある場合のみ検討。社内分析はOverture/OSM系で ⾜りている Q. 可視化すると道路がズレて⾒える Q. IDが変わるのは地図の不備？実際の道路変化？ A. 商⽤の背景地図とはジオメトリが数mズレる。背景地図をOSM系（CartoDB 等）にすれば解消 A. 両⽅ある。changelogで「何がどう変わったか」を確認した上で対応を選べ る Q. ⼀番近い道路に寄せるだけ（空間JOIN）ではダメ？ A. 2つの理由でダメ。①点と点の間にどの道路を通過したかが分からない ②GPSの揺れで、交差点もないのに途中から並⾛する別の道路に乗り移 るような、軌跡として不⾃然な紐づけが起きる。マップマッチは「道路 網上を実際に⾛れる経路か」という軌跡の制約で推定する。この制約は 空間JOINでは表現できない © all rights reserved Luup, Inc. 30