私の開発している古地図絵地図アプリMaplatですが、Maplatリリース0.5.2以降、MaplatEditorリリース0.3.2以降で、「線を線に変換する」機能に対応しました。
どういうことかというと、これまでのMaplatは古地図と正確な地図の対応を、例えば交差点と交差点というような点と点の対応づけで定義してきました。
が、当然複数の交差点と交差点の間にはそれを結ぶ線としての道があるわけですが、正確な地図上での道を歩いても、その変換結果が対応する絵地図側の道にぴったり乗ってくるとは限らないという問題がありました。
具体的には、英語の発表資料からの引用ですが下の図のような状況になります。
Maplatでは対応点群が与えられた際に、自動でその対応点を用いた三角網が計算され、その三角網内でのベクトル演算で座標変換が計算されます。
その変換手法の特性上、三角網の辺上の点は正確に辺上に変換されるので、偶然対応点間の道路に三角網の辺が重なればその道路は正確に変換されますが、もし道路が三角網の辺と交差してしまった場合、その道路上の変換は正確に変換されない可能性がある、という問題がありました。
新しい機能では、それを以下のような手法で解決しました。
道路のような線の上に定義する、2つの対応点を結ぶ対応線という概念を導入しました。
この対応線は、対応点から三角網を生成する際に、必ず辺として採用されるようにしました*1。
なので、この対応線上の点は、正確にもう一方の地図の対応線上に変換されるようになりました。
これだけだと直線を直線にしか移せないのですが、もう一歩進んで、一方または両方が曲線だったりしても対応づけができる方法を考えてみました。
曲線(Polyline)の場合の問題点は、三角網の辺は当然直線しかなり得ないので、Polylineの曲がる頂点は必ず三角網の頂点、つまり対応点にせざるを得ないのですが、対応点にしようにももう一方の地図の方で対応する点が定義できないことでした。
それを、対応線の長さに対する割合に応じてもう一方の地図の対応線上にも補助対応点を定義することによって、Polylineでも三角網が定義できるようにしました。
これにより、複雑な現実の道路形状が古地図や絵地図上で抽象的に描かれているようなケースでも、道路の上を道路の上に対応づけることが可能になりました。
もちろん、いい事ばかりではありません。
Maplatには線を線に変換する以外にも、三角網でトポロジーエラー*2が発生しないようにデータを作った場合に限り、地図間の座標変換で全単射変換を保証するという特徴がありました(全単射変換については下の資料のページ28以降参照)。
www.slideshare.net
ところが、対応線を導入した場合、特に曲線の対応を導入した場合、構造の複雑さにもよりますがトポロジーエラーを発生させないようデータを制御するのが難しくなり、全単射変換を保証できるデータを作りにくくなってしまいます。
これについては、元々全単射変換を保証しないといけないような地図の種類と線から線に変換を保証しないといけないような地図の種類は異なると思うので、それほど大きな問題にはならないと思っています。
今回、この機能を使って何か実証アプリ的なもの作れないかなあと考えていたところ、最近GIS仲間周りで話が盛り上がってるバスロケーション共有仕様のGTFS周りで何かできないかなと思い、宇野バスのGTFSなどオープンデータと路線図を用いて、宇野バスの経路表示とバス運行情報表示アプリを作ってみました。
このような線を線に変換する機能、あるいは以前からの全単射を保証する機能は、Maplatの類似技術であるStrolyでは、原理的に将来にわたり絶対に実現できない機能になります。
何故ならば、StrolyもMaplatと同様、地図間の座標変換に対応点の作る三角からのベクトル変換を用いていますが、その三角の決定に、Maplatは実績あるGISの知見を取り入れて三角網を生成しているのに対し、Strolyは変換対象点の近傍の対応点3つを選び、それの作る三角形からの変換を行なっているからです。
あらかじめ生成された三角網で変換するのではなく、都度都度選択される近傍点での変換のため、Strolyはどの点をどの対応点のセットで変換するかということを意図的に制御するのが極めて困難です。
全単射変換を維持するために変換前後の地図のトポロジーを維持したり、線を線に変換するために、この道路上は必ずこの三角の辺を使って変換する、ということを定義することがほぼ不可能です。
よってこれらの機能の優位性は、未来にわたり、StrolyではキャッチアップできないMaplatの絶対優位性と見ていただいて問題ないと思います。
また、今回の宇野バスアプリは、線を線に変換する機能以外にも、いくつものMaplatの対Stroly優位性のある機能を使って実現しています。
まず、バスの運行情報をGTFSから取ってきて地図上に表示するには、地図をUI表示なしで表示して、動作をAPIで制御する必要がありますが、そのためにはまず地図表示をiframeによる擬似埋め込みではなく、divタグによって本当にhtmlページの一部に埋め込めないといけません。
何故なら、iframe埋め込みだと、親ページからの制御を読み込まれた子ページに与えることが、セキュリティの制限によって実現できないからです。
しかし、Strolyはiframeでのページ埋め込みにしか対応できていません。
また仮にiframeでなくdivでの埋め込みに対応していたとしても、StrolyにはUI以外に、外部から制御できるAPIがありません。
そのため、何か表示内容を変えようと思うと、手作業でエディタでデータの内容を変更しなければいけなくなります。
実際、過去に「ホリエモン祭」で会場地図としてStrolyが使われた際には、担当者が常時手動でホリエモンの位置を更新していたようです。
場所に困った時はこれにアクセス😍
— ホリエモン祭【公式】7/5inパリ (@hori_fes) 2019年2月1日
当日はホリエモンの位置情報も終えるようにします✨✨
ホリエモンの位置情報手動なので更新頑張ります！！https://t.co/hdSvfUpdp1
Maplatだと、宇野バスアプリでバスの運行位置を常時更新できているように、APIでピンの表示位置や状況を変更できるので、ホリエモンの現在位置を常にサーバか何かに送りつけるシステムさえ作っておけば、あとはシステムが勝手に現在位置を更新してくれるシステムだって作れます。
また、バス路線ジオメトリを表示するために使った線を引く機能も、Strolyにはない機能です。
MaplatではAPIで地図上に線を引くことができますが、Strolyは手動、APIを問わず線は引くことができません。
このように、StrolyにあってMaplatにはないWeb上での利用が簡単なエディタ機能は確かにStrolyの大きな魅力ではあるのですが、それ以外ではもう様々な機能でStrolyはMaplatのはるか後ろを走っている状態です。
ちょうど1年くらい前にこのブログに書いた記事では、まだMaplatもいろいろ機能の不足があったため、「StrolyとMaplatは一長一短、使い分けて」と書きました。
が、その後1年を経てMaplatには数々の機能がつき、1年前にStrolyにMaplatが劣っている短所として書いた「1つの画像に複数の地図が共存可能」も既に開発済みで解消され、「StrolyがMaplatに劣っていること」は山のようにある一方で、「MaplatがStrolyに劣っていること」はもうWebエディタがあること以外にはない状態です。
クソほど劣った技術だけれど、Web上だけで簡単に導入できることに魅力を感じる一般ユーザを除いては、システムの一部や機能の一部として業務用途に使いたいユーザにとって、これからStrolyを採用する理由は微塵ほどもありません。
ぜひ、これを機にMaplatに興味を持って、使っていただければと思います。
最後になりますが、Maplatで少額募金や企業からの募金支援を受けやすくしようと、募金サイトOpenCollective
でMaplatのアカウントを作ろうとしましたが、githubのオープンソースプロジェクトだとスターが100以上稼げているプロジェクトでないとアカウント作成可能対象にならないようです。
現在58スターなので、あと42スター稼ぐ必要があります。
githubでアカウントお持ちの方、ぜひご協力いただければ幸いです（スター返しなどもお引き受けします）。
スターつける対象のプロジェクトは以下の通りです。
よろしくお願いいたします。
