ちずぶらり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/

Stroly社の特許の価値を検証してみる

Maplatの基本原理の申請中特許ですが、無事公開されていました(特開2019-91147)。
6月半ばには公開されていたというのに、審査請求しないといけないのに弁理士さんちゃんとチェックしといてくれよ...週1回くらいはチェックする言うとったやんけ...と言うわけで審査はまだ請求してないのでこれからです。
この記念に、比較等しながら、Stroly社の特許の価値の検証でもやってみようかなと思って記事を書きます。

まず、Strolyの主たる特許は2つあります。
これに先行するほとんどビジネスモデル的な特許もありますが、座標の計算方法や具体的な機能の作り込みに言及してるのはこの2つなので、この2つの価値を検証していきたいと思います。

  • 特許5681920号 - Strolyの経緯度から絵地図座標方向への座標変換の手法を定義した特許
  • 特許5810411号 - Strolyのその他の技術全般、逆方向の変換、方角と縮尺を一致させる変換、連続変換時に全単射変換に見せかける処理、不正確な地図同士の間の変換などを全般的に定義した特許

現行のStroly社の実装を特許で守っていない特許5681920号

まず、Strolyのもっとも基本的な特許である、経緯度から絵地図座標方向への座標変換の手法を定義した特許について見てみます。
この特許の本文を読み進めてみましょう。

f:id:kochizufan:20190711005355p:plain
特許5681920号より引用

ご覧の通り、ここでは正確な地図の方の座標が「絶対位置座標」と言う名称で定義されており、そしてその後に、「絶対位置座標とは緯度経度系である」ことが定義されています。
当然のことながら、緯度経度系というのは直角座標系ではなく極座標系です。
ということは、その後の幾何学計算も極座標であることを前提に計算式がたてられないといけないのですが、この特許の中では、直角座標を元にした幾何学計算で式が綴られます。

f:id:kochizufan:20190711010545p:plain
特許5681920号より引用

ぶっちゃけこれだけでも意味のない計算をしているということで特許無効だと言ってもよさそうなものです。
恐ろしいことに、2009年に私がStroly社にジョインするまでのプログラム実装では、本当に「経緯度の座標値を使って3平方の定理で距離を求める」など、極座標値で直角座標の幾何学計算を行なっており、完全に意味のない計算を行なっていました。

それを意味のある計算にするために、絶対位置座標の値として直角座標であるWebメルカトル座標値を用いるように変更したのが私です*1
ところがそのために、特許では「絶対位置座標 = 緯度経度」と定義されてそれを元にした数式も記されているにも関わらず、実際の実装は「絶対位置座標 = メルカトル座標」となっており、特許と比較して「緯度経度をメルカトル座標に変換する」という余分な計算手順が入っています。
つまり、現行の実装は特許に記された通りになっておらず、この特許で守られていない、という問題が存在します。

まとめると、特許5681920号には、

  • 極座標を明言しつつ直角座標系を元にした式が記載されており、無効の可能性もある
  • 仮に有効だとしても、現行の実装は特許に従わない手順になっており、守られていない可能性もある

という問題が存在していると言えます。

既に陳腐化してしまっている特許5681920号

上記な問題点があったとしても、特許5681920号が有効でさらに実装も守られていると、飽くまで仮に、しましょう。
しかし、特許5681920号は既にそれを上回る技術で陳腐化してしまっています。

以前から何度か記事に挙げている、MaplatがStrolyに優る部分劣る部分のマトリクスを再掲します。

f:id:kochizufan:20190707001822p:plain
最新のStrolyとMaplatの長所短所比較

このうち、特許5681920号と比較できるような性能要件は、

  • 1対1全単射変換 - Maplat:できる(特開2019-91147の内容)、Stroly:できない
  • 線を線に変換 - Maplat:できる(特許出願は未定)、Stroly;できない

ですが、これらでStrolyの特許は劣っており、既に陳腐化しています。

しかしながら、全単射変換できるかとか、線を線に変換できるかとか、そんなに大切な性能なのでしょうか。
もし、それらが大切な性能ではないなら、別にStrolyが劣っていても全然構わないかもしれません。
では実際にはどうなのか、「Stroly自身がどう考えているか」を見てみましょう。
Stroly側の2つ目の特許、特許5810411号の中の記述を見てみます。

f:id:kochizufan:20190711013706p:plain
特許5810411号より引用

はい、なんと書いてありますか。
この特許5810411号は特許5681920号を前提にした特許なので、ここでの説明は特許5681920号の性能についてですが、ある座標Xa, Yaを順変換Ωと逆変換ωで連続変換してXaΩω, YaΩωを求めた時、「(Xa, Ya) と (XaΩω, YaΩω)が一緒であることは保証されない」と書いてありますね。
そしてそこからの続きは、「特許5681920号では保証されないけれど、保証されているかのように見せかけるための技術」をつらつらと書いて、その内容で特許を取ってますね。
はっきり言うと、Maplatが実現した全単射変換機能は、Strolyができないと自身の特許の中で明言し、なんちゃって機能でごまかした、「(Xa, Ya) と (XaΩω, YaΩω)が一緒であることを保証する」機能です。
つまり、「Maplatができること」を、Strolyは自身の特許のなかで「やりたいけどできないこと」として明言しており、つまりは自らMaplatに対する負けを明言していることになります。
このくらい酷く、Strolyの特許はいまや完全に陳腐化しています。

特許を保持しているといいながら、実装で再現する力がなくなってしまっている特許5810411号

続いて、その2つ目の特許5810411号の内容について精査してみましょう。
この特許は広範な特許で、Strolyの特許技術のうち、特許5681920号がカバーする単方向の座標変換を除く、ほぼ全ての技術を網羅しています。
ちなみに、発明者は私の単独名特許です(特許を行使する権利はStroly社にありますが)。

余談ですが、Strolyの特許も単方向座標変換以外は私の特許、既にStrolyの性能を超えているMaplatも当然全て私の頭の中から出たものです。
従ってこの地球上に存在する古地図を歪ませずに扱う技術のうち、9割以上は私の頭の中から出ています。
この優位性はStrolyが、どれだけ世の中の普通の意味で優秀な人材、pythonの達人や機械学習の博士や一部上場企業の開発部長やを集めようが、突き崩すことはできません。
今後古地図を扱う技術について、Maplatが様々なブレークスルーを産むことはあれ、Strolyから画期的な新技術が生まれてくることはほぼ100%あり得ません*2

閑話休題、特許5810411号の内容に戻ります。
今回、この特許がカバーする広範な機能の中で、「方角と縮尺を一致させる変換」について注目してみます。

