Code for History

"Code for History"はIT技術を歴史学上の問題の解決に使うコミュニティです。強調したいのは、我々にとってIT技術は「手段」であって「目的」ではありません。「目的」は歴史学上の問題を解決する事であって、必要であればITでない手段も活用します。常に最優先なのは、問題を解決することです。

バズったので宣伝:古地図、絵地図で街歩きできるサイトを作れるオープンソース、Maplatをよろしくお願いいたします。

バズったので宣伝文化に則って、私の取り組んでいる古地図、絵地図で街歩きできるサイトを作れるオープンソース、Maplatを宣伝させてください。
え、バズって宣伝はTwitter文化でブログではそんなのない?知らんわそんなんこっちは認知あげるのに必死やねん(まず読者を敵に回すスタイル)。

Maplatって何?と思う方は、まずご自分のお好きな街バージョンのMaplatのサイトを一度見てみてください。
特に、アニメ「宇宙よりも遠い場所」のファンの方は、館林バージョンを見ていただくと、よりもいの巡礼マップが含まれているのでオススメです!

s.maplat.jp

s.maplat.jp

s.maplat.jp

s.maplat.jp

s.maplat.jp

雰囲気わかったでしょうか?
絵地図や古地図が、現代地図の上に重なって表示されたと思いますが、右下および左下にスライダ表示されている他の地図のアイコン(左のスライダが正確な地図、右のスライダが不正確な古地図や絵地図になります)をクリックいただくと、正確に測量された地図でないにも関わらず、他の古地図や絵地図、正確な地図などに対応する点がぴったり重なって切り替わったのではないかと思います。

f:id:kochizufan:20190325222320p:plain
不正確な地図でもぴったり重なって切り替わる様子
単に切り替えられるだけでなく、画面中央下の方に表示されている透明度変更スライダを動かしていただくと、現在表示されている古地図絵地図と背景の正確な地図との間で、透明度を切り替えて重なり具合を比較することもできます。
また、現地にいる場合のみですが、左上のGPSボタンを押すと、不正確な地図の上でも現在地の青いGPSアイコンが表示されます。
f:id:kochizufan:20190325232416p:plain
不正確な地図の上でもGPS現在地が表示できる
このような、古地図絵地図と正確な地図とのぴったり重なる切り替えや、古地図絵地図上への現在地の表示によって、その場所が昔どのようであったのか、その時代にタイムスリップしたように街の昔を知ったり、一般地図のように無機質でない、街の魅力にフォーカスした絵地図で街を探検したり、そんな楽しみ方ができるアプリを作れるオープンソースライブラリがMaplatです。
まだまだあまり知られていないライブラリですが、地味に、国土交通省が毎年行なっている「Geoアクティビティコンテスト」というコンテストの2018年度で、史上初の三冠(最優秀賞、教育効果賞、来場者賞)をいただいた実績もあったりします。

www.g-expo.jp

実は似たような古地図街歩きを実現できるサービスは世の中に存在しており、京都のベンチャー企業であるStrolyという企業も、似たようなソリューションを実現しています。

www.youtube.com

というか、実は私自身、元はStrolyの前身だった会社に勤めており、Strolyの開発に従事し、Strolyが保持する特許のうち、地図の中心点の座標を合わせる特許は私以外の人の発明ですが、それ以外の機能をカバーする特許は私の発明だったりします。
その私が、Strolyを退社したのち、Strolyとは異なるやり方(これも特許出願中です)で、Stroly以上の性能、機能を実現するライブラリを、オープンソースで開発したのがMaplatになります。
Maplatの主な機能の列挙、およびStrolyとMaplatの性能、機能比較は「Geoアクティビティコンテスト」時のポスターとして作成した下記のチラシにまとめられています。

drive.google.com

主なところを抜き出しますと、まず性能的な違いとして、Strolyは連続して複数の地図を切り替えた場合、元の場所に戻ってくることが保証されていませんが、Maplatは元のところに戻ってくることが保証されています。
下記は格子状の古地図上の点を経緯度に変換してから再度絵地図上に戻した結果で、黄色がStroly、暗い赤色がMaplatでの変換結果を表しており、当然格子状に戻ってきた方が変換性能は優れていることになりますが、見ればわかります通りStrolyの変換は相当にバタついています。

f:id:kochizufan:20190326002334p:plain
格子状の古地図上の点を経緯度に変換してから再度絵地図上に戻した結果、黄色がStroly、暗い赤色がMaplat

また、別の性能差として、Maplatでは記事の冒頭に紹介したいくつかのサイトで体験いただいた通り、不正確な地図でも正確な地図とぴったり重なって切り替わる体験ができますが、Strolyでは正確な地図に切り替えても地図がぴったり合わないという差があります。
Stroly側の実例ですが、以下のサイトにアクセスして、右下の地図切り替えボタンで地図を切り替えてみてください。
地図の中心点はあっていますが、海岸線がぴったり合わない、すなわち地図がぴったり変換できていないのがわかると思います。

stroly.com

f:id:kochizufan:20190326000634p:plain
Strolyは古地図と現代地図を切り替えてもぴったり重なり合わない
実はこれは、Strolyも本来はぴったり重なり合わせることができる特許(まさに私の在籍中に私が発明した特許ですが)を持っており、その特許を正しく実装できていればこのような事にはならないのですが、技術者の流出でStrolyは自社の持つ特許を正しく実装できなくなっており、その結果このような状況になっています。
なので性能差というよりは本来はStroly側のバグというべきものですが、もうバグの存在が判明してから4ヶ月も修正できていないので、もはや性能差と言って差し支えないと思います。

また、Stroly側で地図を切り替えてもらえばわかったと思いますが、相当に切り替えがもっさりしていると思います。
きびきび地図が切り替わる、なんなら同時に表示されてリアルタイムで重なり合ってるMaplatと比較すると大きな反応速度差だと思いますが、これも性能差に含まれると言えるでしょう。

続いて機能差ですが、以下に現状の機能差一覧表を示します。
一部、すでに説明済みの性能差も含まれていますが読み飛ばしてください。

