DRM-PF

アジャイルな道路デジタルツイン（一財）日本デジタル道路地図協会
鎌田 高造

発表者の立ち位置
予備説明 （一財）日本デジタル道路地図協会
 1988年に設立されたナビゲーション用地図を作っている財団
 国土交通省道路局の関連団体
 道路DX を下支えする立場 自動運転用の地図は作っていない 日本の自動運転用地図は、DMP が整備（予算規模が桁違い）
 要求レベルが異なる（後で説明する）

 今日の発表は
 11/12 FOSS4G Tokyo の発表の詳細版（持ち時間４倍）

DRM-DB

ナビゲーション用の道路地図
 ナビ用に道路のネットワーク構造を取得
 道路を一条線で表現、いわゆるグラフ構造を持つ
 交差点をノードと呼んでいる 交差点から次の交差点までをリンクと呼んでいる

 GISとは相性の良い書式

 標準仕様に基づいて整備している
 外部有識者に議論してもらって、標準仕様を決定
 1988年の設立以来、基本書式は維持してきているDRM-DB

道路をネットワークで表示するということ

ノードノード★道路網を、ノードとリンクで表現する★交差点等にはノードがある

リンク★ノードから次のノードを結
ぶ短い道路区間がリンクである★管理者区分で色を分別表示★通行区分は、ノードまたはリンク単位で持たせる・ノードは右左折の可否等等を示す・リンクは一方通行の有無等を示す

DRM-DB

ナビゲーション用の道路地図
 メンテナンスもしっかりと 年４回のバージョンアップ（うち１回は大規模）
 VICSリンクなどとも連携している
 道路管理者から開通前に図面をもらって編集 入手した図面は国土地理院とも共有している

 概ね県道以上の道路には、国費も投入
 道路管理者にも使ってもらっている 著作権は国道管理者と共有している
 図面ベースなので、移動経路実績ベースよりも正確

DRM-DB

ナビゲーション用の道路地図
 幅員３ｍ以上の道路は原則として取得
 高速道・国道・県道等以外のメンテナンスには国費投入なし
 市町村道の図面は入手が容易でない場合もあるのが難点 有償で一般公開してきている メンテナンス費用は利用料金収入にも依存している（国費投入は県道以上のみなので） できるだけ低い料金収入で安定的な更新を続けることが課題

 自動運転用地図よりは、遥かに低いコストで更新できているが

ナビ地図と自動運転地図の違い
予備説明
 ナビ地図はルート選定を担当する
 道路のネットワークを表現する
 道路網を１次元複体で表現 絶対位置が重要（ただし中小縮尺レベルで良い） 自動運転地図は毎瞬の安全運転確保を担当する
 車線、規制、天候、障害物を即時提供可能な形式で表現
 自動車周辺の詳細なリアルタイム状況を表現 相対位置精度が重要（大縮尺レベルが必要） 日本の場合は、ダイナミックマップを採用
 自動運転のシミュレーションに徹する考え方も登場している

ナビ地図と自動運転地図の違い
予備説明
 ダイナミックマップ
 データの変化速度に合わせて、４層構造を持つ
 動的層：路上障害物、子供の飛び出し、信号の変化など
 準動的層：渋滞、天候変化など数分から数時間単位の変化
 準静的層：工事規制情報など数日単位の変化
 静的層 ：高精度な道路地図（要求精度は25cm以上）
 ダイナミックマップの仕様
 ISO 20524, ISO 22726 で標準仕様が定められている
 ISO TC204/WG3 が担当
 DRM協会は、ISO TC204/WG3 の国内審議団体も引き受けている

出典：第30回 SIP自動走行システム推進委員会・資料

xROAD : 道路DXの構想

令和4年度道路関係予算概算要求概要 p.45より

xROAD : 道路DXの構想
前スライドの図を拡大したもの

xROAD構想におけるDRMの役割
道路デジタルツインのベースレジストリを目指す
 道路に紐づく数々のDB群 前スライドの、リアルタイムデータや構造物データ
 道路に紐づく ＝ 道路と相対位置が整合する

 これをデジタル化すると
 DRM-DBに、構造物データやリアルタイムデータのDBが紐づく こうして、サイバー空間に道路が再現される

 デジタルツイン
 サイバー空間内に実空間（の一部）を再現したもの
 DRM-DBはサイバー空間における基盤となるデータ