f:id:kochizufan:20190711020241p:plain
特許5810411号より引用

この機能は、複数の地図を切り替えた際に、中心点の位置だけでなく、地図全体の縮尺や方角も大まかに合わせる機能です。
Strolyは当初中心点の位置合わせや、GPS現在地を青い点で古地図上への表示だけしかできない技術でしたが、それだと現地に行って現在地がGPSで表示された時にしかあまり面白くありません。
なぜなら、古地図には北が上でない地図もたくさんありますし、縮尺も当然現代地図とは違います、すると、中心点だけ一致しててもその周辺の状況が古地図と現代地図の間で重ならないため、ユーザにとっては古地図と現代地図のどこがどう対応しているのかピンと来ず、地図を切り替えても楽しくないからです。
地図を切り替えることが面白いと思ってもらえないならば、Strolyは単なる古地図画像ビューアにしかなりません。
現地に行かなくても地図を切り替えるのが面白いと思ってもらえて初めて、Strolyは何時見ても楽しいソリューションになり得るわけです。
そう言う議論があった上で、実現したのがこの特許の「方角と縮尺を一致させる変換」になります。

では、今現在のStrolyで、この機能がどのように動作しているか試してみましょう。
検証手順は下記の通りです。

  1. 以下のStroly URLにアクセスする stroly.com
  2. 右下のf:id:kochizufan:20190711021558p:plainボタンで地図をOSMに切り替える
  3. 古地図の時の海岸線とOSMの海岸線が全く合わない!

全く合わない両者の海岸線

これは正確に説明すると、「方角と縮尺を一致させる変換」のうち、方角を合わせる機能は動作しているが縮尺を合わせる機能がずれてしまっているために起こってしまっています。
このバグについては、昨年(2018年)11月にStrolyの開発担当に通知済みですが、もう半年にわたり修正されていません。
おそらく、特許の動作原理がわかる人間がもう中に誰もいないので、直し方もわからなくなっているものと思います*3

正直、投資家に対する背信的技術経営状況と行っても過言じゃないのではと思える

これは正直、技術経営的に相当にまずい状況じゃないかと思います。
Strolyはこれまでに5億近く資金を調達してきていますが、その資金を調達するに当たっては、VCにこんな特許を押さえてきていますから、と説明して、自社に価値があると思わせて調達してきたはずです。
が、蓋を開けてみれば、物理的におかしなことを述べていて無効の恐れすらある特許や、現行のやり方を守っていなさそうな特許、完全に陳腐化していてライバル技術が実現している事を「できません!」と高らかに宣言している特許、そして特許でできると宣言しているのにそれを具体化する技術が失われている特許。
この状態を放置しているのって、技術経営の投資家に対する背信状態ではないのでしょうか。

また、過ぎた投資についてはもういいのだと仮にしましょう。
このような特許状況にあったと言うことは掴んでなかったのだ(それ自体問題ですが)、嘘をついたわけではない、と言い逃れられるとしましょう。
しかし、次の資金ショート時に次ステージの資金調達時、どのように投資家にプレゼンするのでしょうか?
私はもう、検証記事を書きました。
いくらこちらを無視していたとしても、年単位で後の次の資金調達までには、Strolyの経営陣に伝わるでしょう。
うちはまともな特許持ってないですけど、次の資金5億10億ください、とプレゼンするのでしょうか?
いや、1万歩譲って、この特許検証がStroly経営陣まで伝わらなかった、そんなわけないのだけど、伝わらなかったふりをして特許はまだ価値があると信じているふりができたとしましょう。
それでも、彼らは既にMaplatを知っています、これは嘘はつけません。
資金調達のプレゼンだと競合分析などもしないといけないと思いますが、どのようにプレゼンして資金調達するのでしょうか?
資金も調達してない個人のオープンソースプロジェクトなのに、うちより機能も性能も上な競合技術が存在しますが、次の資金5億10億ください、とプレゼンするのでしょうか?
果たしてどのようにしてStroly社が次の資金調達を乗り切るのか、なかなか楽しみではないでしょうか。

余談

この記事を書くために特許周りを漁っていて、Strolyが他に出した特許を見つけました。
Google Patentにまだ入ってなかったのでリンクが貼れませんが、特許6537702号です。

f:id:kochizufan:20190711025536p:plain
特許6537702号より引用

地図を処理する技術ではなく、地図DBからユーザのコンテキストにあった地図をリコメンドする機能のようです。
その手の技術についてStrolyが特許を出しているのは掴んでいたのですが、せいぜいユーザの現在地や注視点をベースにした周辺検索で、地図のサイズによって優先順位をつけるとか、その程度の話かと思っていたら、ユーザの人気度や口コミ評価なども加えてスコアリングする事を考えているようで、ちょっと思ってたのと違って面白いです。

が、ユーザの人気度とかによるスコアリングは、メディアとかを運営するレベルの事業者だけが視野に入れればいい話で、単に地図処理システムのユーザ利便性要件としては、現在地や注視点等の経緯度をベースにして、あとは今のユーザが注目している地図スケールにマッチする地図のサイズのコンテキスト等でソートできれば十分だと思います。
そう言った程度のことを考慮して地図DBから地図をソートして抜き出す手法は、このブログで過去に記事にして取り上げています。

blog.chizuburari.jp

この記事はStrolyが特許を出すはるか前の2012年に書かれた記事ですから、この記事に書かれた内容でのリコメンデーションロジックについては、もし仮に上記特許に何か抵触するような内容が書かれていたとしてもこちらがはるかに先ですから、ごちゃごちゃ言ってきたら特許不服請求もできますし、公知のオープンアイデアとして誰でも使ってもらえます。

*1:ここでGISに詳しい人ですと、そこでWebメルカトルにするのも間違いだ、UTMとか平面直角座標にすべきだったという人もいるでしょう。おっしゃる通りで、GIS的にはそれらの方がより正しいです。ただ、Strolyの場合は、またMaplatの場合も、切り替える先の正確な地図の方がWebメルカトルの地図なので、それにぴったり重なるように座標変換するという意味では同じ座標系を使うのが一番だろうということもあり、また全世界一律に使える簡単の意味もあって、Webメルカトルを採用しました。