f:id:kochizufan:20190326001656p:plain
StrolyとMaplatの機能差一覧
これは残念ながら、現時点でStrolyの方が優れている部分もあります。
Strolyはサービスとして展開しているので、オンラインで地図エディターが展開されており、地図のエディットが完了すればすぐ地図コンテンツとして提供できるのは大きなStrolyの利点でしょう。
Maplatはライブラリなので、ライブラリの設定ファイルの設定方法など、いろいろ面倒臭いことを覚えてもらわないと地図コンテンツを提供することはできません。
しかしながら、オンラインエディタでサービスベースのStrolyの利点は、同時に弱点でもあります。
Strolyはインターネットに繋がらないところでは動作できませんが、Maplatはイントラネットだろうが、localhostだろうが、設定さえそれに合わせて行われていれば動作します。
StrolyはStroly社の持つドメインの上でしか動作しませんが、Maplatは独自ドメイン上だろうが自社サーバのサブディレクトリ上だろうがどこでも動作します。
Strolyは他のページに埋め込む場合、iframeでページを読み込む方法しかないですし、APIで挙動を操作するなどもっての他ですが、Maplatはページ内のdivに埋め込むことができ、JavaScriptAPIで視点を変えたり地図を回転させたり縮尺を動かしたり、自在に外からAPIで制御することもできます。
なんならMaplatはAndroidiOSのネイティブアプリ内に埋め込めるaar/frameworkライブラリも用意していますので、ネイティブアプリとして古地図アプリを開発するエンジンにすることも可能ですーー実際、京都の開発会社のコギトさんというところが、ambula mapという名前のアプリを、Maplatをエンジンにして作ってくれています。

ambula.jp

このように、Web技術に喩えるならば、Strolyはブログサービス的なものなのに対し、MaplatはWebサーバ(Apacheやnginx)のようなものと言えるかもしれません。
Strolyは出来合いの簡単サービスで、グラフィカルに編集すればすぐに地図を公開することができるが、決められたこと以上の事は全くできません。
それに対し、Maplatは設定ファイルを設定しないと地図を表示できないが、設定さえ使いこなせば、イントラネット環境、モバイル連携、API操作等、好きなように動作させることができる万能プレーヤーです。
これが機能的なStrolyとMaplatの大きな違いです。

とはいえ、やはり設定を覚えたりするのは大変、オンラインエディタで簡単に編集できた方が楽そう...そう思われるのは全くもっともです。
そういった声に応えるため、実はこれを公に宣言するのは初めてなのですが、一気に機能比較表の中でStrolyに現状劣っている部分を全て潰すべく、Maplat側も編集即パブリッシュができるオンラインエディタを開発したいという気持ちがあります。
とはいえ相当規模の大きい開発ですので、私一人の趣味の余暇の開発で完結するレベルではなさそうなのですが、クラウドファンディングで資金を調達し、それを元にマンパワーを費やして開発したいと思っております。
諸般の環境が揃うのを待つ必要があるため、今すぐ着手、ではなくおそらく今年後半以降くらいからのクラウドファンディング開始になると思いますが、ぜひ開始した際には、ご支援いただけると嬉しいです。

このように、大企業Stroly(Strolyはベンチャーながら、すでに5億円超の投資を集めています)相手に、技術力と機能などの企画力、オープンソースオープンデータの道義的?優位を武器に、圧倒的資金差、知名度差をのりこえて、たった1人徒手空拳で戦っているのが、オープンソースMaplatライブラリになります。
ぜひ興味をもって今後ともウォッチいただけると嬉しいです!
それでは、Maplatライブラリに興味を持った人が、どのように使い始めればいいのか?
そういった入門編的な記事は、長くなりすぎますので近いうちの後日に回す形として、今回はご紹介まででした。

ZENRINを廃した新Google Mapsは自動運転とは基本的に関係がない

2019年3月21日、突然姿を見せた日本でZENRINを廃した新Google Mapsは、一部で見られた地図の劣化とあわせ、驚きをもって受け止められました。

www.itmedia.co.jp

それと同時に、今回の新Google Mapsの変化が大きく道路形状などに現れたことを受けて、

  • 今回の新Google MapsでZENRINを切った理由は、建物重視のZENRIN地図から、自動運転を見据えた道路中心地図への転換を意図したものだ

という意見が多く散見され、また高い評価を受けたりしているのを見ました。
一例を挙げるならば、(このツイートの投稿者さんには指摘をして理解いただき、意見交換などもできたので決して晒す意図ではないのですが)以下のツイートなどです。

ですが、いろんな視点でこれらの意見は的を外しています。
いくつかの視点を提示して、検証してみたいと思います。

1. 新Google Mapsの更新はプローブデータで行われている。そして、プローブデータでは自動運転精度の地図は生成できない。

Google Mapsはどうやって整備されているか?
Googleカー的なものを頻繁に走らせて日本中の道路を網羅整備していっているのか?
もちろん、Googleカーの走った道路もあるので、それをソースに作っている箇所もあるでしょう、それは否定しません。 が、駐車場が道路になってしまった!というような以下のような報告を見ていただければ、明らかにメインのデータソースは、Googleが誇る当代有数のプローブデータから機械学習などにより生成されたものだとわかります。

プローブとは、システムから見て現実世界をなぞる探針になるようなものの総称で、例えば車の車載器からネット経由であがってくる位置情報や車の様々な運転状況情報、人の持つスマホからの位置情報や動態センサー情報等、ネットに繋がって情報をあげてくるあらゆるものがプローブになり得ます。
Googleは、多くのAndroid端末と、またAndroidでなくともGoogle Mapsアプリを配布していることで、当代有数、おそらく世界一レベルのプローブを現実世界に展開している企業です。
それらのプローブからの情報は、1つ1つは位置測定誤差が大きくてそのままでは使えなくとも、何千何万というデータを重ね合わせて機械学習と組み合わせれば、道路の形状を検出することが可能です。
この仕組みを使って、新Google Mapsは独自の道路地図を実現し、ZENRINの採用を停止したという形です。
先に紹介したコンビニ駐車場が道路になってる事例などは、たくさんプローブが通過したところを道路として誤判定した結果といえます。

では、このプローブデータを使って、自動運転ができる規模の地図が生成することはできるでしょうか?
答えは、(少なくとも現時点は)不可能です。
次の動画を見てみてください。

www.youtube.com

