Code for History

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

Strolyの数千件の地図収集アドバンテージをそこまで脅威に思わない理由

Maplat Stroly 古地図 歴史国土 GIS

古絵地図プラットフォーム技術の普及で重要になるのは大きく2つの視点があげられます。

  1. 技術の優劣
  2. 収集した古絵地図コンテンツの量

このうち、1. に関しては、先の記事等で広範なStrolyとMaplatの比較をしつつ、個々の優劣はありつつも全般的にはMaplatの方が優れていることを記してきました。残る2. の視点では、私がMaplatで現時点で集めているコンテンツは100点未満であり、日次の増加数などから外形的に観察する限りおそらく3000〜5000点のコンテンツを集めていると思われるStrolyに劣ります。 が、この差について私はさほど脅威とは感じておらず、その理由について本記事で説明してみたいと思います。

そもそも数千件は大きな数ではない

世の中にいくつの古絵地図があるかの統計はありませんが、おそらく十万百万のオーダーだと思われます。 その中で数千件のリードはさして大きな数ではありません。 Googleがクロールで世界中のほぼ全てのWebページを何億と蓄積しているように、既に大半の世に存在するコンテンツをおさえられてしまっているならば後発が覆すのは容易ではありませんが、数千件レベルであれば、たとえばMaplatが（仮に）投資を受けて事業を開始したり、あるいはオープンソースとして多くの人に使ってもらえるようになったならば、十分に覆すことが可能です。 実際、Stroly社のコンテンツ蓄積サイトhttps://stroly.com/を見てみても、そちらの検索フォームで地名から地図を探せますが、「東京」や「大阪」といった大都市でこそ複数の地図がみつかるものの、地方都市の名前を入れるとほぼひとつも地図が見つかりません。 「数千件」というのはその程度の数という事であり、現時点での彼らの優位はその程度でしかありません。

Strolyの古地図の大半は著作権の切れた「オープンデータ」であり、誰でも使える

Stroly社が揃えている古地図データの大半は、著作権の切れた「オープンデータ」であり、彼らが独占的に使えるデータではありません。 私のMaplat技術での利用含め、誰でも再利用可能なデータです。 ですので囲い込み効果がありません。

絵地図は著作権があるものが多いですが、基本的に個別Strolyユーザが著作権者と一致しているケースが大半であり、個別ユーザが利用技術を乗り換えればそのまま利用権も移るようなものが大半なので、これも囲い込み効果は薄いです。

古絵地図と位置の対応付データの著作者／ライセンス規約があいまい

しかし、地図画像データだけでは古絵地図アプリは動きません。 Stroly / Maplatとも、動作させるためには古絵地図と位置の対応付データを作成する必要があります。 そのようなデータの利用権は囲い込み効果があるものといえますが、Stroly社が独自に作成したデータは間違いなくStroly社の著作物ですが、StrolyのユーザがStroly社のツールを使って作成したデータは、誰の著作物かという明確な規約を現在Stroly社は整備していません。 ですので、ツールはStroly社が提供していても、ユーザが作成したデータはユーザのもの、と判断されれば、ユーザが使用するツールをStrolyからMaplatに乗り換えた場合に、作成したデータをそのまま移動させることができる可能性があります。

もちろん、今後Stroly社が、Strolyのツールで作ったデータはStroly社が著作権を要する、あるいはStrolyでのみ利用できるものとする、といった規約を整備してくる可能性はありますが、元々オープンデータ界隈で支持を得てきた会社/ソリューションだけに、そのような規約変更にユーザが納得するかは疑問が残るところです。

不正確なStrolyのデータは正確なMaplatでは使えない事が多い

一番大きな脅威でない理由で、Maplatの技術的優位性とも繋がってくる問題です。 Strolyと比較してMaplatの方が双方向全単射変換を保証するなど、正確に位置情報を扱えるのですが、それを保証するためデータ作成時においても、正確さを担保するためにトポロジーエラーチェックなど多くの検証処理をMaplatツールでは実施しています。 その検証処理を経ていないStrolyツールで作成されたデータは、そもそも不正確すぎてMaplatでは使えない事が多いです。 正確に言うと、「使えない」のではなく「正確に扱おうとするとエラーが出てしまう＝Strolyと同程度の変換精度しか出せない」なので、動かないわけではないのですが…。 つまり、Strolyがデータを何千件、何万件先行して蓄積したとしても、その多くはMaplat的精度では要求に満たない、不正確な不良データが大半（悪く言えばゴミの山）になります。