*2:とはいえ、Strolyの最初の座標変換の特許5681920号は、私ではないStroly社独自の特許なので、古地図を歪めずに正確な地図と対応づけると言う発想だけはStrolyオリジナルで、Strolyに一時期在籍したMaplatはそれの真似をしている、と思われる人もいるかもしれません。これについては、確かに基本技術の特許は、Strolyの特許5681920号は私の特開2019-91147よりもはるかに前に出ており、特許の順番だけでいえばその通りとしか言いようがありません。また私自身、Stroly中に在籍した際に、同社の業務や社員とのディスカッションの中で必要性に気づいた古地図処理技術もあり、Strolyに大きな影響を受けたのは事実です。しかしながら、元々「古地図を歪めずに正確な地図と対応づけると言う発想」まで遡ると、私はStroly社に転籍する前から持っており、その当時から今のMaplatと同じ三角網で全単射変換を保証する形でそれを実現するアイデアを持っておりました。Strolyに合流する前のMapion社にいた時代から、(私の転職で立ち消えたものの)東京大学の有川先生と共に伊能図をそのままWeb地図にするプロジェクトを進めていましたし、それで三角網で座標変換する技術を実現するつもりでいました。ぞれができなかった理由は、こちらのQiitaの記事にも書いたように、三角網を計算するロジックを自分で書けなかったのが原因であり、それをやってくれるturf.jsが登場したおかげで、Maplatは急速に実装が進んだのです。turf.jsがなかった頃は私のアイデアは形にできなかったので、次善的に不十分な性能ながら既に古地図技術を実現していたStrolyに合流したのです。そして、三角網で全単射変換をするという私のアイデアはStroly社内で共有し、同社現CEOなどにも、将来のStrolyの基礎技術として差し替えられる予定の内諾を得ていました。つまり、Maplatとは、私がCEO達に騙されて退職に追い込まれなければ、Stroly2.0になることで同意を得ていた技術になります。

*3:つまりは、現地に行かなくても古地図を楽しめるようにするための機能が働かなくなってしまっていると言うことです。最近、Stroly Blogで、「部屋から出ずとも名所はめぐれる」と題した記事が公開されましたが、まさにその部屋から出ずに古地図を楽しむための技術をダメにしておいて何言ってんだ、と思っちゃいました。

[特許共同出願者募集その1]Maplat、Strolyなどで用いられるGCP登録の機械学習自動化手法案

MaplatやStrolyで古地図を扱うには、GCP(Ground Control Point)と呼ばれる、古地図上の座標と正確な地理座標を対応づける対応点データを多数整備する必要があります。
この対応点数点の周りでベクトル計算をすることにより、座標変換計算をするのが古地図座標を扱えるタネなので、このGCPをいかに整備するかが古地図技術のキモとも言えるところになります。
今現在は完全に手動でやるしかなく、簡単な地図ならば10点とかそこらで済む場合もありますが、複雑な地図だと1000点以上打つ場合もあります。
まあ私のような古地図好きにはいかに大変でもご褒美のような作業ではあるものの、それでも時に面倒臭い...と思うようなこともある作業なので、あまり古地図などが好きなわけではない人にとっては苦行のような作業と言えるのではないかと思います。

f:id:kochizufan:20190708013135p:plain
古地図を扱えるようにするために、GCPを登録する作業。地味で時間のかかる仕事。

なので、機械学習などを利用してこれを自動化しようという発想は昔からあり、実現方法の腹案も持っていました(それについて述べるエントリなので、どのような事を考えていたかはあとで述べます)。

Stroly社に騙されて同社の外部に出てMaplatの開発を始めてからというもの、Stroly社は私にとって商売敵といっていい存在でした。
ですので、Stroly社が私より先にGCP登録の自動化手法を確立しないか、というのは私がずっと恐れていたところでした。
MaplatとStroly技術のベースになっているGIS分野の知識と発想については、私がGISの専門家が一人もいないStroly社に負けるわけがないのでそこは全く心配していませんが、ことGCP登録の自動化については、機械学習は私も全く専門家ではありませんから、資金力で専門家を雇えるStroly社の方に相当の分があります。
実際Stroly社の社員には機械学習の専門家もいるようなので、私が思いついているような方法はとっくに思いついていて、もう投入寸前じゃないかと戦々恐々としていました。
ところが、待てど暮らせどStroly社が機械学習によるGCP登録自動化を投入する素振りが見えません。
そこで、Stroly社の機械学習GCP登録自動化の現状がどんな感じなのか、信頼できる中の人に尋ねてみました。

その結果は驚くべきものでした。
なんと、Stroly社が取り組もうとしている機械学習でのGCP登録自動化は、地図画像からの地名を検出して、それを基にジオコーディングして、GCPを3,4点だけ打つ、とかその程度のものらしいです。
そしてそのチャチい内容ですら、機械学習部分はほぼGoogleの提供する機能に丸投げですし、そしてその程度の内容すら、長い期間かけてまだ実用化できずに投入できていないと。
地名からのジオコーディングで数点GCP打つって、そんなもん、GCP登録作業始める前に、正確な地図側で古地図の示している領域を検索して表示する、手作業でやっても早ければ数十秒、長くても5分もかからない作業が省略できるだけの話にしかなりません。
もっと強烈に時間がかかる、その後の数百、数千とGCPを登録する作業が半自動化できないと何の競争力も持てないでしょう。
あらためて確信しましたが、このStrolyという会社、新技術や新プロダクトの開発におけるテーマ決めのセンスがおそろしく悪い。

私が考えていたのはそんなチャチいレベルではない、整備する必要のあるGCPの5割くらいは自動生成できるものを目指す案を考えているので、機械学習を取り入れる分野ですら、Strolyという会社に対する恐怖は全くなくなりました。
とはいえ、先に書いた通り私も機械学習の専門家ではないのでアイデアだけ死蔵しててもそれ以上先に進めるスキルがないので、ここで考えていることを公開した上で、現実化するための協力者を募りたいと思います。
今から私が書くレベルの雑い素案では全然特許とかに出せるレベルではないと思いますが、特許は考え方を学会発表やWebサイトなどで公開してから半年は優先権があると聞いているので、これを公開してから半年の間に協力者との間で粗い案を精緻化できれば、特許化できる可能性も十分にあるのではないかと思います。
また特許化できなくても、誰もが自由に使えるオープンアイデアになるのであればそれはそれで。

