ちずぶらりHackers

オープンソースの古地図/絵地図アプリ基盤、Maplat開発してます。同種のソリューションに対する優位性は、色々ありますが一番は、あらゆる地図間で双方向1対1座標変換可能な点です。ぷらっと会津若松 https://s.maplat.jp/r/aizumap/ 、ぷらっと奈良 https://s.maplat.jp/r/naramap/ 、ぷらっといわき https://s.maplat.jp/r/iwakimap/ 、ぷらっと館林 https://s.maplat.jp/r/tatebayashimap/

[古地図こぼれ話1]重要文化財、奈良称名寺薬師如来像の来歴をつきとめたかもしれない話

近鉄奈良駅から北西にいったあたりに、称名寺というお寺があります。

ja.wikipedia.org

茶人として知られる村田珠光が出家していた寺としても知られる同寺ですが、かつて同寺の山門外西側に薬師堂があり、そこに薬師如来立像が納められていました。
今は国の重要文化財となり、奈良国立博物館に寄託されている仏像です。

imagedb.narahaku.go.jp

上記には写真は含まれていませんが、写真は称名寺さんのWebページ内のこちらで確認することができます。

今回の記事は、この薬師如来像の来歴をつきとめたかもしれない、という話です。
知人の歴史研究者への確認や、奈良県立図書情報館のリファレンスなどを使って同様の説が過去にあったか確認してみましたが、調べられた範囲内では見つけられていないので、もし見つかっていない論文等がない限りは新説、ということになります。
本来は歴史学会などに論文として出すべきなのかもしれませんが、私は歴史の学会にも属していないし、論文の書き方もわからないのでまずブログ記事としてみました。
専門家の方、どう扱うべきかアドバイスなどいただけましたら大変嬉しく思います。

まず結論としては、

  • 称名寺薬師如来は、江戸中期まで奈良市高畑町字本薬師の、現在奈良教育大学構内の本薬師と呼ばれた薬師堂に安置されており、それが江戸時代の間に興福寺塔頭の勧修坊、奥芝町の奥芝辻薬師堂への移動を経て称名寺に伝わった可能性が非常に高い
  • 本薬師と呼ばれた薬師堂に安置された薬師如来には、江戸時代の時点で、源頼朝から南都の僧に与えられたもの、という伝説が伝わっていた。同時代史料がないのでこの真偽はわからないが、称名寺薬師如来の学術的な年代推定も鎌倉時代であり、非常に近い

というものになります。
なぜそのような結論となったのか、経緯をこれよりお伝えします。

はじまりは古地図の上の「なんだこれ?」

はじまりは、古地図の上で「なんだこれ?」というような記述を見つけたことでした。

s.maplat.jp

上記のリンクの場所ですが、この周辺、私が奈良に住んでいた頃に居住していた場所でした。
古地図上には、変体仮名混じりで「きかいが嶋」と書かれているのですが、周辺の「かがみ明神」「きびづか」「かげ清地蔵」などは現在にも残っているものの、この「きかいが嶋」にあたるものは全く残っていません。
「きかいが嶋」のそばには「奥芝辻にひける」といった但し書きが書かれていますが、これの意味もさっぱりわかりません。
そこで興味を持って、奈良の地誌などを紐解いてこれの正体を調べ始めたのです。

高畑鬼界ヶ島には本薬師と呼ばれる薬師堂があり、頼朝から下賜されたとの伝説がある薬師如来十二神将像があった

その調査結果は、実はもうWikipediaにまとめてあります。

ja.wikipedia.org

上記のWikipediaは、私が書いたものですが、Wikipediaでは自分の研究は書けないため、飽くまで奈良の地誌などに残っている記述を引用する形で、断定せず複数解釈が存在する場合は両論併記的に書いております。
が、このブログは私のメディアですので、もう少し断定調に近い形で書こうというのがこの記事の目的でもあります。