これは某弊...ぐほっ...某自動運転向け地図を開発している会社が、自動運転向け地図の技術的説明をした動画です。
動画中でも、自動運転地図では、単に道路のあるなしだけではなく、車線の数や位置の情報まで、10cm〜20cm精度で整備されることが求められ、さらに周辺のガードレールやロードサイン、標識などの構造物の位置まで、同程度の精度で整備されることが求められています。
このような精度での車線特定や周辺構造物の取得は、現在Googleが持つプローブ情報がいかに膨大なものであろうと、それだけでは取得することはできません。
スマホの数10mの誤差がある位置情報をいくら膨大な数集めても、この道路に何車線あって今はどの車線を走っている、という付加情報も取れるわけではない状態で、10cm〜20cm精度の自動運転向け車線モデルを生成することは、現状無理と言っていいと思います。

自動運転関連技術で、プローブが全く役に立たないわけではありません。
道路の渋滞情報は今でも普通にプローブから生成されています(これはGoogleだけでなく、競合会社も同様です)し、目の前で起きた事故や局地天気(車のワイパー稼働やフォグランプ点灯状況など)などの情報をプローブから収集し、後続の自動車にアラートとして送るような技術の動きもあります。
自動運転向けの正確な車線情報や周辺構造物情報が正確に取得されてる地図が先にあるのを前提に、車線が変更になった、現在一時工事中で車線閉鎖、などの修正情報だけ、周辺構造物の位置と変化地点との位置変化をプローブからクラウドに共有することで、ダイナミックに自動運転用地図を修正する仕組みも検討されています。
ですが、その前提となる大元の正確な自動運転用地図は、現状まだ、全天球カメラやLiDER、高精度GPSを装備したGoogleカーのような車を走らせることによってしか取得できません。

その意味で、今回の新Google Mapsが自動運転を見据えた変化、というのはかなり的を外しています。

(追記:3/24 23:20)
よい指摘をいただいたので追記してみたいと思います。

ZENRINを廃した新Google Mapsは自動運転とは基本的に関係がない - ちずぶらりHackers

Google mapsが今後改善されてゼンリン並になったら自動運転に耐え得るでしょ。何で切り替え直後の一番ダメな状態を見てそれがプローブデータに頼ってるからって「自動運転を見越したものではない」と言えるのか分からな

2019/03/24 23:08
b.hatena.ne.jp

Google mapsが今後改善されてゼンリン並になったら自動運転に耐え得るでしょ。

これは明確に、ならない(よっぽどこれまでとは全く違う発想の自動運転手法を現時点で確立したのでなければ)という回答になります。
なぜなら、ZENRINさんや私の会社含め、どこの会社も、地図表示やナビ用の地図と、自動運転用の地図は、明確に別の作り方をする別商品だからです。
ZENRINさんがこれまでGoogleに納めてきた地図でも、それは自動運転用の地図ではなく表示やナビ用の地図なので、それを使って自動運転することは不可能ですし、Googleがプローブ由来の地図作成をどれほど極めて、これまでZENRINが納めてきた地図に匹敵する精度に仕上げてきても、それは「ZENRINの表示やナビ用の地図」のライバルにはなるかもしれませんが、自動運転用の地図のライバルにはなり得ません。
作り方も求められる精度も、というか求められる属性等も(たとえば、驚くかもしれませんが自動運転地図に一方通行だの速度制限だのの属性は整備されません。それらはナビ向け地図でカバーされる領域なので)全く異なるので、たとえ新Google Mapsの地図精度がこれまで納められてきたZENRIN地図と同レベルの精度になっても、自動運転には使えません。
自動運転のためには、別の地図を整備しないといけないのです。

Googleが今回ZENRINを切って独自地図に踏み切った理由には、オフラインで使える地図を得るためというのも大きな理由だったと思いますが、このオフライン地図という概念とも、自動運転向け地図は矛盾します。
自動運転向けの10cmレベル高精度地図というのは、その膨大なデータ容量と、かつ常に最新の道路形状を反映した地図を使う必要があるという鮮度の双方の要求のために、自動運転用高精度地図を全部前もって蓄積しておくということをせず、常に車がオンラインの状態で、進行方向の何10?km先まで程度を前もって先読みダウンロードして、通り過ぎて必要がなくなればデバイス上から消す、という常時オンラインで動作する設計の地図になっているのです。
自動運転するためにはそういう設計にせざるを得ないのですが、自動運転の必要がない地図表示やナビだけの用途のために、そんな大容量の地図データをオフラインにできない形で大量にダウンロードしたいですか?

そのことを考えても、表示やナビ用の地図と自動運転用の地図を分けて整備する現行の設計は理にかなっていますし、Googleが独自に自動運転用地図を整備したがっていたとしても、それは表示やナビ用の地図とは切り離せるのですから(実際、表示やナビ用の地図と自動運転用の地図で異なるメーカーの地図が使われることはあり得ます)、表示やナビ用の地図としてはZENRINを使い続けつつ、自動運転用の地図としては自前で整備するという選択肢もあり得たわけです。
にもかかわらず、表示やナビ用の地図としてZENRINを切ることを決めた理由は、はっきりとは言えないもののいろいろ理由は考えられる(先述したオフライン用途のように)でしょうが、自動運転を見据えた結果というのは一番考えにくいと思います。

2. 大元のビジネスモデルが広告会社であるGoogleが、建物形状を軽視することなどあり得ない。

自動運転、まで飛躍しなくとも、新Google Mapsの変化が道路部分で目立ったことから、Googleが建物中心のZENRIN地図から、道路中心の地図に切り替えたのが今回のリニューアルの原因、という意見も見られました。

が、相対的な重心の微移動はさておき、大元のビジネスモデルが広告会社であるGoogleが、地図の建物形状を軽視することなどあり得ない、ということは指摘しておきたいと思います。
Googleではない他社の事例ですが、以下の動画を見てください。

www.youtube.com

施設情報を建物形状と結びつけ、ユーザの移動情報と比較する事を行うと(いわゆるジオフェンシングという技術です)、たとえば単に店の近くを通りがかった人まで来店した人と誤認するというような事なく、正確に自分の店に来た人だけをコンバージョンさせるような広告効果測定を得ることができます。
あるいは、自分の店の業種と同じカテゴリの店をよく訪れるユーザに、潜在的顧客としてセールス情報を送ったり、あるいは完全なライバル店をユーザが訪れた際に、こちらに引き戻すような魅力的な広告をターゲット広告するようなことも、正確な建物形状データがあれば可能になります。
そのような今後の位置情報ベース広告、マーケティングで大きな役割を担う建物形状データを、根のDNAが広告会社なGoogleが、軽視することは絶対にあり得ないと思われます。