私のGCP登録自動化方法のアイデアは、次のようなステップを踏んで実現するものです。

  1. 古地図の側で、画像処理あるいは機械学習などで、道路および水系のエッジを抽出し古地図側の道路/水系ネットワークを生成する。
    道路だけでなく水系も取る理由は、歴史の経過の中で水系は暗渠化などで容易に道路などに置き換わるためです。
  2. 現代地図において、OSM国土地理院発行の地図データなどを用いて、現代地図の道路/水系ネットワークを得る。
    これは画像処理など使わなくとも、元々ベクタなデータを使えばそのままネットワークが取得できます。
  3. (ここは必要に応じて)数点、ヒントとして人力で、古地図と現代地図間の対応するネットワークのエッジ交点を指定する。
  4. 3.のヒントなどを頼りに、ネットワーク構造の類似性を機械学習で抽出し、対応するエッジ交点を全て抽出し、対応点(GCP)とする。
    あるいは、最新のMaplatでは対応点だけではなく対応線という概念も誕生しているので (該当記事)、GCPだけでなく対応線も自動指定することも考えられる。

という手順でのGCP指定自動化を考えています。
が、画像処理や機械学習の周りは私に完全にノウハウがないので、その辺の所に詳しい方や企業で具体化に力を貸してくれる方、一緒に特許取得を目指してくれる方おられましたら、ぜひ rekishikokudo (@) tilemap.jp までご一報いただけると嬉しいです。
なお、古地図と現代地図の道路/水系ネットワーク間の類似性から対応点、対応線を抽出する技術には、機械学習だけではなく、こちらの会社の技術なんかも使えるんじゃないかなと思って注視しています。

sharedstreets.io

この会社の技術は、異なる会社の生成した、微妙にジオメトリが異なる地図間で、対応付けを生成して各々の地図間での道路属性などをマージしたりできる技術のようなので、古地図の道路ネットワークと現代地図の道路ネットワークのような、似ているけれど微妙に違う関係性などもうまくいけば処理できるのではないかと期待しています。

Maplatが「線を線に変換する」新機能に対応しました。実証サンプルとして宇野バスのバス運行路線図Webアプリ作成。

私の開発している古地図絵地図アプリMaplatですが、Maplatリリース0.5.2以降、MaplatEditorリリース0.3.2以降で、「線を線に変換する」機能に対応しました。
どういうことかというと、これまでのMaplatは古地図と正確な地図の対応を、例えば交差点と交差点というような点と点の対応づけで定義してきました。
が、当然複数の交差点と交差点の間にはそれを結ぶ線としての道があるわけですが、正確な地図上での道を歩いても、その変換結果が対応する絵地図側の道にぴったり乗ってくるとは限らないという問題がありました。
具体的には、英語の発表資料からの引用ですが下の図のような状況になります。

f:id:kochizufan:20190706214347p:plain
これまでのMaplatで道が正確に変換されない事例

Maplatでは対応点群が与えられた際に、自動でその対応点を用いた三角網が計算され、その三角網内でのベクトル演算で座標変換が計算されます。
その変換手法の特性上、三角網の辺上の点は正確に辺上に変換されるので、偶然対応点間の道路に三角網の辺が重なればその道路は正確に変換されますが、もし道路が三角網の辺と交差してしまった場合、その道路上の変換は正確に変換されない可能性がある、という問題がありました。

新しい機能では、それを以下のような手法で解決しました。

f:id:kochizufan:20190706221854p:plain
対応点同士を結ぶ道路の上に対応線というものを導入した

道路のような線の上に定義する、2つの対応点を結ぶ対応線という概念を導入しました。
この対応線は、対応点から三角網を生成する際に、必ず辺として採用されるようにしました*1
なので、この対応線上の点は、正確にもう一方の地図の対応線上に変換されるようになりました。

これだけだと直線を直線にしか移せないのですが、もう一歩進んで、一方または両方が曲線だったりしても対応づけができる方法を考えてみました。

f:id:kochizufan:20190706224502p:plain
曲線(Polyline)でも、もう一方の対応線に自動で補助対応点を挿入して三角網が作れるようにした

曲線(Polyline)の場合の問題点は、三角網の辺は当然直線しかなり得ないので、Polylineの曲がる頂点は必ず三角網の頂点、つまり対応点にせざるを得ないのですが、対応点にしようにももう一方の地図の方で対応する点が定義できないことでした。
それを、対応線の長さに対する割合に応じてもう一方の地図の対応線上にも補助対応点を定義することによって、Polylineでも三角網が定義できるようにしました。
これにより、複雑な現実の道路形状が古地図や絵地図上で抽象的に描かれているようなケースでも、道路の上を道路の上に対応づけることが可能になりました。

もちろん、いい事ばかりではありません。
Maplatには線を線に変換する以外にも、三角網でトポロジーエラー*2が発生しないようにデータを作った場合に限り、地図間の座標変換で全単射変換を保証するという特徴がありました(全単射変換については下の資料のページ28以降参照)。

www.slideshare.net

ところが、対応線を導入した場合、特に曲線の対応を導入した場合、構造の複雑さにもよりますがトポロジーエラーを発生させないようデータを制御するのが難しくなり、全単射変換を保証できるデータを作りにくくなってしまいます。
これについては、元々全単射変換を保証しないといけないような地図の種類と線から線に変換を保証しないといけないような地図の種類は異なると思うので、それほど大きな問題にはならないと思っています。

今回、この機能を使って何か実証アプリ的なもの作れないかなあと考えていたところ、最近GIS仲間周りで話が盛り上がってるバスロケーション共有仕様のGTFS周りで何かできないかなと思い、宇野バスのGTFSなどオープンデータと路線図を用いて、宇野バスの経路表示とバス運行情報表示アプリを作ってみました。

s.maplat.jp

f:id:kochizufan:20190706235041p:plain
OSMを背景画像にしての路線表示、この複雑な路線ジオメトリが...

f:id:kochizufan:20190706235133p:plain
路線図に切り替えると、ちゃんと路線図の線上にほぼ載ってくる

このような線を線に変換する機能、あるいは以前からの全単射を保証する機能は、Maplatの類似技術であるStrolyでは、原理的に将来にわたり絶対に実現できない機能になります。
何故ならば、StrolyもMaplatと同様、地図間の座標変換に対応点の作る三角からのベクトル変換を用いていますが、その三角の決定に、Maplatは実績あるGISの知見を取り入れて三角網を生成しているのに対し、Strolyは変換対象点の近傍の対応点3つを選び、それの作る三角形からの変換を行なっているからです。
あらかじめ生成された三角網で変換するのではなく、都度都度選択される近傍点での変換のため、Strolyはどの点をどの対応点のセットで変換するかということを意図的に制御するのが極めて困難です。
全単射変換を維持するために変換前後の地図のトポロジーを維持したり、線を線に変換するために、この道路上は必ずこの三角の辺を使って変換する、ということを定義することがほぼ不可能です。
よってこれらの機能の優位性は、未来にわたり、StrolyではキャッチアップできないMaplatの絶対優位性と見ていただいて問題ないと思います。