いずれにしましても、江戸期の奈良の地誌、『奈良坊目拙解*1』、『南都年中行事*2』、『平城坊目考*3』などによると、この現在は『奈良市高畑町字本薬師』と呼ばれる地域に、『鬼界ヶ島』と呼ばれる一角があったというのは間違い無いようです。
鬼界ヶ島と呼ばれるようになった理由については、伝説としてこの地に俊寛が隠れ住んだとの伝説があったためと思われますが、薬師如来の来歴とはさほど関係がないので詳細は省きます(興味があればWikipediaを見てみてください)。
重要なのはそれらの地誌を見ますと、この鬼界ヶ島の地に、『本薬師』という薬師如来十二神将を祀った薬師堂があったという記録が残っていることです。
この『鬼界ヶ島本薬師の薬師如来』が、経緯は順次後述しますが『称名寺重要文化財薬師如来』に一致する可能性が高いのです。
またその薬師如来の来歴に対して、『奈良坊目拙解』『平城坊目考』等の地誌では、源頼朝勧修坊周防得業という奈良の僧侶に賜った薬師如来であるという言い伝えが記載されています。
この勧修坊周防得業というお坊さん、頼朝に追われていた義経を奈良で一時匿ったものの、それを咎められて頼朝に鎌倉へ呼び出されますが、逆に頼朝の非道を論理立てて諭して頼朝に感心され、鎌倉で勝長寿院というお寺を任されたという逸話のある方です。
のちに奈良に戻ってくるのですが、それほど頼朝に感服されたお坊さんですから、戻るにあたり餞に仏像など賜っても不思議ではありません(残念ながら同時代史は残されていないようですが)。
奈良の地誌の記録は江戸時代の記録であり、頼朝の同時代史ではないので信憑性については疑問が残りますが、重要文化財となっている薬師如来像の推定作成年代が鎌倉時代であり非常に近いので、簡単に眉唾とも言ってしまえない状況です。

鬼界ヶ島本薬師の廃亡に伴い、一時興福寺塔頭の勧修坊へ

その後、鬼界ヶ島本薬師の薬師堂の廃亡に伴い、薬師如来像は一時興福寺塔頭の勧修坊に移され、その後奥芝町の奥芝辻薬師堂に移送されます。
最初の古地図に「奥芝辻にひける」と書かれていたのは、この事をあらわしていたようです。
この鬼界ヶ島本薬師の廃亡、勧修坊への移動および奥芝辻薬師堂への移動はどの地誌でもほぼ一つの出来事的に書かれているので、ほぼ同時期に起こったことなのか、勧修坊にもそれなりに長期間いた後に奥芝辻に移動したのかはよくわかりません。
時期についての記述も、地誌によって寛永年間(1624〜1645)と書いているものもあれば万治年間(1658〜1661)と書いているものもありはっきりしません。
寛永に鬼界ヶ島本薬師から勧修坊への移動、万治に勧修坊から奥芝辻への移動が起きていたのかもしれません。

この勧修坊という塔頭、古地図上では

s.maplat.jp

こちらにあたりますが、今でいうと荒池(当時はありませんでしたが)のほとり、高畑天神社)の裏あたりに当たる地域です。
この勧修坊への移動は、鬼界ヶ島本薬師が元々興福寺勧修坊の管理下にあったことが原因と思われます。
元々本薬師の薬師如来自体が、勧修坊周防得業に与えられたという伝説があるものですから、その管理が得業の住坊であったと思われる勧修坊になるのも不思議ではありません。

この勧修坊という塔頭は、義経とも所縁が深い勧修坊周防得業の住坊だけあって、義経が一時潜伏したという言い伝えもあり、義経が出立する際に鎧の籠手を残していったのが伝わっていたという記録があります。
その籠手は今は春日神社に移って現在も伝わっており、国宝になっています。

bunka.nii.ac.jp

勧修坊についても、いつかWikipediaに書いてみたいと思っております。

勧修坊から奥芝辻薬師堂へ、ケチな坊主のために失われる十二神将

さて、先に書いた通り、薬師如来像はしばらく勧修坊にいた後、奥芝辻薬師堂へと再度移送されます。
奥芝辻薬師堂はこちら。

s.maplat.jp

『奈良坊目拙解』『平城坊目考』等の地誌から見ても、鬼界ヶ島本薬師から勧修坊への移動は少し前時代史に当たるかもしれませんが、勧修坊から奥芝辻への移動はほぼ同時代史だったようで、街の古老の話として、勧修坊から奥芝辻まで車を曳いて移動する際に、街の人に結縁のためと称して車を曳かせていた、といった聞き取り記録が残されています。
またこの時、残念な出来事が起きてしまいました。
『本薬師』の薬師如来は最初に作られた際から十二神将像がセットであり、鬼界ヶ島本薬師から勧修坊までその1セットは漏れなく移されていたようなのですが、奥芝辻への移送にあたり、勧修坊の僧侶が移送費をケチったために、薬師如来のみが奥芝辻に送られ、十二神将は勧修坊にとどめおかれました。
その結果、十二神将はその後行方知れずになってしまいました。
薬師如来と一緒に奥芝辻に送られていれば、十二神将像もあわせて現代に伝わっていたかも知れず、とても残念です。

