見出し画像

PLATEAUの属性データに任意座標系のデータをぶちこんでやるぜ!!

はじめに

PLATEAUには大きく分けてCityGMLのような属性を持つデータとFBXやOBJのような3Dモデルが存在します。

3DモデルはUnity等で扱いやすいため多くの人がこちらを使った開発をされています。

しかしPLATEAUの本質はCityGMLにこそあります!

FBXなど花拳繍腿!! CityGMLこそ王者のデータよ!!!!

とはいえCityGMLの属性データもそんなに使えそうな物が入っているわけでも有りません。

建物の高さや屋根の面積、建築年度等は入っていますが、それらをポンと渡されて「こんな新規性のあることができるぞ!」となる人はそうそういないと思います。

そこで私はCityGMLに無い情報を様々なオープンデータ等から引っ張ってきてぶちこんでいます。

そうすることでPLATEAUを高精度な箱として、新たな使い方が生まれます。

ですがぶちこむにしてもPLATEAUの元々あるデータと新たに追加するデータの関連性を持たせるために共通のキーで紐付ける必要があります。

多くの場合はPLATEAUの持つ経緯度等の座標値で紐づけが可能です。
しかし座標値での紐づけができないケースがあります。

それが任意座標系です。

座標値は座標系によって定義が異なるため、異なる座標系のデータ同士を紐付けるには座標系をどちらかに合わせる必要があります。

多くの場合は座標系の変換式があるため変換可能ですが、任意座標系には変換式が存在しません。
したがって任意座標系を公共座標系等に変換するのは非常に困難なのが現状です。

では、なぜ任意座標系の変換は困難なのでしょうか。

任意座標系の問題点

任意座標系を含むデータとして有名なものが、法務省の持つ登記所備付地図データです。

このデータは、登記に付属する土地の境界線を明確にする為のデータです。

このデータはこれまで一般公開されてませんでしたので、任意座標系についてはごく一部の人間だけが認識していた課題でした。

しかし2023年にオープンデータとして公開された事で多くの人々が容易に利用可能となり、任意座標系に苦しめられる人が増加しました。

ここではこの登記所備付地図データをベースに問題点を示します。

原点がわからない

任意座標系の原点は基本的に不明です。
しばしば任意座標系と対となって現れる公共座標系(平面直角座標系)は、全国19箇所に原点を置き、各地の座標を原点からXYで表します。

しかし任意座標系はこの原点がわからないため、仮にx=100, y=100のデータだったとしても、どこからX軸に100mなのか、どこからY軸に100mなのかがわかりません。

情報の品質が低い

下図の上段左にあるパズルのようなものが任意座標系のデータです。
これらは本来下図下段のようになっているべきですが、分離してしまっています。

https://ascii.jp/elem/000/003/552/3552522/img.html

また下図の場合は、青線が任意座標のデータですが実際に位置合わせをしてもデータとしてズレていたり、境界線が合わなかったりと品質が悪いと言わざるを得ません。

まあ明治とかに作られたものだったりするので品質を批判するつもりはありませんが、下図の場合だと上図のようにパズルを組み立てるような紐づけは難しそうです。

https://www.geosense.co.jp/wp-content/uploads/2023/02/2023-02-10_12h00_05-966x1024.jpg

任意座標データの紐づけに関する既存手法

これまでにも多くの人々が任意座標系の紐付けをしたいと試行錯誤してきました。

それらを含め、既存の紐付け手法を例示します。

人間目視手作業による位置合わせ

言わなくてもわかりますよね。
データの特徴を見ながら、既存の地図と照らし合わせてここかなーとかやる手法です。
これを真面目にする人はよっぽど暇人でしょう。

形状特徴に着目した手法

下図は再掲ですが、NTTデータが開発したサービスとして公開されています。
こちらはいわゆる形状特徴を使ったパズルの組み立てのような手法です。

AIを使うかどうかで精度が変わるかとは思いますが、基本的に辺や角、交差、または交差の角度などを用いたマッチング処理による紐づけ手法です。

いわゆる幾何的なアプローチとして、人間が行っている思考に最も近いと考えられるため、自動化の手法ではまず最初に思いつくアプローチでしょう。

地番等による突合

任意座標系の公共座標系変換には座標だけでなく、他の情報を活用した位置合わせが考えられます。

最も容易に思いつく手法としては、地番の突合によるデータ間の紐付けです。

しかしながら地番による紐付けは文字列突合となるため、「東京都千代田区千代田1−1」と「東京都千代田区千代田一の一」では単純比較ができません。そのために地番の変換ライブラリなどが整備されつつありますが、表記ゆれがあまりにも膨大なためあまり進んでいないのが現状です。

今回の手法

今回はPLATEAUのCityGMLに登記所備付地図データ(任意座標系)の情報を機械的にぶちこむために行った既存手法には無い新たな手法について解説します。

着眼点

既存手法のように、形状特性や地番等を使ったマッチングを行う場合、任意座標系データの精度に依存します。

しかし前述した様に品質が悪い為、そのまま使用しても限界があります。

そこで本手法では、任意座標系データの形状特性ではなく位置関係に着目し、公共座標系のデータであるPLATEAUとのマッチング手法について提案する(だんだん書き方が論文チックになってきた)。

環境

端末 M1 MacBook Pro 16GB
言語 Python

用意するデータ一覧

  1. PLATEAU(CityGML)

  2. 登記所備付地図データ(任意座標系)

  3. 農地区画情報

※全てオープンデータ

概要

本手法では、登記所備付地図データ(以下、地図データ)の形状は不正確であると前提の下、公共座標系であるPLATEAUを正とし、任意座標系である地図データの座標を補正し、対応するPLATEAUに地番を追加します。