f:id:kochizufan:20190707000232p:plain
Strolyは各点の変換に用いる対応点の三角を意図的に制御することができない

また、今回の宇野バスアプリは、線を線に変換する機能以外にも、いくつものMaplatの対Stroly優位性のある機能を使って実現しています。

f:id:kochizufan:20190707001822p:plain
最新のStrolyとMaplatの長所短所比較

まず、バスの運行情報をGTFSから取ってきて地図上に表示するには、地図をUI表示なしで表示して、動作をAPIで制御する必要がありますが、そのためにはまず地図表示をiframeによる擬似埋め込みではなく、divタグによって本当にhtmlページの一部に埋め込めないといけません。
何故なら、iframe埋め込みだと、親ページからの制御を読み込まれた子ページに与えることが、セキュリティの制限によって実現できないからです。
しかし、Strolyはiframeでのページ埋め込みにしか対応できていません。

また仮にiframeでなくdivでの埋め込みに対応していたとしても、StrolyにはUI以外に、外部から制御できるAPIがありません。
そのため、何か表示内容を変えようと思うと、手作業でエディタでデータの内容を変更しなければいけなくなります。
実際、過去に「ホリエモン祭」で会場地図としてStrolyが使われた際には、担当者が常時手動でホリエモンの位置を更新していたようです。

Maplatだと、宇野バスアプリでバスの運行位置を常時更新できているように、APIでピンの表示位置や状況を変更できるので、ホリエモンの現在位置を常にサーバか何かに送りつけるシステムさえ作っておけば、あとはシステムが勝手に現在位置を更新してくれるシステムだって作れます。

また、バス路線ジオメトリを表示するために使った線を引く機能も、Strolyにはない機能です。
MaplatではAPIで地図上に線を引くことができますが、Strolyは手動、APIを問わず線は引くことができません。

このように、StrolyにあってMaplatにはないWeb上での利用が簡単なエディタ機能は確かにStrolyの大きな魅力ではあるのですが、それ以外ではもう様々な機能でStrolyはMaplatのはるか後ろを走っている状態です。
ちょうど1年くらい前にこのブログに書いた記事では、まだMaplatもいろいろ機能の不足があったため、「StrolyとMaplatは一長一短、使い分けて」と書きました。

blog.chizuburari.jp

が、その後1年を経てMaplatには数々の機能がつき、1年前にStrolyにMaplatが劣っている短所として書いた「1つの画像に複数の地図が共存可能」も既に開発済みで解消され、「StrolyがMaplatに劣っていること」は山のようにある一方で、「MaplatがStrolyに劣っていること」はもうWebエディタがあること以外にはない状態です。
クソほど劣った技術だけれど、Web上だけで簡単に導入できることに魅力を感じる一般ユーザを除いては、システムの一部や機能の一部として業務用途に使いたいユーザにとって、これからStrolyを採用する理由は微塵ほどもありません。
ぜひ、これを機にMaplatに興味を持って、使っていただければと思います。

最後になりますが、Maplatで少額募金や企業からの募金支援を受けやすくしようと、募金サイトOpenCollective

opencollective.com

でMaplatのアカウントを作ろうとしましたが、githubオープンソースプロジェクトだとスターが100以上稼げているプロジェクトでないとアカウント作成可能対象にならないようです。
現在58スターなので、あと42スター稼ぐ必要があります。
githubでアカウントお持ちの方、ぜひご協力いただければ幸いです(スター返しなどもお引き受けします)。
スターつける対象のプロジェクトは以下の通りです。

github.com

よろしくお願いいたします。

*1:このため、三角網の生成ロジックを、TIN(Triangulated irregular network)という手法から、制約付きドロネー三角網(Constrained delaunay triangulation)という手法に変更しました

*2:三角網の形成する三角同士が、もう一方の地図で重なり合ったりしてしまうこと

祝ミリシタRebellion配信! MaplatのテーマカラーはRebellion Redです

スマホ音ゲーアイドルマスター ミリオンライブ シアターデイズ(略称ミリシタ)が現在2周年キャンペーン中なんですが、その最中に通常楽曲として、ついに我那覇響の「Rebellion」が配信されました!

www.nicovideo.jp

www.nicovideo.jp

この曲は私の大好きな曲で、その歌詞の内容*1が、Strolyに裏切られてたった一人でMaplatを開発していて、何度も心折れそうになっていた時に出会って、私を勇気付けてくれた2つの曲の1つでした*2

実は、Maplatのテーマカラーである#780508の赤系カラーも、Rebellion Redという色名の色*3から採っています。
その意味で、RebellionはMaplatのテーマソング的にも私は考えています。

まあそれだけの話なのですが、嬉しかったので記事にしてみました。

[古地図こぼれ話3]毎日新聞ならまち暮らしでも取り上げられた京終天神社の歴史について

www.facebook.com

作家の寮美千子先生の連載、毎日新聞のならまち暮らしで、奈良京終地域に鎮座する京終天神社(飛鳥神社)が話題に採り上げられました。

ja.wikipedia.org

記事中で京終天神社の社伝と歴史書に残る史実の違いについて触れられていますが、この記事の作成に、私がそれまでに調べていた情報などを提供して協力させていただきました。
本ブログで、毎日新聞側記事では字数などの問題で載らなかった詳細を補足させてもらいたいと思います。

江戸中期の書物「奈良坊目拙解」には、京終村と高畠村(現在の高畑町)で水争いがあり、百姓を殺害された高畠村が幕府に訴えて出たという血生臭い事件が記されている。このとき、京終村の人々が京都の北野天満宮に加護を祈ったところ、無罪となり、京終村が高畠村より先に取水することを許された。そのしきたりが、いまでも続いているそうだ。

これに感謝して北野天満宮が祀(まつ)る菅原道真を祀ったのが、北京終町にある「京終天神社」であるという。

享保15年(1730年)ごろ成立した奈良の地誌、「奈良坊目拙解」の「京終町」の条には上記記事引用の通りの内容が、年月等には触れないままに記載されています。
その訴訟勝利の神恩に感謝するため、天神社の祠を祀ったのが、京終の天神社の始まりだと記されています。
同じような記録は延宝6年(1678年)ごろ成立した別の奈良の地誌、「奈良名所八重桜」の「富士権現」の条にも似たような記録が残っており、同じように京終村が水論で他の村と争って幕府で訴訟になり、勝利を神に祈って勝てたためその神を勧請したという記録がありますが、八重桜ではいくつかの違いがあり、

  • 水論をして村人を殺してしまった相手の村は高畠村ではなく鹿野苑
  • 勧請したのは天神ではなく富士権現。また、新たに祠を作ったのではなく、元から伊勢、春日を祀った京終村氏神があったところに、追加で勧請した。
  • 年代は不明ではなく慶長18年(1613年)と明確