奥芝辻薬師堂も廃亡するにおよび、いよいよ薬師如来像は称名寺、そして奈良国立博物館

これまで主に参考にしてきた地誌は『奈良坊目拙解』『南都年中行事』『平城坊目考』等になりますが、奥芝辻薬師堂への移動以降は江戸時代も後期の様相になりますので、次の時代の地誌である『平城坊目遺考*4』を参考にすることになります。
奥芝辻に移ってしばらくは周辺の信仰を集めた奥芝辻薬師堂と『本薬師』薬師如来像ですが、廃亡の時期ははっきりとはわからないものの、廃亡するに及んでこの薬師如来像は、近くの菖蒲池町称名寺、山門の傍に移設されたとの記録が『平城坊目遺考』に残っています。
また、これまでの地誌では残されていなかったのですが、『平城坊目遺考』で初めて、『本薬師』薬師如来像の高さが五尺(1m50〜60cm)という記録が残されますが、このサイズは称名寺重要文化財薬師如来像の高さ(164.5cm)とほぼ一致します。

そして、後に称名寺薬師如来像は重要文化財指定され、奈良国立博物館へ寄託されるわけですが、この時の話について称名寺の住職さんにメールインタビューしたところ、

重要文化財薬師如来が収められていた)薬師堂は、現存いたしませんが、山門外の西側に有ったと伝えられております。

との話をいただいており、これも『平城坊目遺考』の「菖蒲池町称名寺、山門の傍に移設された」という記述と合致します。

このような地誌の記述を追っていった結果と、そしてところどころでの記されている事象の合致

があることより、私としては、記事最初に示した事項、再掲しますと

  • 称名寺薬師如来は、江戸中期まで奈良市高畑町字本薬師の、現在奈良教育大学構内の本薬師と呼ばれた薬師堂に安置されており、それが江戸時代の間に興福寺塔頭の勧修坊、奥芝町の奥芝辻薬師堂への移動を経て称名寺に伝わった可能性が非常に高い
  • 本薬師と呼ばれた薬師堂に安置された薬師如来には、江戸時代の時点で、源頼朝から南都の僧に与えられたもの、という伝説が伝わっていた。同時代史料がないのでこの真偽はわからないが、称名寺薬師如来の学術的な年代推定も鎌倉時代であり、非常に近い

ということが成り立つ可能性が高いと考えています。

*1:村井古道著、享保20年(1735)発行、私の調査は喜多野徳俊訳註の1977年綜芸舎発行本に基づく

*2:村井古道著、元文5年(1740)脱稿、私の調査は喜多野徳俊訳註の1979年綜芸舎発行本に基づく

*3:久世宵瑞著、寛政7年(1795)成立、私の調査は金沢昇平校正の1890年阪田購文堂発行本に基づく

*4:金沢昇平著、1890年、阪田購文堂発行

自動運転では、Googleのスピード感だけでなく自動車会社のスピード感も考える必要がある

先の記事

blog.chizuburari.jp

につけていただいたブクマコメントで、いくつか唸らせられたのにお答えしたいと思います。

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

プローブによって生成した地図の精度は低いかもしれないけど、RTKのような高精度な測位システムが出てきたら解析能力を持っているGoogleにあっという間に抜かれてしまう。確かにコケたGoogleサービスは多いけど、要警戒。

2019/03/25 07:57
b.hatena.ne.jp

これに関しては完全におっしゃる通りで、今の携帯電話などのプローブ位置情報精度がいくら積み重なっても自動運転可能な精度にはなりませんが、プローブの位置情報側に革新があり、多くの携帯がRTK対応なんて事になってくると話は違ってきます。
そんな自体が何年後、十何年後に来るのかわかりませんが、そんな自体になれば、特に自動運転向けに作ったわけではない基盤が「結果的に」自動運転にも使えるようになる可能性もゼロではありません。
そこまでは否定していないつもりです。

また、RTKが世の中にあふれる「かもしれない」十何年後かを見据えて、Googleが最初から自動運転にも使えるような仕掛けをプローブ生成地図の中に埋め込んでいる可能性も、これまた「ゼロではありません」。
その意味では、ブコメで誰かがおっしゃっていた、「Googleの中の人でもないのに何がわかるのだ」という指摘はごもっともです。
私が論証したのは今新Google Mapsが使っている技術が、今のトレンドの自動運転技術にはリンクしないということであって、Googleが「今は実現不可能でも、十何年後にはできるかもしれない、まだ『誰も知らない自動運転の仕組み』の秘密の種を新Google Mapsの中に撒いている」可能性については、Googleの中の人でもなければ「撒いている」とも「撒いていない」とも断言できません。

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