以上のような理由により、何千件程度のStrolyのコンテンツ量優位は、さほどの脅威ではなく、もし後発で事業化したとしても、簡単に覆せるものであると言えます。

StrolyとMaplatの長短比較

Stroly Maplat 古地図

StrolyとMaplatの長所短所比較を聞かれることが何度かあったので、その際に都度答えた内容をいくつか組み合わせて、記事として起こしてみました。

全体として、技術的な面と運用的な面での長短に分けて記載します。

技術的な面での比較

双方の長短がわかりそうな代表的な地図をセレクトしてみました。

Stroly:
https://m.stroly.com/a/i#1522409396

Maplat:
https://s.maplat.jp/r/naramap/

Stroly - 1つの画像に複数の地図が共存可能

まず、Strolyにアクセスしてみると、日本地図が見えますが、周辺に北海道や台湾、東京や大阪の拡大図などがメインの画面と区切られた地域に存在します。
そういった、メインの地図と区切られた地域に地図の中心を持っていって、地図を現代地図に切り替えると、ちゃんと台湾や大阪が表示されます。
別の言い方をすると、Strolyは一枚の画像の中に複数の地図が存在する場合、それぞれに対応できます。
残念ながら、Maplatは現状、まだこれには対応しておらず、 一枚の画像の中の単一の地図にしか対応できません*1。

Maplat - 古地図絵地図と現代地図をぴったり重ね合わせ、半透過重ね合わせも可能

これが技術的にStrolyのMaplatに勝っている部分ですが、逆にStrolyの欠点は、Stroly側で地図を切り替えてもらえばわかりますが、地図がぴったりとサイズ一致しないと思います。
絵地図と、現代地図と、双方が微妙に違うサイズに表示され、ぴったり重ならないはずです。
また地図の表示ズームだけでなく、朝鮮半島のあたりで切り替えてもらえばわかりますが、絵地図側の方角が少しズレているのも、切り替えても双方の傾きがズレたままで、ぴったり合わないと思います。
これは、StrolyのWeb版は今表示している範囲の中心点で位置が合うだけで、地図全体でズームをぴったり合わせたり、方角をぴったり合わせたりする機能がない事が原因です。
それに対し、Maplatの方は、地図を切り替えてもらえばわかりますが、中心点だけでなく、地図のスケールや方角も比較的ぴったり合わせて地図を切り替える事ができます。
都度ぴったり合わせるよう計算しているので、リアルタイムに背景画像として現代地図を表示することもできますし、古地図側を透過表示して重なり具合を確かめる事も出来ます。
これによって、実際に古地図や絵地図と切り替えた現代地図が、本当に同じ場所を表している地図である、ということが視覚的直感的にわかりやすいというのがMaplatの長所です。

Maplat - 地図間の座標変換で1対1変換、必ず元の場所に戻ってくる

また、ちょっとわかりにくいMaplatの利点なのですが、Maplatは絵地図と現代地図（或いは絵地図と絵地図間でも可能）で座標を変換する際、ある地点を変換して、もう一度逆変換した際、絶対に元の場所に戻ってくるよう設計されています*2。

jsfiddle.net

こちらのサイトを見てみてください。
右下に地図とその上にメッシュが出てくると思いますが、StrolyとMaplatで同じデータを使って、絵地図の上の格子状の点を経緯度に変換し、その経緯度をさらに絵地図上の座標に逆変換した結果を描画しています。
深紅がMaplatの結果で、黄色がStrolyの結果です。
双方向きちんと元の場所に戻ってくるように変換されていれば、ちゃんと格子になるはずなのですが、Strolyの方は特に右下付近などでぐちゃぐちゃに変換されているのに対し、Maplat側は綺麗に格子に戻っています。

技術的な優劣はこんな感じですが、この辺の内容はだいたいこちらのプレゼンにまとめてあります（ただしMaplatの方が優れている部分の視点のみ）。

www.slideshare.net

運用的な面での比較

Stroly - 手軽に始めて手軽に配信、オールインワンのウェブエディタ

運用的な面でのStrolyの優位性は、何と言っても手軽さにあるでしょう。 企業が十分に労力をかけて整備しているサービスですから、Twitterアカウントなどでログインすればすぐに使い始められて、チュートリアル等も豊富、編集が終わればデータはすぐ地図をサービス提供できる手軽さは、一人の開発でドキュメントの整備なども手が回らないMaplatでは全く太刀打ちできません。
Maplatで地図を提供しようと思うと、ドキュメントも不十分なエディタを使ってデータを作成し、一部エディタがまだ対応しきれていない部分は手作業でデータを作り、それをサーバ等に適切に配置して、初めて提供できるようになります。
手軽さの度合いは比べるべくもありません。