といった違いがあります。

これらの地誌は現在から比較するとはるかに近い時代の事柄を記録していますが、しかしながらどうしても同時代の一次資料ではないため完全に信じることはできませんが、同時代の一次資料的記録として、「本光国師日記」と呼ばれる金地院崇伝の日記に、慶長19年(1614年)4月20日の条として京終村水論の訴状が残されているそうです。
そのため何らかの史実に基づいているのは間違いなく、奈良坊目拙解と八重桜の記述の違いは似たような事件が2つあって京終には天神と富士権現の両方があったのか、それとも八重桜が天神を富士権現に取り違えて記録したのか*1まではわかりませんが、何れにしてもその他の地誌まで確認しても、江戸期の記録に見える京終の神社は天神または富士権現とした記録のみで、今の飛鳥神社祭神とされる事代主神を祀った記録は一切残されていません。

飛鳥神社の今に残る社伝を信じると、江戸期どころか室町の初めには、元興寺鎮守の飛鳥神社が京終に移転していたはずなのですが、その存在が京終村の記録として奈良の地誌に残っていないのはどう考えても変です。

ここから、「京終天神社」は、明治・大正期には「紅梅殿社」と呼ばれるようになった。

1889年(明治22年)の奈良絵地図 s.maplat.jp

1917年(大正6年)の奈良絵地図 s.maplat.jp

などでは、確かに紅梅殿神社と記されています。

無格社だったこの神社が宗教法人として法人格を取得したのは1953年(昭和28)。申請書に「明日香鎮座の元興寺鎮守社が、平城遷都に伴って平城京に移されたもの。古くは平城坐飛鳥天神社と呼ばれていた」という旨の社伝が記されているので、その名を掲げ、以来「飛鳥神社」と呼ぶことにしたという。

先にも書きましたがこの「明日香鎮座の元興寺鎮守社が、平城遷都に伴って平城京に移され(て、さらに室町初めに京終に移された)」という京終村の記録は、1953年の宗教法人の申請書に書かれた社伝以外には一切残っていません*2
では、京終村以外では残っているのか?というと、実は残っています。
先にも出た「奈良坊目拙解」の、「西ノ新屋町」の条には、同町内に「飛鳥神並神社」一座が鎮座している、という記録があり、元々元興寺鎮守社で、高市郡の飛鳥法興寺から遷座してきた、と記されています。
それに続けて、「近世(この飛鳥神並神社を)率川明神と号すがよくない説で、飛鳥川は率川と和語が似ているので謬って伝えたので正さなければならない」と「奈良坊目拙解」には記されていますが、これが今に残る西新屋町の率川神社です。

ja.wikipedia.org

同様の記録は、やはり江戸時代の地誌である「本朝佛法最初南都元興寺由来」や、1890年(明治23年)発行の「平城坊目遺考」などにも、やはり「飛鳥神並社、今は誤って率川神社あるいは率川阿波神社となる」という形で記されています。
京終飛鳥神社の社伝と比較して、

という点で一致しており、これに「室町初期に京終に移された」という項目を加えると、そのまま京終飛鳥神社(京終天神社)の社伝になります。
ところが実際には、飛鳥神社社伝が京終に移ったとするよりはるか後の江戸期資料でも、この元興寺鎮守社が京終に移ったという記録はなく、西新屋町の率川神社こそが飛鳥神社を名乗るべき、という記録しか残っていません。
この事は、江戸時代よりも後の後世に、西新屋町の率川神社の由緒を参考に、京終飛鳥神社の社伝が創作された可能性を強く示唆すると思われます。

それでは、飛鳥神社社伝が創作されたとして、いつ頃創作されたのでしょうか。

まず京終天神社側の状況は、「ならまち暮らし」内にも書かれ先に古地図2枚を引用したように、明治大正期は京終天神社は紅梅殿神社と呼ばれ飛鳥神社とは呼ばれていなかったので、社伝を創作する意味がありません。
西新屋町率川神社の方は、

1889年(明治22年)の奈良絵地図「率川飛鳥神社」と記されており、まだ「飛鳥神社」の名称が残っている s.maplat.jp

1917年(大正6年)の奈良絵地図、「阿波神社(率川阿波神社の略か)」となっている s.maplat.jp

となっており、率川神社=飛鳥神社であることが大正期に忘れられつつあったのではないかと推察されます。

つまり大正までは社伝を創作する目的がなかったので創作は昭和以降という事になりそうですが、ではいつ創作したのかという事になると、「社伝」などというものを登録しなければいけなくなった戦後、宗教法人として法人格を取得した1953年(昭和28年)その時ではないかと私は考えます。
宗教法人になる際に社伝、由緒を登録する必要が生じて、中世の大火で古文書が失われ伝わってきた社伝がなかった京終天神社が、忘れさられつつあった西新屋町率川神社の社伝を借りて創作したのではないか、というのが私の考えです。

社伝が100%創作物だ、という証拠はありません。
また、社伝が創作物であってもそれがどうした、寮さんもならまち暮らしで書かれているとおり、信仰の場で人々が何を心の拠り所にしているのかこそが大切だ、ということもわかります。
が、一方で私は、京終の鎮守が、そんな国家鎮護元興寺のそのまた鎮守社だった、などと言うような大仰なものでなくても、京終村を昔から水論で勝てるなどの現生利益で守ってくれた、地元密着の身近な守り神だった、それだけで十分ではないかと思うのです。
また心の拠り所だからこそ、それが正しくどのような言われがあってどういう歴史を辿ってきたのか、どう祀られてきたのか、正しく伝えられていくべきだと思うのです。
また少なくとも、伝説の領域を外れた史実を語る場では、今は社伝を元にしてしまっているため、本来は史実が語られるべきはずの奈良市史、奈良県史などでも京終天神社を「元興寺鎮守社だった」と記してしまっていますが、今後はそのようなことがないよう、史実が史実として紛れなく伝わっていくよう、情報を残していかないといけないと思うのです。

そのような思いを込めて、このブログ記事を残させていただきました。

*1:全般的に、その他の項目を見ても「八重桜」は他の地誌と比べて独特の言葉遣い、例えば他の地誌では勧修坊と記される寺を寛俊坊と記したり、勝願寺を聖願寺と記したり、と言ったものが多いので、記録間違いを疑う余地はありそうです。