xROAD構想におけるDRMの役割
道路デジタルツインのベースレジストリを目指す
 道路の相対位置
 起点からの道なりの距離（縦断方向）
 バリエーションとしての、交差点中心からの距離

 道路中心線からの距離（横断方向）
 バリエーションとしての、道路縁からの距離

 道路中心線を（微分可能な）曲線として考えると
 縦断方向は接線方向に該当し、
 横断方向は法線方向に該当する

 局所的には相対位置が重要 車載センサが返す情報も、相対位置
 全てを絶対位置だけで管理しようとするのはコスト高になる

道路デジタルツイン
 道路に関するデジタルツインを作るとは？
 サイバー空間内で道路を再現する
 センサーを通じて現況を取り込む
 外部要素が与える影響を推定する

 時系列解析で近い将来を予測する
 関係者で状況を共有する

 道路デジタルツインを使いこなすとは？
 道路に関する現況をデジタルツイン上で表現する
 デジタルツインに表現されている道路の現況を共有する
 現実世界に影響を与えずにシミュレーションを行う
 これら全てを従来よりも少ないリソースで行う

道路デジタルツインの実際
 Lv.1 道路デジタルツイン
 道路網を再現する
 全ての道路構造物の位置を、縦断方向＋横断方向で管理 現在のDRM-PFが目指すのはこのレベル

 インフラ管理には、このレベルで十分に役に立つ Lv.2 道路デジタルツイン
 車線レベルの道路情報を完全再現する

 全ての道路構造物の位置は、縦断方向＋横断方向＋路面高及び経度緯度＋標高を状況に応じて自動的に使い分ける
 Level 5自動運転が目指すのはこのレベル
 シミュレーションに耐えるレベルができればメンテ不要かも？

DRM協会の目標

Lv.1 道路デジタルツインの完成を目指す
 DRM-PF
 道路管理者への普及を達成する
 道路関連施設DBを紐付ける
 ナビ及び道路管理以外への利用を見越してAPIを開発する

 点群データ DRM-PFと紐付いたデータの活用が進む 特車の折進可否審査の自動化が進む

 DRM-DB
 点群を活用して、直轄国道から精度向上が進む 地理院とも協力して道路変化への追随速度を向上させる

DRM-PF

Lv.1 道路デジタルツインのベースレジストリ
 DRM-DB を PostGIS に入れてみた
 DRM-DB 自体は位相的に１次元複体の構造を持っているので、PostGISに入れること自体は簡単
 0次元単体のテーブル（交差点） 1次元単体のテーブル（交差点から次の交差点までの道路区間）

 ユニークキーを実装した
 道路網は時間変化するが、これまでのDRM-DBには時間変化に耐えられるキーが設計されていなかった（30年間も！
 時間変化に耐えるキー：P-ID（DRM標準として定式化した）

 ベクトルタイル化した 地理院地図ベクトルタイルと書式や UI を合わせた

DRM-PFの外観
令和4年10月版

 見た目は地理院地図に酷似
 道路管理者にとっつきにくいと思わせたくない 操作もかなりの部分が共通

最後に時間の許す限り実演します

背景地図は、地理院地図（淡色）

背景地図は地理院空中写真に切替え可能

DRM-PFの開発、実際①ベクトルタイルを選ぶ前

 QGIS で見せることを考えた
 可視化アプリをDRM協会で新たに作りたくない DRM-DBを単にRDB（PostgreSQL+PostGIS）に格納 道路関連情報のDBとは、QGIS上で疎結合すれば良いと考えた 多くの道路管理者は、QGISの操作に不慣れだった 国土交通大学校で10年以上前からQGISの講習もやっているが 使える人材の割合は現時点でも少数にとどまっているようだ ソフトウェアのインストールとカスタマイズも好まれなかった
 地理院地図は既に道路管理者でも広く使われていたDRM-PFの開発、実際②
なぜベクトルタイルを選んだのか GISより易しい、ベクトルデータ配信をしたかった
 地理院地図（ベクトルタイル）の出来が良かった
 地理院地図サイトが、自由にフォーク出来る設計思想だった
 自分が地理院OBなので地理院地図に思い入れと信頼があった ベクトルタイルを選んでみて
 開発工数を抑えることが出来たことは良かった 外見や UI/UX が地理院地図なので、利用者の取っつきも良い GIS と比べて、学習コストが大幅に低い

DRM-PFの開発、実際③ベクトルタイル化 DRM-PFの設計方針（2） PostgreSQL+PostGIS に格納した DRM-DB をベクトルタイル化
 地理院地図VTとは別のサイトで提供することとした
 道路特有のAPIについても若干数を設計した

 最初のバージョンをR4.3に開発
 DRM-DBベクトルタイルを地理院地図VTライクなサイトで構築
 背景に地理院地図タイルを表示

 個々のベクトルの属性を表示させることも成功
 ８点のAPIを初期導入することにも成功 本省道路局、DRM協会の大口提供先企業等に披露