道路の部分に大きな変化が散見されるのは、単に彼らが強いプローブベースの解析で地図を生成できるのが、道路形状が中心(プローブがいくらあっても建物形状の自動生成などは困難)だった、というだけの事だろうと思います。

また、広告だけでなく自動運転やナビの視点を考慮に入れても、私の友人で、私とは別の会社なものの同様に地図データを自社処理している会社に勤めているinuroも指摘していますが、

そのとおりで、ナビなどの視点からみたって、今議論の熱い「ラストワンマイル」(目的地までいかに辿りつくか)には、建物の形状どころか、建物の入り口の場所、もっとアグレッシブにいくと建物の中の屋内駐車場の特定の位置までデータ化が必要になってきている時代です。
建物か道路か、なんて話じゃなく、今の時代両方いるのです。

あとまた別の視点で言うならば、ZENRINは確かに建物に注視してきたところから歴史が始まった会社ですが、今では国内のナビ地図のトップシェアもZENRINです。
そのZENRINに対し、「建物に強くて道路に弱い」などというのはかなりZENRINを甘く見過ぎと言わざるを得ません。

3. Googleの地図データは、自動運転どころかその下のナビ実現レベルにまで至っていない。

Googleが超優秀な技術会社であることは、誰もが認めるところでしょう。
その彼らが実現しようとしている自動運転、そしてすでに実現している?ナビ機能も、おそらく競合他社では及ばない様々な高度技術が多く用いられているのだろうと思います。

が、Googleは残念ながら優秀な地図データ生成会社ではありません。
他の何十年とナビ一筋でやってきたような会社群が常識として普通に持っているような地図データの属性などを、保持していないがためにナビが異常動作するような事象が多数報告されています。

たとえば、具体的事例がなく定性的事象の列挙のみですが、下記のツイート。
これはZENRIN地図を採用していた時代から、という話ですが、

さすがに一方通行属性までGoogleが整備してないとは考えにくく、何らかのバグだと思うのですが、その他の歩行者専用道路属性、中央分離帯属性などは、ナビ地図業界でも高いシェアを誇っているZENRIN地図がそれらの属性の含まれていない地図を販売しているとは考えられないので、ZENRINが整備している属性をGoogle側が落としている可能性が一番蓋然性が高いと考えられます。

また、以下のような報告も。
これは新Google Maps以降の報告ですが、ある意味新Google Maps以降の劣化で一番驚いた報告です。

これ、「ああ、管理用車両を運転していた人がたまたまAndroidGoogle Mapsスマホ持ってたので、彼らしか通れない道ができちゃったんだねー」で済ませていい話じゃないんですね。
ZENRINさんももちろんそうですし、地図を作っている会社では普通に、もちろん会社によって呼び名は違うでしょうが「コントロールアクセス」という類の属性がついた道路があって、これは高速道路のように、インターチェンジやランプ、PA/SAなど以外では他の道に交わらない、交差点のない道路を表す属性です。
この属性が道路についている事によって、交差点がないはずの道路に交差点ができていれば地図全体のエラーバリデーションでエラーをはじくことができるので、こんなエラーが起こることは普通の地図会社だとありえないのですね。
にもかかわらず、Google Mapsで高速道路にこんな側道ができてしまったということは、Googleには「コントロールアクセス」の概念がないか、あってもエラーバリデーションしてないか...いずれにしても、普通の地図会社から見ると恐ろしい話です。

プローブからのデータ自動生成の話でも、先に引用したツイートを再引用しますが、

これ、仮に駐車場がプローブで道路だと判定されたとしても、ならば同時に、この駐車場を通るのは一方向への通り抜けのみだと思われるので、一方通行規制の情報もプローブから生成可能だと思うのですね。
ですが、実際にはこのエラー道路には、一方通行規制の属性がついていない、ということは、Googleはプローブからの規制情報の生成はしていないと受け取ることができます。
実際、真偽は不明なのですが、新Google Mapsでは、道路規制情報はトヨタマップマスター社の情報を使っている、という報告も上がっています。

つまり、プローブ情報をソースにしている新Google Mapsは、自動運転向けデータをつくるどころか、それよりはるかにレベルの低い、ナビ向けデータであるところの道路規制情報すら、プローブから生成できていない。
ということはやはり、新Google Mapsは自動運転を見越している、というのは相当に的外れだ、ということが言えると思います。

Maplatで同時に複数の古地図画像等を表示することに関する考察

先日、大阪市大で行われたMaplatのワークショップが開かれました。 そのワークショップ上で、面白い質問をいただきました。

よく航空写真などを大量に広域撮影することがありますが、そういった航空写真群をGISで扱う際、通常はオルソ補正加工などをして複数の航空写真をひとつのGIS化された大きな広域写真にまとめて、扱うということを行います。 が、そういったオルソ補正なども元画像を歪める処理の一種であると考えると、オルソ補正前の航空写真をMaplat上で扱いつつ、広域を覆ういくつもの航空写真を一斉に同時に表示する、というような事に対応する予定はあるか、という質問でした。

これは面白い問いかけで、まず技術的に考察しますと、Maplatによる古地図画像などの一般地図上への重ね合わせは、一般的なGISと異なり、単独の地図インスタンスの上に複数の地図画像レイヤーを載せているのではなく、背景の一般地図と重ね合わせている古地図等それぞれに、独立した地図インスタンスを生成し、各々を連携させながらも独立して動かす事で実現しています。 つまり、重ね合わせる地図を増やすことは技術的には可能ですが、その地図が増えるたびに、独立制御する地図インスタンスも比例して増えていく事になります。 1つや2つ制御する地図インスタンスが増えたところでそれほど重くはならないでしょうが、何百という数の広域の航空写真群を一斉に制御するようなことをすると、おそらく重すぎて制御できないでしょう。 ということで、まず技術的にも難しい要請になります。