*2:ただし、その新しい社伝より後に記された書物で社史を参考に書かれたもの、例えば奈良市史、奈良県史、角川日本地名大辞典などにはこの記録が採用されています。

[古地図こぼれ話2]アニメ「宇宙よりも遠い場所」の舞台に見る館林の歴史

アニメ「宇宙よりも遠い場所」(略称;よりもい)をご存知でしょうか。
女子高生世代*1の女の子4人が、友情を育て成長しながら南極を目指し、そしてまた日常へ帰っていくという青春ロードムービーです。
その人間味あふれた、完成度の高い構成が評価されて、昨年度の米ニューヨークタイムス紙ベストテレビショー特集海外部門で、日本の作品として唯一、またアニメ作品からも唯一、ベスト10に選出された等の結果も持っている、非常に評価の高い作品です。

www.animenewsnetwork.com

その「よりもい」の前半の舞台になっているのが、群馬県館林市です。
館林市が舞台に選ばれた理由は、南極という極端に寒い場所と、日本で一番暑いと言われる?場所との対比だと聞いていますが、古い城下町の独特の雰囲気が作品前半のイメージにマッチして、作品の魅力を増しています。
実際、聖地巡礼と称して、作品に登場した魅力的な場面を実際に訪れるファンの人たちも大勢います(というか、私もその一人です)。
ですが、その魅力的な街の風景は、街の歴史によって育まれてきたわけですが、どのような歴史を経てアニメ中の魅力的な街並みが生まれたのかは、あまり語られていない気がします。
本記事では館林の古地図を開きながら、「よりもい」の舞台となった場所の歴史を紐解いていきたいと思います。

記事中で引用されている古地図、およびよりもい巡礼マップに関しては、一部を除き、拙作の館林街歩き観光アプリ、「ぷらっと館林」上で公開されています。
この記事で興味を持たれた方は、ぜひそちらを用いて館林の街歩きを楽しんでみてください。

s.maplat.jp

物語の動き出す交差点 - 大辻

まずは物語中でも重要な意味を持つ場所、キマリと報瀬が南極へ行く絆を危うく壊しかけながらも持ち直し、またキマリと日向が出会うきっかけとなった2人のバイト先がある、館林本町二丁目の交差点から。
ここは多くの周辺カットが作中で描かれている他、キマリと日向2人のバイト先と特定できるコンビニが実際にある点で、巡礼でも屈指の有名スポットとなっており、巡礼のたびにこの交差点に立ち寄ってコンビニを訪れては、キマリの好きなプリンシェイクをいただく*2、というのが定番になってたりするようなところです。

f:id:kochizufan:20190511124851p:plainf:id:kochizufan:20190511124915p:plain
店名などは改名されているが、主人公達が歩いた作中そのままの街並みがある

f:id:kochizufan:20190511123425p:plainf:id:kochizufan:20190511123509p:plain
キマリ達のバイト先コンビニのある交差点の地図

実はこの交差点、館林の歴史上も重要な交差点になっています。
この交差点は竪町の大通り、谷越町の大通り(日光脇街道)という2つの大通りが交わるところで、古来「大辻」あるいは「札の辻」と呼ばれた、いわば館林城下町の一丁目一番地にあたる場所なのです。
林城大手門から出た参勤交代の行列も、ここで南へ曲がり江戸に向かうという交通の要地であった他、幕府や藩から一般民衆への御触書がある際はそれが掲げられる、高札場という設備も設置され、情報の流通もここを起点に始まるという、城下町館林の本当の中心地がここでした。
江戸時代が終わり近代に入ってもその重要性は変わらず、この場所には館林周辺の道路整備の起点となる、道路元標というものが設置されました。

f:id:kochizufan:20190511135927p:plain
館林町道路元標

まさに、館林という街を起点とした旅がここから始まる、「ここから、ここから」の場所がこの交差点だったのです。

ちなみに、この交差点から参勤交代の行列の行く筋に沿って、谷越町の大通り(日光脇街道)を南に下がっていくと、オープニングで出てくる特徴的な雑居ビル(谷越ビル)や、日向がジュースを買ったポコポンガールズ(実際にはmenkoi girls)の自販機があったりします。

f:id:kochizufan:20190511162531p:plainf:id:kochizufan:20190511162559p:plain
谷越ビルとmenkoi girlsの自販機

キマリの成長を見守ってきた神社 - 金山神社

主人公キマリの家の前に描かれている小さな神社も、主人公の家というよく舞台になるところだけに、作中で多く描かれました。
家のすぐ前の神社だけに、キマリがまだ子供だった時代からその成長を見守ってきた神様だと思うのですが、このモデルになった神社が、本町二丁目の金山神社です。

f:id:kochizufan:20190511140535p:plain
主人公の家そばにある神社のモデル、金山神社

この神社は小さな神社ながら歴史は古く、江戸時代初期の古地図にはもうその名前がこの場所に出てきます(下の古地図キャプチャは江戸時代後期)。

f:id:kochizufan:20190511140401p:plainf:id:kochizufan:20190511140438p:plain
江戸期の古地図にも、金山神社は描かれています

この神社の祭神は金山毘古神といい、火やそれを用いた金属加工などを司る神様です。
この地域一帯は昔は鍛冶町、あるいは近代以降は字金山と言われた地域で、その名の通り鍛冶屋が多く住んでいた地域でした。
そのため、鍛治を生業とする人々が、自分たちの職業安全のためこの神様を祀ったのだと思われます。
キマリの裏表のないまっすぐな性格は、この神様が子供の頃から鍛えた賜物なのかもしれません。

そのすぐ近くですが、5話でキマリがめぐっちゃんに「絶交無効」した後、南極の旅へと振り向かず走り去る路地があります。 小さな路地ですが、この路地も歴史は古く、江戸時代には与力や同心が集まり住んだ「御家中屋敷」と記されている地域になっていますが、その区画の中に一本、通用路として切られた路地(当時は行き止まりでした)が、このキマリの走った路地のようです。

f:id:kochizufan:20190511142410p:plainf:id:kochizufan:20190511142443p:plain
キマリが旅に出る前走り去った路地は、御家中屋敷の通用路だった

キマリ宅近くの街の風景 - 片町

5話ではキマリとめぐっちゃんにフォーカスが当てられて語られますが、その中でキマリ宅周辺の風景が描かれます。
水商売の店が多数雑居する特徴的なゴリラビル、エンディングアニメでも描かれる角のタバコ屋さん、etc...

