　この記事は、過去に断片的に書いた記事を Advent Calendar 用に加筆修正してまとめなおしたものです。

★前置き

▽自動運転とナビ

　私の所属している組織では、ナビ用の地図を作成しています。

　ナビ用の地図は、原則としては道路のネットワーク構造を体現できれば良いので、道路を１次元複体（と同相である図形）で表現します。交差点（行き止まりの道路の終点を含む、以下同じ）を０次元単体で、交差点から隣の交差点までの短い道路区間を１次元単体（線分と同相の閉セル）で表現するわけです。

以下、上の意味での位相同相である図形を同一視して、道路ネットワークを単に１次元複体と呼ぶことにします

　実際のナビ地図は、個々の道路区間は適当な折れ線で近似されて表現されています。その上に、図形は地上の座標系（局所的にはジオイド面とその法線としての鉛直線で規定される３次元座標系、大域的には地球重心を原点とする３次元直交座標系またはジオイド面を近似した回転楕円体面とその法線を用いた地理学的経緯度及び平均海面からの高さによる座標系）に基づく長さ（計量）を持ち、また、車線数とか規制速度などの属性値を持ちますので、これらを重み付けした結果として選択すべき経路に順序を導入して最適な経路を見つけているわけです。自車の位置は、一般的には衛星測位で得ますが、この１次元複体上の特定の点になるよう、３次元空間から１次元複体への適当な写像が用意されています。この写像は、一般的にはマップマッチングと呼ばれています。ここまでの話は、多くの方には釈迦に説法だと思います。

　一方、自動運転用の地図は、自車を中心とした狭い範囲（たかだか200m程度以内）について、現実の３次元空間の一部を再現できるようなものとして生成されます。ナビ地図とは異なり、工事規制、天候変化（豪雨による冠水など）、信号機の状態、路上障害物の有無なども表現する必要があります。短時間で変化する情報まで含めた大量の情報を扱いますから、個々の自動車には局所的な情報しか保持できません。静的な道路の情報も、車線を区別できるレベルの、最低でも25cm、できれば数cmレベルの精度の詳細な位置情報が必要になります。

　このように用途が全く異なりますので、自動運転用の地図では毎瞬毎瞬の安全確保を目指す反面、大域的なルート選定は不向きです。ナビ地図と自動運転用地図とは、メンテナンスの難易度、データ量の多寡などの観点もあって、今後も共存していくものと考えています。

▽地図データの表現形式

　上の意味での一次元複体で地理空間情報を表現する場合は、ISO 19107 で詳細の記述が規定されています。このISO19107は、ISO/TC211（地理空間情報に関する標準についての技術委員会）で制定されたものですが、制定当時は日本国の代表は故伊理正夫先生が務められました。位相空間上で表現する場合と、その図形の実空間での表現が対比できるように標準が書かれていて、ある意味一般の利用者には難しいのですが、理解が進むと良くできていることが分かります。

　ナビ地図の場合は、ISO19107に従いつつ、ISO19107が規定していない細かい部分については独自の標準を設けて、それに従って記述しています。本稿では、一次元複体を適当な要求精度で離散化して記録している、ということだけを述べておけば足りると思います。

★自動運転用地図とナビ地図の関係づけを考え直す

▽ナビ地図の数学的な性質を追加する

　実は、ナビ地図には、１次元複体としての性質だけではなく、もう一つ性質を持たせることができると考えています。

　ナビ地図で扱う道路は、当然、自動車が円滑に走行できる道路です。一次元複体としての道路区間は、現実的には、道路管理者が設計した道路中心線を取得するものですが、この道路中心線は滑かな曲線を接続して描かれます。つまり、少なくとも C¹ 級の線図形です。従って、ナビ地図は「少なくとも１回連続微分可能な線図形を１次元閉セルに持つ、１次元複体と同相な図形」と言い直すことができます。（←ちょっと厳密な表現ではないかもしれませんがお許しを）

　これまで微分可能性が言われてこなかったのは、デジタルデータ（離散化した後）だからだと思いますが、実際には道路の曲率半径が自動車の最小回転半径よりも大きい値になっているかどうかは重要なファクターです。余談ですが、一般の自動車はたかだか 5m 程度の最小回転半径を持ちますが、大型車（例えば新幹線車両を陸送するような車両）の場合は最小回転半径がずっと大きくなります。このような車両が通行する場合は、曲がれる・曲がれないや、橋梁などの耐荷重が問題ないか、トンネル入口や高架下で車両が頭をぶつけないか、などを道路管理者が逐一判断する必要があります。

▽自動運転用地図の現状

　自動運転用の道路地図には、一応デジュール標準（ISO TC204/WG3 が定める GDF5.1 をベースに ISO20524 と ISO22726 が最新規格、詳細は https://www.jsae.or.jp/01info/org/its/tc204_wg03.pdf などをご覧ください）がありますが、技術進歩が早い分野なので多くのプレイヤーはデジュール標準の制定を待っていられず、デファクト標準をチーム毎に定めている感じがあります。理由の1つに、自動運転では TC204 よりも TC22 に軸足を置くプレイヤーが圧倒的に多いので、TC204 の標準があまり知られていない、ということもあるのだろうと私は見ています。