次にMaplatでそれを実現する意味的にも考察してみます。 オルソ補正などで補正して共通座標系の一枚画像に加工した後ならばともかく、補正前の航空写真群は1枚1枚が独立した座標系を持つ地図画像です。 つまりは地図画像の切れ目で座標系が重なり合わない、視点を動かすと各々が独立してウネウネと動く独立座標系をもった画像の集まりであり、一度に表示することにあまり意味があるとは感じられません。 特に、Maplatの場合各々の地図の独立座標系と、経緯度などの正確な座標系がぴったり重なり合うのは現在の視点の中心点においてだけであり、中心点が地図の座標域に入らない、すなわち地図の全域で正確な位置情報と重なる場所がない地図を表示することにあまり意味はありません。 以上の理由より、隣接地図の切り替わりなどは工夫が今後も必要な点かもしれませんが、基本的にMaplatで複数地図を同時に見せることに大きな意味はないと考えています。

Maplat技術は今までになかった古地図の見せ方ができる技術ではありますが、万能の技術ではないです。 バラバラに撮られた航空写真などをまとめて一枚で広域に見るには、やはり既存のGISで処理した地図の方が向いている場合があり、それは全くMaplatは否定しておりません。 注意して欲しいのは、Maplat技術イコールMaplatビューアではない点で、Maplatのビューアは、Maplat技術で作られた地図だけでなく、既存のGIS技術(TMS、WMTS等)で作られた地図も一緒に読み込めます。 Maplat技術で処理するに向いていない地図は既存技術で処理しつつ、それらを重ね合わせるのはMaplatビューアを使う、という形で活用いただければな、と思います。

Stroly社との関係改善取り下げ連絡全文

この週末にStroly社に内容証明で出した、関係改善の取り組みの取り下げを通知する連絡の全文をここに引用公開します。
なぜ公開したかについては、末尾に記載しております。
なお、本文読んでいただければわかる通り、当方からの能動的取り組みは取り下げますが、先方からの取り組みに対する門戸は開いております。


拝啓
御社と当方との関係改善のやり取りにおきまして、当方からの回答が大変遅くなりましたことを、まずはお詫び申し上げます。

当該の関係改善に関する取り組みですが、理由については後述いたしますが本連絡の結論といたしまして、当方からの申し出は取り下げさせていただきます。もし御社の方で、当方との関係改善が必要だと考えられ、後述するような理由について態度を改善していただき、取り組みを継続されたいならば、その門戸は閉ざすつもりはございませんが、当方から申し出る形での関係改善の取り組みは取り下げさせていただきます。

理由については大きく2つございます。

まず1点目に付きましては、御社側で当方からの申し出に対し、真摯な姿勢が見られないためです。当方としては、関係改善のために双方ただちに謝罪し合うのであれば、それでも構いませんし、その謝罪の前に担保とやらが必要とおっしゃられるのであれば、それを双方示し合うのでも全く構いません。ですが、当方といたしましては、謝罪し合うのであれ、担保を示し合うのであれ、先に行動を起こすのは、たとえそれがほんの1秒の差であったとしても、御社側が先に行動を起こす必要があると考えており、その点に関しては1ミリも譲る気はございません。当方のこの立場に関しては、直近の内容証明のやり取りよりはるか以前の、https://blog.chizuburari.jp/entry/2016/11/23/124531こちらの記事で取り上げた内容であるところの、御社高橋徹氏に関係の清算を呼びかけた際(その際には、徹氏には一瞬で逃げられましたが)より、一歩も揺らいでおりません。当該の関係改善が為されるとして謝罪し合う対象の事象の中で、御社より当方に為された不利益は、当方より御社に為されたかもしれない不利益よりはるかに時系列上先に行われております。しかもその中には、当方への脅迫など、もう時効であろうとはいえ、刑事にもなりかねないものも含まれております。そうである以上、謝罪し合うにせよ担保を示し合うにせよ、まず先に動くべきは御社であろうというのが当方の立場です。
にもかかわらず、御社の姿勢は、まず担保とやらを当方が先に出す事に固執しており、御社の側に問題行為があったかどうかの認定はその当方からの担保を確認後認定する、つまり現時点では御社の側に非があったことすらいまだ認めておられません。そのような態度をされる限り、当方としては関係改善を進めるわけには参りませんので、御社側が関係改善を継続したいと考えられ態度を改められない限りは、当方からは申し出を取り下げさせていただきます。

2点目の理由ですが、御社よりCTOの中川氏が退任されたことが挙げられます。私の主観的な感覚では、御社より当方に為された不利益は、ほぼ100%が高橋徹氏、真知氏によって私に為された不利益ですが、逆に当方から御社に対して為された(謝罪すべき)不利益は、ほぼ100%が中川氏に対して私が為した誹謗中傷であったろうと考えております。私は中川氏に対しては、彼の配偶者が亡くなられたのは天罰だ、等という酷いものを含め、相当の誹謗中傷をした自覚があります。御社に対して関係改善を申し出たのも、9割以上中川氏との関係改善を望んでのものでした。
が、その中川氏は御社を退任され、中川氏の退任理由も高橋徹氏との不調和であった結果、同じく高橋徹氏との不調和で御社を退社となった私との関係改善が成立し、既に個人として中川氏に謝罪し許していただくことが叶いました。その結果御社に対しては、私の主観的立場からは、そちらから謝ってもらうべきことは多々あるものの、こちらから謝るべき(と当方が認識している)事象はほぼなくなったこととなります。御社との関係改善で期待していた中川氏との関係改善は既に獲得できておりますので、謝罪すべき事象の量が不釣り合いになったことも含め、御社との関係改善に固執する必要が全くなくなりました。

以上の2点の理由より、何度も申します通り依然門戸は開いておりますが、当方が能動的に御社との関係改善を申し出る事については、それを取り下げさせていただきます。それを受けまして、御社の方では、当方の行為が目に余ると思われるのであれば警察に相談されるもよし、訴訟されるもよし、自由にしていただいて結構かと存じますが、ただ、当方の主観的立場として、このような行為は御社への誹謗中傷には当たらないという事例を、2点ほど当方の主張としてこの場を借りて示させていただきます。