f:id:kochizufan:20190511143832p:plainf:id:kochizufan:20190511143801p:plain
キマリ宅周辺 - 片町の風景

この辺りの街は、歴史的には片町と呼ばれます。
町名の由来は簡単、ここらあたりは館林城の城内と城下町の境目であり、昔はこの通りの東側は城内を守る堀と城壁の威容があるばかりで、人家や店の類は通りの片側、西側にしかなかったため、片町と呼ばれるようになったのでした。

f:id:kochizufan:20190511143625p:plainf:id:kochizufan:20190511143703p:plain
城壁に面していたため、通りの片側にしか街がなかった片町

さすがに堀が埋められ城壁が撤去された今は、片側にしか建物がないということはありませんが、それでも建物密度は西側の方が詰まってるような気がしないでもありません。

同様に5話の中でキマリとめぐっちゃんの帰り道シーンで描かれた場所として、片町の通りの少し東側の水路があります。

f:id:kochizufan:20190511144924p:plain
片町東すぐの水路、作中ではこの水路から道路を見上げるような視点だった

この水路はまさに、片町が境だった館林城の城内と城下町を隔てていた堀の遺構です。

f:id:kochizufan:20190511145202p:plainf:id:kochizufan:20190511145239p:plain
キマリとめぐっちゃん帰り道の水路は館林城の堀の遺構

花屋さん前の「止まれ」 - 谷越町天王の裏通り

オープニングと、同じく5話で少し描かれる特徴的な場所として、花屋さんの前に「止まれ」と描かれた細い路地の風景があります。

f:id:kochizufan:20190511150434p:plain
花屋さん前に「止まれ」と描かれた路地

この路地も決して大きな道ではありませんが、昔からある古い路地です。
今も残る歴史ある施設として、この路地の東には青梅天満宮、西には大道寺があり、その双方にこの路地から裏口アクセスできますが、その昔にはもう一つ、路地の東側、青梅天満宮の北側に、円蔵院というお寺がありました。

f:id:kochizufan:20190511145551p:plainf:id:kochizufan:20190511145643p:plain
路地の東に円蔵院が見え、その中に「天王」と描かれている

この円蔵院には牛頭天王が祀られ、谷越町の天王として知られていましたが、その他に館林には足利町の天王(別当同町密蔵院)、竪町の天王(別当材木町法性院)があり、この三天王が旧暦六月七日に催す夏祭りは、三つの神輿が市内渡御の後登城して城主拝礼まで行われるという、盛大なものだったようです。
今は三天王も他の神社に合祀され、天王夏祭りもなくなって静かな路地になっていますが、その昔は夏祭りの際は賑わった通りだったのかもしれません。

館林の街の玄関 - 昭和まであった街のランドマーク、善導寺

これまでに挙げた例のようにピンポイントではないのですが、館林という街の玄関口である館林駅周辺も、作中では多く描かれました。
キマリが旅立つ際に利用した駅前トイレや駅改札口、駅前のタヌキ像、めぐっちゃん行きつけの喫茶店カフェドスタール、少し離れていますが結月が泊まった?ニューミヤコホテル*3など。
これらの地域は、その昔どのようなところだったかというと...全域が善導寺という大きなお寺の境内でした。

f:id:kochizufan:20190511153319p:plainf:id:kochizufan:20190511153349p:plain
今の館林駅前一帯は、全て昔は善導寺境内

善導寺は江戸時代より前は館林城の北側、加法師と呼ばれる地名の地域に、伝説では行基が開基したとされて存在していましたが、安土桃山の頃榊原康政が館林に入城した際に、善導寺の上人に深く帰依し、この現館林駅前付近に土地を与えて移転させたそうです。
それ以来江戸期を通じてこの場所にあり、近代に入ってからも寺域こそ大幅に小さくなりましたが、ずっと館林駅前にランドマークとして鎮座していた名刹でした。
が、昭和末期、館林駅前の再開発計画に伴い、城沼の北側に移転してしまいました。
その後館林駅前は再開発されたと言っても、誘致したスーパーも撤退しだだっ広い駐車場しか残っていないのを見ると、再開発とはなんだったのか、善導寺の山門の威容を館林駅前のランドマーク、街のシンボルとして駅前に残しておくべきだったんじゃないかと、余所者ながら思ってしまいます。
もし善導寺館林駅前に残っている世界線で「よりもい」が作られていたら、館林駅前の描写ももっと違ったものだったのかもしれません。

f:id:kochizufan:20190511160528p:plainf:id:kochizufan:20190511160611p:plain
左は城沼北側の現善導寺にある榊原康政の墓、右は館林駅前にある墓が元あった場所の記念碑

番外編: 東屋の江戸時代

このように、アニメの聖地として訪れた街並みであっても、それを歴史などの別の視点を重ね合わせてみてやると、また全く違う景色が見えてきます。
とっかかりはアニメであったとしても、そこから街を他の視点で見たりして楽しむ楽しみ方がもっと普及すればいいなと思います。

最後に、番外編として、「よりもい」の館林聖地として筆頭に挙げられるであろう、つつじが岡公園の東屋が昔はどうだったか。

f:id:kochizufan:20190511195225p:plain
作中を代表する聖地である、つつじが岡公園の東屋

f:id:kochizufan:20190511161537p:plainf:id:kochizufan:20190511161606p:plain
つつじが岡公園は城沼の底

古地図の範囲外...というか城沼の底でした。
昔の城沼は今よりもずっと広く、館林城の難攻不落の南の守りとして広がっていたのです。

*1:本編を見ればわかりますが、世代は一緒だけど女子高生じゃない娘も含まれますので、「女子高生」ではなく「女子高生世代」と表現しました。

*2:最近置いてないんだよな...

*3:結月が泊まったホテルは、周辺風景と玄関はニューミヤコホテルがモデルなのですが、外観内装は館林グランドホテルがモデルのため、?と書いています

Maplat採用のambula mapアプリが京大散策地図に対応&アニメ「PEACE MAKER 鐵」とスタンプラリーコラボ

私開発の古地図アプリオープンソースライブラリMaplatを実際に採用してくれている、株式会社コギトさんのambula mapが、新しい地図に対応いたしました。

一つ目は、京大の散策地図への対応のプレスリリースです。

k-tai.watch.impress.co.jp

二つ目は、アニメ「PEACE MAKER 鐵」とスタンプラリーコラボを行う案内です。

travel.watch.impress.co.jp

Maplat同様、ambula mapへの応援もよろしくお願い致します。

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