なお、地図データ内に存在する「地番」をPLATEAUにぶち込むことを目的とする為、地図データの形状補正は行いません。

データ特性

まずは今回使用するデータの特性を見てみましょう。
今回はわかりやすくするために両データとも千代田区のデータに絞っています。
さらに(解説の都合上)わかりやすくするために、対象の領域を東京都千代田区一番町にしたいと思います

1.PLATEAU

以下はQGISで表示したものですが、使えそうな情報としてaddressがありますね。
それ以外では、QGIS上には出てませんが内部でポリゴンの経緯度を持っています。

PLATEAUをQGISで表示して属性データを表示した

2.地図データ

地図データは地区町村名や座標系、原点からのXYがメートル単位で入っています。

登記所備付地図データの中身

上記に加えて、地番まで含まれています。
今回はこれをなんとかしてPLATEAUにぶちこみたいわけです。

登記所備付地図データの中身

GISで表示させるとこんな感じ

GISに入力した地図データ

手法解説

本手法の大まかな流れは以下のとおりです。
なお、細かいデータ変換については割愛します。

  1. 領域限定

  2. 次元削減

  3. 特徴量抽出

  4. 特徴点マッチング

流れの各項目について解説します。

1.領域限定

今回の取り組みは自動化を対象としているため、全国のPLATEAUに地番をぶちこんでいく前提で考えました。

その場合、日本全国のPLATEAUのポリゴンに対して網羅的かつ総当たり的に処理を行うと莫大な計算コストがかかります。

したがって、ある程度領域を絞って機械に「ここの範囲内に対象がいるから範囲内で処理してねー」と指定して上げる必要があります。

その処理がこの領域限定です。

領域限定自体は簡単で、PLATEAUの区市町村コード、大字・町コード、町・丁目コードと地図データの市区町村コード、大字コード、丁目コード、大字名等使えば何丁目レベルまで限定可能です。

例えば、上記のようなPLATEAUの各コードから導出した「東京都千代田区一番町」と地図データの各コードから導出した「東京都千代田区一番町」という文字列を突合して領域を限定したら、これだけでも任意座標の地図データは「東京都千代田区一番町」あたりにまで持っていけます。

本来この処理のアウトプットはプログラムの内部的に持っておく処理ですので、実際には地図的な処理はしません。
ですが、今回はわかりやすくするために以下にGIS上に表示させます。
ちなみにたざ経緯度を変換しただけではスケールが合わないので、スケールをあわせる処理が後々必要になります。

ここではスケールは調整せずに、PLATEAUからランダムで抽出したポリゴンの頂点座標に合わせました。

地図データを公共座標系に持ってきたイメージ

2.次元削減

領域を限定したら、次は詳細なマッチング処理をするための前処理です。
前処理にはいわゆる次元削減という、不要な情報を削ぎ落とす処理です。

ここでいう不要な情報はポリゴンの形状です。
既存手法でもポリゴンの形状を利用したマッチングアルゴリズムは存在しますが、そもそも地図データの形状は品質が悪いため、それを用いたマッチングも自ずと品質が悪くなります。

じゃあ悪いものは削りましょうってことで形状は捨てます。

捨てると言ってもただ捨てるだけではありません。
今回の手法は形状ではなく位置関係でのマッチングですので、ポリゴンの中点を算出します。
なお、中心点ではなく中点であることが重要であることを強調しておきます。

中点(一部)を黄点でプロットしたイメージを以下に示します。

3.特徴量抽出

次に各中点の位置関係をベクトルで算出します。
ベクトルについては距離、角度(方角)等が中点の特徴量として格納されます。

これについては中点全てに処理を実行するため処理としては重めですが、精度に影響するため確実に行う必要があります。

同じ要領でPLATEAUの方も中点を算出し、特徴量を抽出しておきます。

4.特徴点マッチング

特徴点マッチングでは、PLATEAUと地図データから算出した特徴量を含む中点(特徴点)をマッチングさせます。
今回は類似度の計算にコサイン類似度を用いたました。

紫点がPLATEAUの特徴点、黄点が地図データの特徴点です。
このように、特徴点の位置関係を計算してマッチングを行うことで、公共座標系と任意座標系の紐付けが可能になります。

なお、今回実装した処理はすべてデータ上ものなので視覚的にわかりやすい様にGISに頂上したりしてイメージを作成しました。

以下はマッチングした一点を軸にデータをそのまま重畳した際のイメージになります。
これを各点個別に行います。

特徴点マッチング処理によって、PLATEAUと地図データをマッチングしたイメージ

実際の処理は、マッチングした各点同士で紐づけを行い、以下のようにPLATEAUのポリゴンひとつひとつに地番をぶちこんでいます。

PLATEAUに地番を追加した

まとめ

今回はPLATEAUに任意座標系である地図データの地番をぶちこむ方法を解説しました。

精度についてはまだまだ改善の余地がある上に、紹介しきれなかった課題として、PLATEAUはあくまでも建物ベースで地図データは土地ベースである点で厳密な紐づけの正確性を最終的に確認するプロセスが必要な点が挙げられます。

精度については、特徴量のひとつに「地目」があると精度が飛躍的に向上すると考えています。

地目はオープンデータとして存在しませんが、登記情報としては持たれているため、法務省の登記事項要約書等を使えば地目を特徴量として組み込むことが可能と考えられます。

こちらは国交省さんと法務省さん(あとはデジ庁さん?)の官官調整で実現してもらえないかな―とか思ってみたり。

とりあえず、今回はアルゴリズムの詳細な内容等は省いて(それを説明するにはNoteでは余白が足りない)処理フローベースで解説しました。

この記事が気に入ったらサポートをしてみませんか?