まずは、御社より当方に対して為された不利益行為に関して、当方が言及する行為についてです。「高橋徹氏によって、当方は脅迫された」ですとか、「当方が善意で申し出た条件付きの退職申し出について、騙して条件を全て反故にした上で追い出した」といった内容は、当方にとっては完全に主観的事実です。単に事実というだけでなく、それこそが御社と当方の確執の決定的原因である以上、当方に対してそれに言及するなと言われる筋合いはないと考えております。もちろん、当方も理性ある思考はできますから、私の知り得なかった様々なファクターも合わせて考えると、それらが主観的事実であっても客観的事実でない可能性は理解できます。なので、客観的事実だと言うつもりは毛頭ありません。ですが、当方が認識を主観的事実から客観的事実に改めるためにも、御社との関係改善で認識をすり合わせる機会が必要だったわけですが、その機会から延々と逃げたり、担保だなんだと不誠実に対応されたりする御社に、私が主観的事実を語ることを責める資格があるとは当方は考えません。これも何度も繰り返しますが、当方は御社と関係改善する門戸は閉ざしませんので、もし関係改善し当方の認識を客観的事実で更新したいと思われるのであればそのための話し合いには応じますが、それなしに主観的事実を当方が言及することを妨げられる筋合いはないと当方は考えております。

次に、https://drive.google.com/file/d/1rEjkN2d5AvVhB0nY8OUvwZaCxQIHe9TD/viewなどの場において、御社のソリューションと当方のソリューションの比較を行ったり、あるいは御社が御社製品のバグを修正できないことについて、当方が言及したりする行為についてです。当方も御社を追い出されたために独自のソリューションを開発しなければならなくなった以上、そのソリューションを世の中に普及させるために、御社ソリューションより優れている部分は優れているとして、宣伝していく必要があります。当方が資金調達できる可能性を考えてVC様に情報を提供する事を含め、それらを宣伝することは当方にとって経済活動の自由として当然の権利であり、あからさまな虚偽を含むものでない限りは、御社への誹謗中傷や営業妨害に類する類のものではないと当方では考えております。当方の資料を見ていただければわかりますが、虚偽を含むどころか、現状で御社の方が優れている機能については無視することなく、正しく御社の方が優れているとして資料では触れておりますし、誹謗中傷の類と言われるようなものではありません。

以上2点について、当方では仮に当方が公の場で言及することがあっても、それは誹謗中傷や営業妨害に類するものにはならないと当方は考えております。が、それは当方の主観的考えですので、御社の方で不法行為に当たると考えられるのであれば、ご自由に警察へ再度相談されたり、訴訟を検討されたりすればよいかと存じます。ただ、もし警察や訴訟などで当方のソリューション、Maplatの活動を止められると考えてそのような手段を選ばれるのであれば、そのような事のないようにオープンソースにしておりますし、近々元御社CTOの中川氏が参加していただけるのを含め、私の手を止めたところでMaplatは止まらない、ということをお伝えしておきます。また、当方は御社から受けました不利益に対して、その中には当方主観から見て脅迫行為や公共機関への虚偽申請など、今さらですと時効ではありますが、刑事の対象になりかねないようなものもございましたが、特に警察沙汰などにすることなく対応しております。御社も、そのような力を借りてどうこうしようとするのではなく、正々堂々と、言論と技術開発、経済活動で対抗なさる事を強くお薦めいたします。

最後にですが、御社と複数回内容証明をやり取りさせていただきましたが、論点をズラされたと感じることが何度かございました。関係改善において謝罪に先立ち担保を、と要求された事に対しても、当方は不利益行為を先に行ったのは御社側であるのだから、担保を示すならば先にそちらが、と言及したにも関わらず、御社からの返信では御社が先に当方に不利益をなした、という点に答える事を無視して、当方が御社の要求を無視した、と言う点のみ強調されました。そのような論点ズラしなどがあるとまともに交渉できませんが、それも全てクローズな場でやり取りしていることが原因かと当方は考えます。万人に主張の内容が精査される場ではそのような事は起こらず、真摯で誠実に議論ができるのではないかと当方は考えますので、当方は今回のご連絡につきまして、送付後当方のブログ上で内容をそのまま公開いたします。また、これに対する御社からの返答があった場合は、それもテキスト化させていただいて同じく公開させていただきますので、その前提で返答いただける場合は返答いただければありがたく存じます。

当方からのご連絡は以上です。よろしくお願いいたします。
敬具

Maplatが特許申請しているのはStrolyからのスラップ訴訟対策のためだけです

Maplatは特許を出願していますが、そのことについて、年末のQiitaの記事で質問をいただきました。

特許出願中とのことですが、取得後Maplatの利用にどのような制約が生じますか?
別途許可を得ないと利用できなくなるかなと思ったのですが。

Maplatの特許申請中原理は、JavaScriptオープンソース実装の利用を通じて利用される限り、将来におよびライセンス料などを徴収する事はありません*1
Maplatの特許出願は、対抗技術(Stroly)対策として出願しているのが主目的です。

Strolyも特許を取っており、その特許技術の手法と全く違うやり方でMaplatは性能機能を実現しています。
それは仮にMaplatが特許を申請していなかったとしても明らかで、現時点でMaplatは下記の通り、Strolyに対し性能的にも機能的にも優位を実現しています。
特許技術を剽窃している方が本家より性能が出るなんてそんなわけはありません、違うやり方をしているから相手より性能が出ているのです。
(以下の図表は2019年1月現在の比較)
f:id:kochizufan:20190114181035p:plain
f:id:kochizufan:20190114180959p:plain

が、Stroly社はそういう道理が通じる相手ではありません。
Maplatを潰すためなら、脅しのためのスラップ訴訟を起こしてくる危険性が普通にある会社ですので、完全に違う技術であることを明確にし証明する事を主目的として、Maplatは特許を出願しています。

ですので、ライセンスビジネスで儲けることなどが主眼ではないので、繰り返しますがMaplatの実装を通じて特許技術を利用される限り、特に申請もライセンス料も必要なく利用継続できる形になります。

以上のことをQiitaで説明しましたところ、それであればこれまでのMITライセンスではなく、オープンソースを通じて特許を利用する限りライセンス料は自由に使えるApache 2.0ライセンスに変更した方が良いのでは無いか、という助言をいただきました。
その助言に従い、2009年1月公開のリリース0.4.0より、ライセンスをApache 2.0ライセンスに変更いたしました。
これで、Maplatの特許取得完了後も、皆様により使ってもらいやすいライセンスになったと思っています。
ぜひ、どんどん利用いただけると嬉しいです。