　それはともかく、自車の周辺の道路を地図にする（適切に抽象化してデジタルデータとして取得する）場合、車線の一部を長方形と同相の図形として取得して、そこに必要な属性を載せる、と考えることが自然です。案の１つとして、ベルトモデルというものがあり、これは車線の一部を長方形と同相な図形として見た場合に、長辺に対応する部分を Side Line、短辺に対応する部分を Terminal Line と呼んでいるようです。車線を流路とみなして考えると、Terminal Line は流入専用と流出専用のものが一対となります（ここでは議論を簡略化するために、行き止まりの道路は一旦除外して述べています）。

　問題は、こうして車線単位の図形を規定した場合、それが道路中心線ベースのナビ地図とどのように対応付くかについて良い考えがまだ登場していないことです。上記のベルトモデルでも、中心線との対応について、また、合流・分岐車線の扱いについては、決定打となる案が示されていません。

▽ナビ地図側から手を伸ばす

　ナビ地図側に微分可能性を追加仮定するならば、局所的には（曲率半径の範囲内では）管状近傍が定義できます。厳密には、１次元複体がどのような空間に埋め込まれているのかも考える必要がありますが、ここでは議論を簡単にするために、現実の路面と整合するような２次元多様体に埋め込まれているものとします。（立体交差まで考えると頭が痛くなります）

　管状近傍の範囲内では、中心線を底空間と見てその上の法ベクトルバンドルを規定すると、その切断として個々の車線境界線を一意的に記述できます。車線には一対の車線境界線がありますが、これをベルトモデルでいうSide Lineに対比させることができます。その場合、Terminal Line は、底空間（道路中心線）上の適当な点における法ベクトル上の２本の切断を結ぶ線分として規定できます。

　交差点（分岐合流を含む）においては、交差点を合理的に通過できるルートが何通りか存在します。議論を簡略化するために、Ｙ字路で分岐しているものとしましょう。前方左へ行く車線と、前方右へ行く車線は、交差点の手前では同一の車線です。Ｙ字路では道路中心線も分岐するわけですが、左の分岐路と右の分岐路は交差点の手前では同一の位置にあると見ることができます。交差点の手前では、この２つの分岐路を同一視して、一本の中心線として扱っている、と考えることができます。実際には、ナビ会社はこんな面倒なことを考えていないと思いますが、道路管理者は「国道１号線と国道20号線の重複区間」のように、複数路線を同一視している場合があります。

　中心線から上記の方法で生成した車線についても、分岐の手前については、接着写像を用いて同一視することとすれば、車線としての分岐が自然に定義できると考えられます。より複雑になりますが、複数車線の道路同士の十字路（右左折も可能な道路）についても、複数本の車線を接着写像で同一視することにより、現実の道路及び現実の走行路と対比させることができるはずです。

　ちなみに、道路管理者はおそらく誰も法バンドルという言葉は使いませんが、中心線の接線方向を縦断方向、法線方向を横断方向と呼んでいます。従って、中心線（１次元複体と可微分多様体の構造を併せ持つ図形として考える）の管状近傍の範囲内であれば、縦断座標（現実には、指定道路の起点からの道なりの距離、または、最寄り交差点からの距離）と、横断座標を使えば、任意の点を一意的に表現できます。これは、建物を建築する場合における敷地内の局所座標系（それは往々にして設計時の CAD の座標系だったりします）と同様に、現実空間（S² と同相なジオイド面とその法線である鉛直線で規定される空間）の局所座標系として広く使われているわけです。

▽自動運転用地図側から手を伸ばす

　上記の考え方は、多少の数学的な知識を必要とするので、多くの人にはハードルが高いと思われます。実際、ISO/TC204 国内関係者だけの小さな会合で述べた際には、ごく一部の人にしか分かってもらえませんでした。ISO/TC211（地理空間情報全体の標準）においても、３次元までの図形は扱っているものの、それらの図形を底空間とするベクトルバンドルについては記述がありません。

　地理空間情報を取り扱う一般的なソフトウェアとして GIS が有名ですが、GIS では、図形の属性情報は図形を底空間とするファイバーバンドルのつもりで扱っているように見える場合が多々あります（属性値が文字列のような離散空間の場合もあるので、ベクトルバンドルと書きませんでした）。GIS 上での属性追加は、ホイットニー和を想起させます。このファイバーは、関係代数と呼ばれる分野である程度まで定式化されているようですが、私の乏しい知識では関係代数の標準的な教科書（古い）にも数学的には仕方のない穴がいくつか見られます。RDB の専門家の間では解決済かも知れませんが、ちょっとググっただけではそのような話は見えません（どなたかご存じの方がいらっしゃればご教示下さればありがたいです）。

　このようなことを考えつつ、自動運転用地図（ISO/TC204 を意識しておらず、ISO/TC211 も十分には意識していない、デファクト標準もどきの地図）をナビ地図と対比させようとする場合は、ベクトルバンドルのような一般人には難しい概念を使わず、単に「各車線から道路中心線への連続写像」が定義できればいいではないか、という考え方が存在し得ると考えます。管状近傍内の任意の点は、ベクトルバンドルを考える際の射影として対応する底空間上の点を考えることができますから、上記のような連続写像は必ず存在します。あとは、計算機で実装しやすい方式を考える、という工学的もしくは計算幾何学的な問題に帰着するわけです。

★おわりに

　Level5 の自動運転が実現するためには、まだ多くの問題が残っています。余り注目されていませんが、ここで書いたような問題も解決が必要ではないかと考えています。私の力ではとても解決できそうにありませんが、世の中には私よりも遙かに優れた方も多数いらっしゃいますので、その中から上記のような問題を数学的にすっきり定式化して下さる方がいると嬉しいな、と馬齢を重ねて引退が近い私はこっそり希望しています。