Maplat - オープンソースライブラリ故の自由度、カスタマイズもオフライン環境でも自由自在

が、Strolyはサービスです。
サービスであること、またその手軽さとの引き換えとして、使い方の自由度がありません。
決まった地図UIでしか地図を提供できませんし、もちろんカスタマイズは可能ですが、そのためにはStroly社と契約して、カスタマイズ費用を払い、特別に専用UIを開発してもらうしかありません。

それと比べて、Maplatはライブラリです。
自由度はStrolyと比べ物になりません。
普通にデフォルトの設定で使って標準のUIを出すこともできますが、UI表示をオフにして、メソッドとイベント経由で動作を制御して、完全にオリジナルなUIで動作するようにすることもできます。
地図だけのページではなく、普通のHTMLページの中の一部分にだけ表示するようにもできます。
表示の自由度だけでなく、配信の方法も、Stroly社のサーバからサービスとしてオンラインでしか配信できないStrolyと違い、Maplatはライブラリなので配信に必要な材料さえ揃っていればどこの会社のサーバからでも、完全オフラインな環境（例えばネットワークの繋がっていない街頭のデジタルサイネージなど）からですら地図コンテンツを配信できます。
ドキュメントなどが揃ってない分ハードルは高いですが、理解して使っていただければ自由度はStrolyとは比べ物になりません。
しかも、オープンソースなので、どんなにカスタマイズしても利用は無料です*3。

Maplat - オリジナルモバイルアプリの開発の中にもライブラリとして組み込み可能

またモバイル対応も、StrolyはiOSとAndroidに対応していますが、Stroly社独自のアプリとしての実装しかありません。
カスタマイズで機能をつけようと思うとStroly社に開発を依頼する必要があり、地図表示機能だけを提供して、あとは別の会社が自由に機能を開発できるようなモバイルライブラリの提供はありません。
が、Maplatは、モバイルで自由なアプリを開発していただけるライブラリの形で提供しています*4。
なので、Maplatの機能を一部として埋め込んだ、独自のアプリを自由に作っていただけます。

以上が、運用面でのStrolyとMaplatの比較です。

結論：長短を把握して、用途によって使い分け

以上がStrolyとMaplatを比較した、長短の提示になります。
私はMaplatの開発者ですので、当然Maplatの利用が伸びればいいと思っていますが、やはり現状一長一短があり用途によって向いている向いていないがありますので、この記事を参考に向いているソリューションを選んでいただければと思います。
Maplatを利用されるにあたり不明な点などあれば、ぜひrekishikokudo@tilemap.jpにご連絡いただくか、Maplatレポジトリのissueページなどで質問してみてください。

*1:技術的には対応可能です。もともとStrolyの複数地図対応仕様を考えたのは私ですので。ただ、開発が追いついておらず、また結構な量の開発工数がかかるので、すぐに対応するのはほぼ不可能です。

*2:Maplatはこの実現手法で特許出願中です。特願2017-218223

*3:もちろん、私にヘルプを要求される場合は実働に応じて人件費は請求いたしますが...ライセンス費用的なものは不要です

*4:正確には、Androidはモバイルライブラリ化が完成していますが、iOSは7月末完成予定です

1月22日の大雪パニックは「日本的危機管理のなさ」のせいじゃなくて「合成の誤謬」のせいだと思う

社会 Facebook流用 危機管理

昨日、薬が切れたためどうしても医者に行く必要があり、新横浜=>目黒=>町田と帰ったせいで、東急線とJR横浜線だけだが15時ごろの電車運行状況と18時ごろの状況、20時ごろの状況を全部見た立場から語ると、
昨日の大混乱って多くの人が八甲田山なんかを例に挙げて日本的危機管理のなってなさの表れのように語るけど、皆が共通の指揮系統で動いてるわけでもない群衆の危機管理をそんな見方したって何も役に立たないわけで、私はそうじゃなくて合成の誤謬の結果だと思う。