DRM-PFの開発、実際④パーマネントIDの実装
 パーマネントID
 DRM-DBのには、これまで時間変化に強いID体系がなかった それまでに提唱された区間IDは実装方法が明確ではなかった
 R3下半期に、時間変化に強いID体系を標準化

 これがパーマネントID （P-IDと略称することが多い） DRM-PFに直ちに実装した

 パーマネントIDの更新
 標準化に際し、道路網の変化に伴う P-ID の更新方法まで規定
 RDB上での更新を R4.9 に実装

DRM-PFの開発、実際⑤パーマネントIDの模式図①：従前の id 体系
N:0314

N:0314

N:0314

L:03140625

L:03141248

L:03141248

N:1248

N:1248

新設道路①

新設道路①

L:12483587
N:3587
新設道路②

N:0625

L:06251248

L:06251248

N:0625

N:0625

道路が新設され交差点が増えるごとに、リンク番号が変化していくDRM-PFの開発、実際⑥パーマネントIDの模式図②：P-ID の場合
基準日：すべてのP-IDは整数
P:4270005835

P:4270005835

P:4270005835

P:5270015284.00000

P:5270015284.10000

P:5270015284.10000

P:4270010836

P:4270010836

新設道路①

新設道路①
P:5270015284.21000
P:4270034261
新設道路②

P:4270000912

P:5270015284.20000

P:5270015284.22000

P:4270000912

P:4270000912

道路が新設され交差点が増えても、リンクP-IDの整数部分は変化しないDRM-PFの開発、実際⑦集約交差点①

必要性と定義 IC や JCT
 ICやJCTは、多数のノードとリンクで構成される
 ノード：本線とランプウェイ及びランプウエイ同士の分岐合流
 リンク：個々のランプウェイ

 一般交差点
 一般交差点でも、複数のノードとリンクで構成される場合あり 例：立体交差点＋渡り線、十字路＋常時左折可のリンク

 集約交差点 DRM-PFでは、IC や JCT を構成するノード及びリンク群をまとめて「集約交差点」と呼び、P-ID とは別に ID を振っているDRM-PFの開発、実際⑧集約交差点②集約交差点の例

 集約交差点の例
下妻市R294とR125の立体交差と側道つくば市、左折可路線がある十字路



論理的には１点だが、交通の円滑化のために複雑な形状で設計されている

このような交差点は、ICやJCT以外にも膨大な数が存在しているDRM-PFの開発、実際⑨集約交差点②実装方法

 集約交差点機能の実装
 集約交差点の範囲をポリゴンで囲む（紙地図に手書きで範囲を囲ったものから、地理院地図の作図機能などを使ってポリゴンを生成させる） IC に関係しない道路を除外（除外するべきリンクの両端ノードを除外リストとして別途記録）
 集約交差点に属するノード ポリゴンの内部にある、除外リストに記載されていないノード

 集約交差点に属するリンク
 両端ノードがともに集約交差点に属するノードであるリンク

DRM-PFの開発、実際⑩集約交差点③応用

 集約交差点機能の応用
 ポリゴンで囲む範囲は、集約交差点でなくてもよい 代表的な有効例は、ゾーン30

 ゾーン30を一括して扱うと
 内部のリンク全てに、制限速度30km/hを一括して付与できる

 道路網が変化すると？
 ICやJCTの範囲、ゾーン30の範囲は変わらないことが多い 変化した道路網（一部の道路が追加され、それによって既存のリンクが分割され、時系列を意識してP-IDが再附番される）に対し、前スライドの方法で集約交差点を容易に再指定できる

DRM-PFの開発、実際⑪集約交差点④

将来の用途

 集約交差点機能の応用（2） ポリゴンで囲む範囲は、集約交差点でなくてもよい（続） 代表的な有効例は、特車スパン

 特車スパン 特車が走行できる道路（道路網の一部）
 特車道路網を、一般道路網の部分グラフと見た場合における、特車道路網のリンク（一般道路網の複数のリンクと対応する）
 実装はやや難しい
 部分グラフと全体グラフの対応付け（数学的には中への準同形）
 別々に管理してきているので、機械的な対応付けが簡単にできるわけではない・・・

