道路地図のベクトルタイル
まえおき
この記事は、
qiita.com用の記事です。
昨年までの状況
私は道路地図を作る財団で仕事をしています。私が今の職場に来たのは 2020年ですが、この団体は 1988年から仕事をしていますので、今の目で見るとやや Old Fashined な部分はあります。
現在のデジタル道路地図データは、あの頃に設計されたもので、
- 道路のネットワーク構造をグラフで表現する
- グラフは、一次元複体と論理的に同等な図形に、属性値を持たせたものとする
- GIS が高価な時代だったので、大型計算機でバッチ編集できるような固定長の書式を採用する
- 当時の計算機のメモリ空間が貧弱だったので、極力切り詰めた書式とする
のような考え方でした。令和の現在の視点で見ると時代遅れですが、あの頃の計算機環境を考えると画期的だったと思います（今、このことを誇りたいのではなく、単に先人の悪口を言いたくないだけです）。なんせ、GIS を導入しようとしたらハードウェアとソフトウェアのそれぞれにベンツ１台分とか掛かった時代です。パソコンはようやく i80386 が登場した頃で、クロック周波数はまだ12MHzとか、メモリ空間も数MBytes しかない時代、GIS を動かしたければスペック･価格とも１桁上の WS を買わなければならない時代でした。
これを、曲がりなりにも30年以上にわたって維持管理してきたわけです。システム寿命が30年あるってそこそこ偉いと思います。
ーーー
そのような時代のデータですので、これまではオフラインでCD-ROM等に格納して提供してきました。昭和の頃はパソコンに装着可能な安価な CD-ROM ライターはまだありませんから、当時は多分 MT 渡しだったのだろうと思います（調べていません）。
当然、このやり方では令和の時代になじみません（というか、平成中期には既にメインストリームから外れつつあったと思います）。
昨年のこの記事では、なので、ウチの DB を PostGIS に格納してみる、という記事を書いたのでした。
今年の状況
さて、PostGIS への格納と、それをリモート接続した QGIS からアクセスすることには、今年初春には既に成功していました。データ量がギガバイトまでいかないおかげで、アクセスもストレスなくできています。
しかし、ウチのDBを利用してくれている顧客の大半は、QGIS が使えません。QGIS 自体は短いものなら半日、少し長くても３日程度の研修で最低限の操作ができるようになりますが、それは昭和の時代のワープロ研修と同じで、覚える気持ち満々の人だけに当てはまる話です。
また、PostGIS でネット越しにデータアクセスをしようと思うと、クライアント側でポートを開放する必要が出てきます。実は、これはセキュリティ管理者の立場ではあまり嬉しくありません。なによりも、セキュリティ管理者が GIS に理解がなければ、そもそもポートの開放を認めたりはしないと思います。
ベクトルタイルへ
ところで、QGIS の比較的新しいバージョンでは、地理院地図ベクトルタイルに直接接続ができます。Mapbox の ver.1 で .pbf に変換したデータであれば、正しく url を入れれば読み込むことができるわけです。
ウチのデータは、論理的互換性を維持したままで、shapefile に変換することはできました（顧客の中には shapefile 形式で欲しいと言ってくるところがそこそこあります）。もともと、道路網をモデル化すれば一次元複体を採用するのは自然なので、データ形式も shapefile と相性の良いモデルになるのは当然だとも言えます。
であれば、うちのデータも .pbf に変換してネットアクセスできるようにすればいいのではないか。こう思い至ったのが９月のことでした。
ベクトルタイルになった地理院地図を QGIS でアクセスしてみて分かったことは、
- ポートが開いていなくてもアクセスできる
- 基本的に readonly なので、サーバ側もクライアント側もセキュリティを維持しやすい
- shapefile や PostGIS とは異なり、レイヤを初心者が簡単にはローカル保存できない（つまり、不正コピーを作るのがそれだけ難しい）
というような特徴があることです。QGIS もビュワーとしては使えるが、編集やローカル保存ができない形で公開できるということですね。
これ、著作権を放棄せず、有償で見せているデータについて、単に閲覧に供するためだけの保持の仕方としては結構使えるのではないかと思いました。言い換えると、利用者に特別な利用権限付加の動作がいらないということです。
これでは再利用が難しいという声はあるかも知れませんが、再利用したい方（それなりに再利用に必要なスキルを持っておられる方）には、従来通り有償で加工しやすい書式で提供すれば良いだけのことです。これまでは、そういう方には、昭和以来の固定長書式ファイルの他に、shapefile でも提供してきましたが、今後はアクセス権限を設定して PostGIS へのアクセスも認めるようなことも考えられます。
ベクトルタイルのビュワー
ベクトルタイルを見る場合は、QGIS 以外のビュワーがある方が便利です。
多くの人に（権限を気にせずに）見てもらおうと思うならば、地理院地図と同様にウェブサイトから見えることがもっとも自然です。幸い、地理院地図Vector のサイトは fork 可能ですので、これを fork して、デフォルトで最初にアクセスする .pbf の url をウチのベクトルタイルになるように調整することとしました。地理院地図が「他機関の情報」として「著作権を尊重しつつ他機関の情報も閲覧下さい」としていることと、本質的には同じことです。ですので、（2021.12.11 時点ではまだ公開していない）ウチのサイトも、地理院地図（ベクタだったり、ラスタだったり）を重ね合わせ表示できるように作ろうと思っています。地理院地図タイルが比較的オープンなライセンスを採用してくれているので、こういうことが合法的に実行できます。
API
本家の地理院地図の場合、サイトの画面の右上にドロップダウンメニューがあって、そこから「距離計測」とか「簡易作図」のような機能を呼び出すことができます。
デジタル道路の場合、道路管理者だけが必要とするようないくつかの機能を実装する必要が出てきます。これらの機能は、DB に対する API として実装することになるわけですが、ビュワーが Webサイトなので、WebAPI として実装し、機能は場合によってはサイトのドロップダウンメニューから「距離計測」等の同等の UI で呼び出せるようにするのが良いだろうと考えています。
このあたりは、想定利用者のスキルレベルを低めに設定して（QGIS をすぐには理解できないような人たちだと見なして）考えています。
地理院地図にもない機能として、３年前と現在で道路網の形状が異なる（新設された道路があって、グラフ構造として対応の付かない場所がある）場合であっても、正しく対応が取れることを保証するための API を、データ構造付き（付加情報を設計する）で用意しようと考えています。これは実は結構大がかりな作業で、これがあるためにこの記事を書いている時点でまだお見せできるサイトが存在しないのです。このあたりも、昭和期に初期設計をした時点ではハードルが高すぎて実装できなかったのだろうな、と思っています。
ベース･レジストリとして？
ベース･レジストリとして考えた場合、データの修正要求は誰でも提出できると思いますが、データの修正権限は限られた一部の人にのみ与えられることになります。仮に、性善説に立って、悪意ある修正要求が出てこないものと考えても、善意＋誤解による誤った修正要求が出てくることには対応が必要で、それを提出者の責任に帰すのは無理です。ベース･レジストリと Wiki 系のデータとは、そこが決定的に異なると考えます。
ウチのデータは、これからはベース･レジストリ的な方向に向かうと考えています。ただ、こちらも道は平坦ではなく、公証性を求められることも将来は想定しなければなりませんし、網羅性や即時性（情報セキュリティ的には可用性と完全性）をどこまで保証できるのか（現時点では最高レベルではないので）といった課題も解決が求められるようになるのかな、と思っています。
ベクトルタイルの採用は、ベース･レジストリを目指す（かもしれない）レベルのデータが、著作権を維持したままで高みを目指す基本的なツールになりそうだと考えています。ウチのシステムは、これまで30年以上も安定運用してきました。これからも何十年か安定運用を続けるために、最先端の技術ではなく、少し枯れた技術を確実に導入して行きたいと、情弱な私は考えています。
このあと
このサイト（Qiita ではなく、私のはてなブログ）で過去記事として書いているように、一次元複体として記述している道路のネットワーク構造から、車線別構造を自然に定義したいと思っています。
ISO/TC204 では、GDF5.1 が既に International Standard になっており、現在は GDF6.0 が検討フェーズに入っています。しかし、ISＯ/TC211 から見た場合、必ずしもベストな書き方になっていないかも知れない、として指摘も頂いている状況です。
私の中では、この問題はアイデアレベルでは解決済みで、
- 道路網が一次元複体の構造を持つこと自体は多くの人が認めている
- 自動車道に限定すれば、その一次元複体は一回連続微分可能であるという仮定を付加しても問題ない
- すると、道路網は単連結ではない一次元多様体の構造を持つ、とも言える
- 微分多様体なので、至る所に管状近傍が定義できる（定義可能範囲は、大雑把に言って、道路の最小曲率半径以内のエリアである）
- この管状近傍の概念を使えば、車線は元の道路網と数学的に整合する形で定義できる（誰もまだやっていないようだが）
- 道路中心線が基本となる多様体で、車線境界は法ベクトルバンドル（道路の言葉で言う「横断面」）の滑かな切断として与えられる。
- 車線の分岐合流は、車線を二次元の位相多様体と見て、接着写像で与える
ということを定式化（ISO/TC204の言葉で記述）すれば良いのだろう、と思っています。ただ、私の数学力と根気では、構想倒れに終わる可能性も高そうです。
それより前に、DB の原本を PostGIS に移行して、編集もその上で GIS で行えるようにする方が先かな、と考えます。昭和のレガシーを、当時の人の偉業はたたえつつも、今の手法に地道に置き換えることがより重要なわけですね。