だって、19時半～20時頃に乗ったら、運行こそ普通しか走ってないけれど、ちょっと混雑してる程度でしかなかったわけですよ。
危機管理できてなくて長時間働かせてたから大パニックが起こったんじゃなくて、みんなが「おい、早く帰れ」となったから合成の誤謬で大パニックが起こったわけで、普通にみんながそこそこ残業して帰る時間がバラけてたらスムーズに流れてたわけです（残業がいいことという意味じゃないよ）。
いや、定時で帰らせるからパニックになったんだ、もっと早く早退させてたらパニックにならなかったはずだ、という人もいるだろうけど、私15時台にも乗ってるから知ってるけど、その頃ですらもう相当混んでたわけで、これは早く帰してる会社が相当数あったからなわけだから、
もし全ての会社が昼過ぎとかに帰してたら、パニックが起こる時間が早まってるだけで別にパニックが起こらなかったわけじゃないはず。

私は15時台ですら相当混んでたの知ってた上で、医者に行った後18時台に帰ろうとしたら、どうにもこうにもホームで身じろぎもできないくらい人があふれてて、列に並んでても5台くらい電車を見逃さないと乗れない状況なの見て、
『別に普段の日に比べて出勤してる人の総数が増えてるわけないし、15時台にもあれだけの大人数が吐けてたのに今大混雑するという事は、普段ならバラける帰宅時間がこの時間に集中してるだけだから、30分～1時間も時間つぶしてこの混雑が吐けるの待ってれば空くはず』と思って、腹もすいてきたし飯食って時間つぶしてたら、案の定ホームに戻ると空き空きで、その後入構してきた最初の電車に余裕で乗れた。
だから、雪降ってきた早く帰れ、じゃなくて普段通りもっと自然に散ってたら、パニックにはならなかっただろうし、とはいえこんな非常時に共通の指揮系統にないバラバラの群衆がそんなうまく動くわけがないので、それで生じたパニック見て「日本的危機管理がどうだこうだ」言ってもしゃあないと思う。

Maplatディストリビュータ企業募集

Maplat ビジネス

会津若松版や奈良版など展開しています古地図アプリMaplatですが、オープンソースなので誰でも自分でデータ作って自分のサーバ上で公開できるものの、技術ある人やある程度勘のある人しか設定できないので、市井の方が公開したいと思ってもまだハードル高い状態です。
ですので、Maplat普及のためにも、導入したい方の相談に乗って代わりに設定導入作業する（もちろん商売として）、Maplatディストリビュータとでもいうべき立場になっていただける企業を募集しています。
ご興味あれば、rekishikokudo@tilemap.jpまでご連絡ください。

私が語らないと歴史に残らない「位置ゲー事件簿」その2:Willcomと京ぽん - ユーザからの熱愛を受けたキャリアと名機

位置ゲー 歴史 位置ゲー事件簿

その1より1年以上を経てしまったが、その2を書いてみたいと思う。

位置ゲー黎明期は同時にケータイWebサイト黎明期（は少し過ぎてたかも）でもあったが、開発者とユーザの間がとにかく近かった。
黎明期の位置ゲーはほぼほぼ企業ではなく個人が作っていた、というのも一つの理由ではあろう。
それゆえに、開発者が動作検証できる各キャリアの端末を全部揃えていないこともあったし、また揃えていても機種依存等で動作が同じキャリアで異なることもあった*1。
そうなると、勢い問題の発生している機種を持っているユーザの助けを借りないと、デバグすらできない事もあった。
プログラムを少し変えて、変えた事を当該機種を持つユーザにメールや電話で連絡して、動作の変化を教えてもらって、変化と仕様書を付き合わせながら起きている現象を想像して、また少し変えて...というようなボトルシップの組み立てのようなデバグを繰り返したりもした。
ゲームが少しおかしな動作をすればクレームの嵐というような今現在から振り返ると想像もつかないような、おおらかな時代だった...ひとつには、開発側だけでなく遊ぶ側も、自分たちがコンテンツを作っているという意識があったのだと思う。

また単にゲームのデバグだけでなく、ゲームの前提となる機能の利用方法のハックなども、開発側とユーザ側が一緒になって行ったりもした。
たとえば、auケータイでの位置情報は、アンテナ基地局の位置情報を取得する方法は公開されていたが、GPSで位置情報を取得する方法は長らくezwebでのコンテンツキャリア以外には公開されなかった。
それをハックして、htmlタグの記述方法と、種々のパラメータの意味を明らかにしたのは、我々黎明期の位置ゲー開発者とユーザとの連携の功績だ。
そんな仕様ハックを楽しんでいたユーザの中でも、特に熱かったのが、PHSである「Willcom(当時DDIポケット)」のユーザ達と、その愛した名機「京ぽん」である。