かつて 3D ゲームにおいてコリジョンマップと景観モデルは別だった。しかし今やハードとゲームエンジンの性能向上によって景観モデルはコリジョンを兼ねるようになった。Google もそういう方向に未来を考えてるのかもね

2019/03/25 09:22
b.hatena.ne.jp

これは喩え方が面白いなと思って唸らされましたが、確かに今の技術の限界(ネットワーク速度やストレージ容量の限界等)では、ナビ、表示用の地図と自動運転用の地図は分けて作成されるのが合理的ですが、将来通信が5Gだ6Gだとなり、ストレージにも革新が起きて状況が変わってくれば、表示用の地図と自動運転用の地図が共通になる未来も考えられないわけではないと思います。
そしてこれも同様、Googleが十何年後のネットワーク環境等を見据えて、将来の新型自動運転技術の種を新Google Mapsの中に撒いている可能性は、中の人以外の誰にも、否定も肯定もできません。

が、それでも、100%の否定はできませんが、私は「新Google Mapsに将来の自動運転につながると現時点でGoogleが考えている技術要素は入っていない」蓋然性が高いと思っています。
それは、自動運転を実現するには、Googleだけで完結する話ではなく、Googleと組んでいる自動車会社のスピード感も絡んでくるからです。

皆さんは、5年後の未来って想像できますでしょうか。
今年大学に入学した子が既に就職しており、明日発表される新元号ももはや5年目になって目新しくなくなっていて、東京オリンピックももう終わってむしろ次の話題は大阪万博になっているような未来です。
はるか先に思えますが、自動車会社の人々にとっては「5年後」は「現在」です。
新しい自動車モデルが発売されるとなると、その自動車に搭載される「ナビ」等の部品は、5年前には企画がスタートし、4〜3年前には使う技術が決定しインタフェースなどの詳細を2年程度かけて詰め、2〜1年前に実装に入りいくつかのプロトタイプで実走テストを繰り返し、実際に発売された後は10年程度は継続して動作することを保証する事が必要とされます。
つまり、自動車会社にとっては、製品に使われる技術は5年後に発売されるモデルの技術であっても、現時点できちんと動作する事が保証されており、かつ15年先にも動作する事が保証されている技術である必要があるのです。

Googleはインターネットの企業で、開発サイクルなどに囚われずいつでも最新で最高の技術をパッと市場に投入し、必要なくなればパッとなくしてしまう身軽な会社ですので、みなさんGoogleの自動運転と聞いてもそのようなイメージを持ってしまっているかもしれません。
が、Googleはもう早くに自動車筐体まで自分たちで準備する形での自動運転参画は放棄していますので、自動運転に参画するには協業している自動車会社の開発サイクルも考慮しなければなりません。
たとえ自動運転機能が搭載される新車の発売が5年後だとしても、その実現に必要な機能の原理は、今この時点で確立して、自動車会社とこの技術でいく、ということが握れていないといけないのです。
「何時になるかもわからない」携帯にRTKが広まったら、5G6G通信が広まったら、動作するようになる「かもしれない」最新の自動運転技術、では自動車会社とは握れません。
インターネット上のGoogleの自社サービスのように、目処がついた、技術が完成した!すぐ投入しろ!というわけにはいかないのです。

ということなので、少なくともここ5年程度の自動運転実用化でGoogleがプレゼンスを持とうと思うと、「何時になるかわからないけれど、高性能なのができるかもしれないね」技術を追っていては完全に足がかりを失うので、Googleといえども今実現できる事、ナビ表示用地図とは別に自動運転用高精細地図を準備する形で参画するしかあり得ないと思っています。
そして、Googleといえども同種のプロジェクトをいくつも並行して走らせる余力はないと思われますので、高精細地図による自動運転技術の開発と、RTKや5G6G通信が広まって以降の全く新しい自動運転技術の開発を2列走らせるということはしないのではないかと思います。

なので、結論としては、新Google Mapsで使われているプローブ地図作成等の技術が、携帯にRTKが広まったら、5G6G通信が広まったら、というような十何年か先の?将来の変化に応じて自動運転にも絡んでくる技術になる可能性は否定できません。
しかし、今のGoogleがそこまで見込んで種を撒いている蓋然性は低い、というのが私の考えです。

バズったので宣伝:古地図、絵地図で街歩きできるサイトを作れるオープンソース、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のブランド名の元で、オープンソースで新たにやる場合は、ライセンス料はなしで認めるつもりでおります。

© TileMapJp/歴史国土/地図タイル工法協会