DRM-PFの開発、実際⑫セキュリティとユーザ管理①
 ユーザ管理 当初は道路管理者にまず公開
 著作権のある、有償提供しているデータなので、いきなり一般公開にはしない予定 悪意のある利用者がほぼ皆無の状態で、セキュリティとユーザ管理を確立させたい（R4下半期で対応中）
 セキュリティ
 現時点では、ユーザIDとパスワードを個別に発行
 多くの SNS と同様、1つのIDで複数の端末からログインを許す
 身に覚えのない場所からのアクセスには確認メッセージを送るDRM-PFの開発、実際⑬
一般公開に向けて 一般公開に際しての要件
 データが流出しない仕組みが必要
 ベクトルタイルサイトを前提に、ラスタタイルサイトを構築
 APIを共通で使えるように工夫する

 道路管理者以外には有償公開
 ラスタタイルサイトは無償で供覧するが DRM-DBの詳細なデータはAPIを介さないと得られない

 API の利用に小額の利用料金を頂く仕組み

DRM-PFの道路管理での利用
絶対座標と局所座標との変換
 データペア（P-ID, D-tan）
 P-IDで１次元単体（道路区間）を指定
 １次元単体は、予め向きが決まっている D-tan で端点からの距離を指定
 D-tan は、P-ID で指定される道路区間の端点からの道なり距離 これで、任意の道路上の地点を一意的に指定できる

 表現方法の変換
 道路上の任意の地点について
 絶対位置（lat, lon）を局所座標（P-ID, D-tan）に変換する
 局所座標（P-ID, D-tan）を絶対位置（lat, lon）に変換する
 この２つをAPIとして実装

DRM-PFの道路管理での利用
道路関連施設DBとの紐づけ 橋梁、トンネル
 頭上高、耐荷重などの属性値を持つ

 標識
 規制または案内の効果を持つ

 道路関連施設の位置
 GNSS 等で経度緯度の値を得ている
 API で局所座標（P-ID, D-tan）に変換できる

 これで、道路関連施設が道路地図に紐付く
 P-ID＋D-tan → 路線名＋距離程に変換すると、道路管理者は経度緯度の誤りにすぐ気づくことが出来るプラットフォームのイメージ
ユースケース

交通量・
旅行速度
ビュワー

特車登録
経路確認

通れるマップ

バスロケ

ヒヤリ
ハット

維持管理
業務支援

道路交通情報マネジメント側
システム側

アプリ

ユースケースに特化した専用アプリ

QGISなど汎用アプリ

PF経由で業務に必要なデータを取得するためのAPI

プラットフォーム

PFがあれば：
1. 全てのDBは道路に紐づく
2. アプリは統一IFでDB群にアクセス
3. 道路管理者はマネジメントに専念

APIを
交通整理

道路上の位置を特定するためのAPIP

道路PF情報（ベースレジストリ－DRM-ess.DB ＋ P-ID ）DRM協会の担当は枠内のみ

道路に紐付いたMMS点群を取得するAPI

MMS点群
DB

その他のDBにアクセスするAPI
それぞれのDBからデータを取得するためのAPI

民間DBを含む

橋梁DB ，トンネルDBDB

その他の道路に紐付くDB

ETC2.0 DB

各DBは、格納データを全て道路に紐付けるものとする

占用物件
DB ，付属物DB 等

もしもプラットフォームがなかったら
ユース
ケース

交通量・旅行速度
ビュワー

通れるマップ

特車登録
経路確認

バスロケ

ヒヤリ
ハット

維持管理
業務支援

道路交通情報マネジメント側
システム側

アプリ

ユースケースに特化した専用アプリ

QGISなど汎用アプリ（自力で位置合わせ）（自力で位置合わせ）

個別入出力

個別入出力PFがないので：
1. 全てのDBは経度緯度に紐付いている
2. アプリはDB毎に異なる仕様とIFに対応
3. 道路管理者はDBの特性も考慮する必要

DRM-DB

MMS点群
DB
橋梁DB ，トンネルDBDB（道路ネットワークのDB）

ETC2.0 DB

占用物件
DB ，
付属物DB 等

その他の道路に紐付くDB
民間DBを含む各DBの格納データは経度緯度で取得。道路との紐付けはアプリとDBの個別対応。

たったこれだけのこと
 道路関連施設
 全ての道路関連施設を、DRM-PF に紐付けたい
 道路関係団体として、道路行政のDXを下支えしたい QGISが難しいと感じる現場に、学習コストを負わせない

 道路関連施設以外
 交通関連施設も、同様に紐付け可能
 工事図面、３次元点群データも紐付け可能

 ダイナミックマップの紐付けも目指したい アジャイルなスタートアップ 予算を掛けずに DX に対応しているので・・・・