その1で書いた通り、日本の位置ゲーの走りのひとつである「アンテナ奪取」は、端末が返すアンテナの基地局位置情報を元に、それを奪い合うゲームだった。
ということは、当然のことながら位置情報が取れない機種/キャリアでは遊べないだけではなく、位置情報が取れてもそれがGPS位置情報などの正確な位置情報だと遊べない、「アンテナ位置情報でないと」ゲームが定義できないゲーム性だった。
当時そのようなアンテナ位置情報を取れたのは、へなさんが「アンテナ奪うのれす」を作った「J-Phone（現Softbank）」と、「au」しかなかった。
Willcomの位置情報は、端末がその時受信できている複数のアンテナとそのアンテナからの電波強度を元に、三角測量的な手法で推定した位置情報を返していた。
当然、Willcomは少しでも正確な位置を返すためによかれと思ってそうしていたのだが、その三角測量をしているがゆえに、Willcomでは「アンテナ奪取」は原理的に遊べないはずだったのである。
熱いWillcomユーザが、名機「京ぽん」をハックし倒すまでは。

Willcomユーザというのは、まあぶっちゃけ変わり者が多かった。
普通にほぼ同じ技術を使っている（CDMA oneとかPDCとかは置いておいて）ケータイの間で利用料金などで3社を乗り換えている一般ユーザと違い、明確に毛色の違う「PHS」を選んでいる彼らは、どこか普通と違っており、またこの技術のここが好きだからこれを選んだ、と明確な意志を持ちかつ技術に詳しい人が多かった。
実際、アンテナから得られる電波の強度を測定してロギングしたデータをデータベース化したり、そういった活動を楽しんでいるユーザが多かった。
そのWillcomユーザから熱狂的に愛されたのが、京セラから発売された「京ぽん」だった*2。

その京ぽんを使って、位置情報測位時の電波強度パラメータの測定等を遊んでいたWillcomユーザが、ある日気づいた。
普通に位置取得すれば、必ず複数箇所のアンテナの電波強度が返ってくるのに対し、ある手順で位置取得すれば、再現性を持って必ず1ヶ所の電波強度しか返ってこない（つまりは三角測量してないのでそのアンテナの位置が得られている）というファームウェアバグに。
その手順自体は、昔のことすぎて私もよく覚えていないが、確か1度httpリクエストを投げて、そのレスポンスが完了する前に、リクエストをキャンセルしてすぐに位置情報取得リクエストを投げるとか、そんな手順だったと思う。
そのやり方は変わったもの好きなWillcomユーザの間ですぐに広まって、すぐにWillcomユーザではなかったものの位置情報サイトや位置ゲーをやっていた私の耳にも届いた（というかそもそも私のサイトのユーザさんが見つけたのだったかもしれない。そこまでの細部は忘れた）。
その手順がシステム的に再現できれば、Willcomでもアンテナ奪取ができる！と思った私は、いろいろ実装してみて、もちろん私はWillcomユーザじゃないので京ぽんを持っているユーザさんにテストしてもらって、最終的にシステム的にも再現できる事を導くのに成功した（たしか、味ぽんは当時では珍しくクライアントサイドのでJavaScriptも使えたので、空のページを読み込んで、その上でJavaScriptで位置取得URLにリダイレクトする、といった手順だったように思う）。
その技術の確立で、晴れてWillcomでも、京ぽん限定だがアンテナ奪取を遊べるようになったのだった。

一度Willcom版アンテナ奪取が実現すると、弱小キャリアで元々ユーザが少ない上に、機種限定というハンデがあったにも関わらず、Willcom版はJ-phone版やau版に引けを取らない盛り上がりを見せた。
元々変わったものが好き、というユーザ特性があったし、自分たちで作り上げるコンテンツが好き、というところもうまくはまったのだと思う。
驚くのは、公開後しばらくして京ぽんのファームウェアアップデートがあり、そのファームウェアアップデートを施すと単独アンテナ位置を返すというバグが直ってしまい、アンテナ奪取が遊べなくなる、という情報が出回った時だ。
それを聞いた京ぽんアンテナ奪取ユーザ達は、ファームウェアアップデートをすれば様々な動作が改善されるにも関わらず、ファームウェアアップデートを施さず、その後何年も古いファームのままアンテナ奪取を遊び続けた。
すごい位置ゲー愛だと思う。