*1:ただし、Maplat実装とは別に同じ手法を独自実装する場合には、事前承認が必要ですし場合によってはライセンス料を必要とする場合もあり得ます。
基本的に、現在JavaScriptしか実装がないこの技術において、JavaScript以外の言語での実装を、Maplatのブランド名の元で、オープンソースで新たにやる場合は、ライセンス料はなしで認めるつもりでおります。

Strolyでは近い将来、地図のマッピングデータライセンス帰属が問題になってくるだろう

Strolyに関して、半年1年規模で近い将来に問題になってくるのが、地図のマッピングデータ(対応点情報やPOI情報等)のライセンス帰属がどこなのか、という問題だろうと思う。
オープンデータ企業を標榜している割に、Strolyはいまだかつてマッピングデータをオープンデータにするという表明をしていないどころか、そもそもライセンスをどこが持っているのか、Strolyエディタを使ってマッピング作業をしたユーザの所有なのかそれともStrolyエディタを擁するStroly社の所有なのかという事をあいまいにしてきている。
これはStroly社が上向き成長*1している間は問題を生まなかったが、今後近い間に問題になってくる可能性がある。

Stroly社はこれまでにまず昨年1.4億を調達し、さらに今年2.5億という多額の資金を調達した...にもかかわらず、その所有する技術は、座標変換性能においても機能においても、個人のオープンソースプロジェクトに過ぎないMaplatに大きな遅れを取っている。
具体的にどのような性能、機能が劣っているかについては、Maplatが2018年11月に国土交通省主催のGeoアクティビティコンテストで最優秀賞含む三冠を達成した時の資料に詳しくまとめられているのでここでは省略する。
またStrolyは単に他プロジェクトに劣っているだけではなく、現時点で自身が実装完了している機能についても、うまく動作しないバグを抱えている。
一例として、こちらのURLを確認してみてほしい...鎌倉市由比ヶ浜付近の古地図の海岸線が見えると思うが、これをOSM地図に切り替えると、全く海岸線が一致しない*2
これは地図変換時の縮尺計算ロジックが間違っているバグである。

これらの性能機能の遅れやバグの存在について、すぐキャッチアップできるならばStrolyもなんの問題もないといえる。
が、実際には、これらの性能機能の遅れの一部は昨年1.4億調達した時点で存在したにも関わらず、それから1年経ってさらに2.5億調達した時点で全く遅れがキャッチアップできていないどころか、新たに機能対応遅れが発生しているという体たらくである。
1年で1.4億使い切ったにも関わらず*3、一切技術的遅れを取り戻せなかったどころかさらに離されたStrolyが、残り2.5億使ったからといって技術的に優位に立てるだろうか。
ましてや、Strolyにとってさらに悪い状況として、今年技術力の流出が発生したことがある...同社で唯一GISの知識を持つ技術者であった元CTOの中川氏が、共同CEOの高橋夫妻との確執の末に、今年11月退社したのである。
技術の核が存在した状態で1.4億使い切り1年かけても技術的劣勢を覆せなかったStrolyが、技術の核を失った状態で、2.5億あったところで技術的優位を得ることができるだろうか...私にはそうは思えない。
その傍証もある。
先に述べた地図変換時の縮尺計算バグ、私は2018年11月25日の時点で、中川氏退社後の技術開発リーダーである同社上田氏にバグの存在をレポートしている。
しかしこの記事を書いている2018年12月17日現在、もう大方20日が過ぎようとしているにも関わらず、いまだにバグは修正されていない。
自社の技術の心臓部分のエラーすら、まともに修正できないレベルで、Stroly社の技術はすでに失われている状態といえる。

このようにStrolyが残り2.5億で、個人プロジェクト相手にすら技術的優位を得るのは絶望的な状況である。
また、同社は1.4億を1年で使い切ったように、まだ完全に赤字体質で、売上で会社を維持していける状態ではない*4
となると、同社が経営を維持していくには何が必要か?...2年後くらいだろうか、2.5億を使い切った後に追加で投資してくれる投資元である。
もし2年後に追加の運転資金を投資してくれるところがなければ、Stroly社は完全に干上がるだろう。
しかし、個人の余暇プロジェクトにすら後れを取るStrolyに、2年後投資してくれるVCが現れるだろうか?
もちろんStroly対抗プロジェクトのMaplatの知名度がなければまた投資する元は現れるかもしれないが、2年という月日はStrolyがMaplatに対する技術優位を得るには短い年月だが、Maplatが知名度を得るには十分な年月と言っていい。
もし2年後、どこからも投資を受けられなかったら...Stroly社に見えるのは「倒産」の2文字である。

さて、当初のマッピングデータライセンスの話題に戻る。
Stroly社が順調な間は、ライセンスの問題はあいまいなままでよかった。
ライセンスの所有者がどうであれ、そのマッピングデータを使ったサービス結果は、Stroly社のサービス基盤を通じて享受できるのだから。
しかし、Stroly社の倒産が見えてくるとどうなるか?...倒産すなわち、Stroly社のサービス停止であり、マッピングデータを使ったサービスはその後受ける事ができなくなる。
そうなると、Strolyを利用しているユーザは、自分たちのマッピングデータなどを外に逃がして、Maplatのその他の手段でサービスを継続したいと思うようになるだろう。
その時に問題になるのが、マッピングデータのライセンス帰属問題である...もしマッピングデータのライセンスがStroly社にあるとされるのであれば、ユーザがいかにデータを外に逃がしたくても、ライセンス違反になるので持ち出せない!!

マッピングデータについて、Stroly社が自主的にマッピングして公開している地図のマッピングデータのライセンスは、言うまでもなくStroly社の持ち物である。
これらについては、残念ながら、もしStroly社が潰れる事があれば一緒に消滅しても仕方のないデータだと言える*5
しかし、ユーザがStrolyに対価を払ってマッピングしてもらったデータのライセンスは誰に所在するのか?
Strolyエディタを使わせてもらっただけで、マッピング自体はユーザ自身が行ったデータのライセンスは?
こののちStrolyの経営に陰りが見え始め、Maplat等にデータを移したいと考えるユーザが増え始めるにつれ、これは問題になってきそうである。
だからこそ、Strolyのユーザには、まだStrolyが元気なうちに、マッピングデータのライセンスの帰属をはっきりするよう、そして当然ユーザ側の方に取り戻すよう(あるいはオープンデータの側に)、働きかけることをお勧めしたい。
これを働きかける事は、ある種Stroly経営陣が今後の経営についてどの程度自信があるかを確かめるための試金石にもなるといえる...何故ならば、今後の経営に自信があるのならば、データの帰属がどうであろうと気に留めないだろうが、自信がなければ、自社サービスに引き止めるためライセンスを手離さないであろうからだ。
是非Strolyユーザの皆さんには、マッピングデータのライセンス帰属を明確にさせる働きかけをして欲しい、そしてライセンスを勝ち取って欲しい。

というか、Strolyが倒産しうる可能性を考慮したうえでデータのライセンス帰属をはっきりさせた方がいい、と長々論じてきたけど、そもそも経営が危険であろうがなかろうが、データのライセンス帰属をはっきりさせないこと自体がどっかおかしいんだけどな!

*1:単に成長実態はなくて金が集めるのが上手かっただけという話もあるが

*2:もし一致しているならば、バグは修正されたという事だが、この記事を書いている2018年12月17日現在、バグは修正されていない

*3:これは当初Strolyの社員数と人件費から推定した憶測だが、のちに後述する元CTOの中川氏にも裏取りしたが事実のようである。1.4億使い切ったので、新たな運転資金として2.5億調達したが、調達できなければ今年で足が出ていたようである

*4:この事は中川氏にもある程度裏を取っている

*5:本来は、Stroly自体がオープンデータ企業を標榜しているのだから、これらについても積極的にオープンデータにして、同社が潰れても社会資産として残るようになることを望みたいところだが、それは強制できない

Maplat、2018年Geoアクティビティコンテストで最優秀賞含む三冠達成しました! & 東京都中央区版公開 & 館林市観光協会員になりました

どうもご無沙汰しております。
しばらく記事書いていない間に、タイトルのような大きな話もいくつかあったのですが、来年の地図学会日本開催でMaplatの発表をするための英文アブストラクト作成に追われていてあまり時間が取れませんでした。
ですので古いものは1か月以上前の報告になるのですが、いくつか報告します。
まずは...

Maplat、2018年Geoアクティビティコンテストで最優秀賞含む三冠達成しました!

今年、Maplatは国土交通省主催のGeoアクティビティコンテストに参加しておりました。
参加にあたってのポスター兼配布資料はこちら、発表資料はこちらでご覧いただけます。
参加結果ですが、なんと、最優秀賞をいただいただけではなく、教育効果賞、来場者賞も同時受賞の三冠をいただきました!
コンテストの様子は、片岡さんの地図ウォッチ記事や、株式会社コギトさんのブログ記事でもレポートいただいています。
古地図の位置を視点中心で正確な位置とあわせつつ、方角と縮尺を都度合わせる事で全体として古地図を歪めないままに正確な地図と「なんとなく」重なっているように見せかけるという手法について、多くの来場者の方から「天才的だ」と言っていただいたり、地理院の方々から「これは地図をぴったり合わせる事ばかり考えている地理院の中からは出てこない発想だ」と言っていただいたりし、とてもありがたく感じました。
この中心、方角、縮尺を合わせてざっくり重なってるように見せかけるという手法は、やはり因縁があるので言及してしまいますがStrolyも、Web版ではまだできていませんがiOS版では実現できている事です(といってもそれをやったのは私ですが)、しかし、元々Stroly社には古地図と正確な地図の中心を合わせる技術しか存在してなくて、方角と縮尺を合わせる技術は私がStroly社の中に居た頃に実現させたんですね。
その意味では、MaplatはStrolyの真似事をしているわけではなく、方角と縮尺を合わせる技術は完全に私のオリジナルなものなわけなのですが、それが「天才的」等と評価されて、また実際に賞までいただけた事をとてもうれしく思います。
今後もこの受賞を糧に、古地図に含まれた様々なストーリー性、コンテンツ性を表現できるツールとしてMaplatを育てていきます。
そしてICC2019での国際会議発表を経て、いよいよ海外進出だ!なんてw

Maplat東京都中央区版「ぷらっと東京中央区」公開!

これまで「ぷらっと奈良」、「ぷらっと会津若松」、「ぷらっといわき」、「ぷらっと館林」の4サイトを公式展開してきたMaplatですが、この度5作目として、初の東京エリア進出の作品を公開しました。
その名も「ぷらっと東京中央区」!

s.maplat.jp

初の東京進出だけでなく、今回は絵地図師/散歩屋として有名な高橋美江さんの魅力的な絵地図とのコラボレーション!
美江さんの綺麗な絵地図と、江戸期、近代の中央区地図との切り替えで中央区の街歩きを楽しくサポートします。

もしこのようなサイトを他の地域で作りたい!と思われる方は、ぜひ rekishikokudo@tilemap.jp にコンタクトください。
格安でサポートいたします。

館林市観光協会員になりました!

アニメ「宇宙よりも遠い場所」、もう公開から1年を経ようとしていますが、館林のアニメ聖地88選定、さらに誰もが驚いたニューヨークタイムズ海外テレビ番組ベスト10選出と、ますます盛り上がっています。
聖地館林でも、長年草の根で聖地巡礼者を支えてこられたコテージレザーさんの数々の革細工瞬ぴーさんの南極チャレンジカレーうどんとパーシャル丼大島まんじゅう屋さんのペンギン饅頭のそれぞれ公式化と、明るい話題が絶えません。
今後ますます館林巡礼が活発化していくと思い、我がぷらっと館林のよりもい巡礼マップもどんどん利用してもらってよりもいと館林盛り上げに貢献したいと思っているのですが、いかんせん中々存在を知ってもらう事ができません。

そこで思い立って、館林市観光協会さんの会員になってみました。
もう観光協会さんからのリンクも張っていただいています。
館林駅前の観光案内所などにもチラシも置いてもらえるようになったので、以前よりは発見してもらえ易くなったと思います。
観光協会会員になった事を活かして、うまく館林盛り上げに遠隔地ながらもどう絡んでいけるかを考えていきたいと思います。
今度は館林城の再建を目指す会の会員を目指してみようかな...会員募集してるかわからないけど...。

© Code for History