アンテナ奪取の元管理者という立場から、私がWillcomと京ぽんについて語れるのはここまでだが、Willcomと京ぽんコミュニティーからは、他にも多くの黎明期位置ゲーコンテンツが生まれている。
いまや日本を代表する企業に育っているコロプラも、その元になっているコロニーな生活はWillcomから生まれたコンテンツだし、同じく黎明期の位置ゲーである電波の杜のゲーム群も、Willcom起源。
位置ゲーではないけどKamoTOWNやGPSMANなどいろいろジオメディア界隈に影響を与えたコンテンツを作成した、ふぇちゅいんさんもWillcom起源。
今や残っていない企業ですが、あの頃のWillcomという会社とその名機京ぽん、そしてその熱いユーザ達は、日本の位置ゲーの歴史に大きな爪痕を残したと思える。

*1:私もできる限り4キャリア揃えていたが、やはり限界はあった。ちなみにその頃の後遺症か、いまだにiOSとAndroid両方持ってないと不安だし、もう触ることはないだろうとはいえWindowsフォンもあったりする。

*2:京ぽんの名称は、当時のWillcomのネット利用可能電話ブランドが「Air-H"（エアーエッジ）」であったため、Willcomの電話全体が「味ぽん」の略称で呼ばれていたことによる。「京セラ」が発売した「味ぽん」なので「京ぽん」。

Maplat奈良版公開！

Maplat 古地図 奈良 GIS

私の開発しているMaplatという古地図を扱うアプリですが、奈良の古地図2件と、歌うパステル画家5Seasonsさんの京終界隈マップ、うとうとさんのならまちおもしろ地図3部作を加えて、Maplat奈良版として公開しました！

GPSで現在地を表示しながら、古地図や楽しい絵地図で奈良の町歩きが楽しめるはずです。 ぜひ試してみてください。

他の地域もあります！

今後も新しい地図をどんどん増やしていきます！ これに追加したい地図などお持ちの方はぜひご提供、ご紹介ください！ 自分の地域に作ってみたい方も、ぜひご相談ください。

古地図アプリが紙の地図に勝つために：その1、みんなでワイワイ視点共有

Facebook流用 Maplat Stroly サーバレス技術 仕様

以前、Facebookにも書いた話題の改題です。

私は以前Stroly(当時はちずぶらり)という古地図や絵地図の観光マップアプリの仕事してましたが、家族と鳥羽に行った時に自分の観光アプリ起動した隣で、大学生たちが大きな観光マップ広げて「どこいくー？」「私ここ行きたいー」とかワイワイしてるの見て、あ、負けた、と思いました。
1人で手元で古地図/絵地図みながら何かを探す用途としては、古地図/絵地図アプリはハンディで便利ですが、バッと拡げてみんなでワイワイ視点共有しながら、あーでもないこーでもないと楽しく検討するためのプラットフォームとしては、現状の古地図アプリは全く向いているとはいえません。

単に視点を共有できるようにすればみんなでワイワイできるようになるとは限りませんが、少なくとも現状できないものをできるようにすることには意味があると思い、すぐ視点を友人とのアプリ間で共有する機能を考えてStrolyに実装したいと思っていました。 しかしながらその直後、Strolyを解雇されて実現できませんでしたが、今でもあの時「紙に負けた！」と感じたインパクトが強いので、自分のアプリ（Maplat）で実現したいと思ってます。
そういった視線を多人数で共有できるの含め、アプリ地図はまだまだ紙の地図に勝てないところは残っていて、その意味でまだ紙地図はアプリ地図のライバルだし、そういう負けてる点にいかに気付いていかに取り込んでいくかが、アプリ地図技術者の使命だと思ってます。

といったところまでがFacebookや、その以前にはTwitterにも書いたはずの内容なのですが、媒体を変えたとはいえ何度も同じ内容だけを書くのもアレですし、今回は実際にシステムを組むとどうなるかを設計してみました。
今私の中で空前の大ブームの、Azureサーバレス構成で作ると、 f:id:kochizufan:20170916011546p:plain こんな感じになります。

この仕組みを使って、Maplatでも友達間の視点や現在地、お気に入りPOI等を共有でき、チャットなども交えてワイワイできるような機能を加えたいと思っています。

=== 追記 === 最初この視点に気づいた2012年GW頃と10月ごろのTweetがサルベージできたので貼っつけておきます。

なるほど、当初はBlueTooth等での視点共有を考えていたようです。

© Code for History