ただいま開催中の国際地図学会2019東京(ICC 2019 Tokyo)で、昨日(7月17日)Maplatの発表をしました。
Open Sourceカテゴリーの枠で発表したのですが、今日18日に古地図関係の枠がたくさんありました。
こちらで発表すればよかった...。
しかも今日は早々に名刺を切らしてしまい...胃が痛い。
論文、発表で使用した資料を公開いたします。
連日Strolyを貶める投稿（もちろん嘘や誹謗中傷ではなく、事実を示して、ですが）をブログで続けている私ですが、それは私が開発しているMaplatで、技術の分野で、Strolyを上回る技術を開発しているという実績を既に残しているからです。
Stroly社の技術マネジメント能力は最低最悪ですし、その結果として5億円近くも投資を受け何人もの技術者に専業させているにも関わらず、個人が本業の余暇にお小遣いで作っているオープンソースに技術力で劣っているという、その結果があるので行っていることです。
（もちろん、優っている部分があるからといって相手を貶めていいのかという話もありますが、それは、感情的には私がStroly社から過去被った信義則に反する行いに対し怒っていることと、冷静な理由としても、後述するとおりStroly社が得意な分野に対抗するため別の私の得意な分野で対抗する必要があるから、ということがあります。）
では、Strolyの技術以外の分野はどうなのでしょうか？
別に全く超一流ではないものの、Strolyのそれぞれの分野でそれを上回る成果を出してない奴が、安易に舐めてかかっていい状態ではないのがわかります。
たとえばデザイン。
StrolyのCEOはデザイン馬鹿で、自分の評価指標がデザインしかないために、技術やその他の要素をマネジメントすべき時でもひたすらデザインデザインしか言わず、元同社CTOの中川氏（id:monomoti）も言ってましたが、技術の開発にコストを使わずにひたすらデザインを作っては壊し、作っては壊ししかやっていない人です。
ですが、ちゃんとプロのデザイナー投入した上でそれだけ作っては壊ししてますから、トータルな生産性の面ではともかくとして、結果的に仕上がってるデザインとしては、それで何か状況が好転するほど優れたものではないにしても、ちゃんとまあ見た目的にはよくできてるよね、的なものに仕上がっています。
翻ってMaplatを見てみると、現在のところMaplatにはデザイナーの協力者がいませんから、デザインに力が入れられていません。
私もそれなりにシステムに携わってきた経験があるのでその範囲で、UXが壊滅しているようなUIは作ってないつもりですが、アイコンなどもフリーフォントの流用ですし、ボタンなども地図ライブラリの標準ボタンのカスタマイズです。
別にデザインの面でMaplatがStrolyに勝っているとは全く思っていないし、技術に金かけるべき時にデザインばかりいじってるStroly CEOのデザイン馬鹿を揶揄したことや、Strolyがバグを直せなくてこれまでできていた事ができなくなった際に、それをごまかすUI遷移に変えた事を揶揄したことはあれ、Strolyのデザインを馬鹿にしたことは一度もありません。
（ただし、MaplatはAPIで外部制御できる作りになっているため、UIは気に入らなければ自分で作り直せるので、Strolyのデザインを完全コピーしたバージョンのMaplatを作るのも2日仕事とかそういうレベルです。なのでデザインで負けていることは大きなファクターとは全く思っていません。）
別の視点では、たとえば金集め。
Strolyの経営陣は、本業をちゃんと回して黒字にできる体制を作るという点ではほぼ無能ですが、しかしながら前身のATR-Promotionsの時代から、お金を集めてくるという意味では、どういう魔法を使ってるのか知らないですがすごい才能を発揮していました。
ATR-P時代の行政からの補助金から、今のStroly時代のVCからの投資まで、本業が赤でもそれを埋める資金をどこからか調達してきて、結果的に売り上げと集めた金を合わせると年間トータル10万円かそこらだけギリ黒字（ATR-P時代の話で、今もそんなギリ経営してるのかは知らないですが）、というような経営をうまく回してました。
ATR-P当時の我々は、補助金でドーピングするような経営など長続きしないのだから、ちゃんと本業を回して黒字にするような経営をしろと批判的でしたが、そんな経営でも10年も回せれば大したものです。
（一方で、その得体の知れない謎の集金力に対し、とはいえさすがに技術などの実体がないのに口先だけではいかに弁が立とうと金は集まらないだろうし、またサイコパスでもない限り資金を集めるプレゼンの場で、実体もない技術を嘘で塗り固めるようなことはしないと思うので、Stroly社の次の集金の際にアピールする要素を皆無にするために、技術で殴って外堀を埋めようとしているのが今のMaplatの活動になります。冒頭で書いた、私がStrolyの技術を貶める記事を何度も書いているのは、この技術的優位を広報することで、Stroly社の集金能力を潰えさせることが目的です。）
その他にも、Stroly社にはATR-Pの時代に私も在籍して、経営の方向などの議論に私も参加しましたし、当時コンシューマー向けビジネスのコの字も知らなかった彼らに私は自分の経験知識をちゃんとトランスファーしましたし、その当時に議論して決めた方向性を、今も彼らが踏襲しているところはいくつもあります（踏襲しているというより変え方がわからないので変えていないというのもあるでしょうし、また中には、前の記事で書いたこの事例のように、ちゃんと議論して方向性を決めたにも関わらず、技術的に実現できなくなってしまってなし崩しに無くしてしまった施策もあるでしょうが）。
Stroly社が今やっていることの一部には、技術の大半を私が作ったことも含め、過去の私を相手にしている部分もあるのです。
そういう彼らの得意な点や、私も含めた蓄積が彼らの中には既にあるのであって、少なくとも、同じようにコンシューマ向けビジネスなどもろもろ素人なStroly競業業者が、私に意見を聞いたり、忠告を受け入れたりせずに舐めてかかって潰せるほど、Strolyは甘い企業ではないと思います。
翻って、Maplatを採用して、協力してStrolyを打倒しようと言ってる、あるいは言っていた、いくつかの企業の方はどんな感じか。
Maplatを採用することによって、技術面ではStrolyを上回れる可能性（飽くまで可能性です。採用した側がMaplatを使いこなせるとは限らないので。実際、Maplatを採用したにも関わらず、使いこなせなかったためにStrolyよりはるかに劣った機能しか実現できなかった会社はありました）は提供されていますが、その他の面でStrolyのパフォーマンスを上回れていないにもかかわらず、程度の差はあれ少なからずStrolyを舐めてかかっている会社ばかりです。
お前らほんと、どうして根拠もなく相手を舐めてかかって、そして漏れなくやらかしてしまうのか。
不思議で仕方ありません。
その中で特に酷かった会社で、あまりに酷すぎて付き合うメリットがなさすぎるので今は付き合うのをやめてしまった会社があります。
上記で書いたMaplatを使いこなせなかったのもこの会社ですが、これがまあ酷かった。
元々は先方から声がかかって、投資を集めて一緒に新しい会社を作るくらいの勢いで、Strolyを倒しにかかりましょう！という話だったので、一時期ほぼ行動を共にしていたのですが、
頻繁に行なっていた打ち合わせで、私が「新機能ができて、これでこう、さらにStrolyの技術を上回ったんですよ」と説明すると、すかさず「やりましたね！これでStroly倒せますね！」とかその会社CEOの彼は言うんですが、当然そういう事を言うのだから、Strolyを倒すための技術以外の部分、Strolyからシェアを奪うための戦略を立案したり、そのための資金を調達したり、デザインを提供してくれたり、するのかと思ったら、何もしてくれない！
本当に何もしてくれない！
恐ろしいほど何もしてくれない！
競業企業としてのアプローチで、技術だけ上回ったってStroly倒せるわけないやろアホか！
上回る技術持ってたって広報したりしてシェア奪わなきゃ知られることなく、何も変わらんやろ！（というかその技術すら、Maplat使いこなしてないせいでStrolyを下回ってたけどな！）
ソリューション広報のために必要な技術のランディングページや、プレスリリースすら全く打ってなく、そのため彼らがStroly対抗のソリューション持ってることすら人に知ってもらえない状況だったので、そういうの作って人に技術を知ってもらう機会作らないとシェア広がらないですよ、Strolyはそういうのちゃんとやってるから、営業しなくても使ってみたいとお客さんの方から仕事が来ることがあるんですよ、とかアドバイスしても、「いや、私の経験上そんなページとかにコスト費やしても受注増えないんですよ、ちゃんとお客さんに営業かけて初めて受注が取れるんです」とか言ってて、蓋開けてみればStrolyのシェア奪うどころか、年数件しか受注取れなくて経営危機に陥ってる有様。
ほんま、なんで競業相手を上回るパフォーマンス出せてない分野で、なんでまず相手を否定してかかれるのかが全く理解不能。
今その分野で相手に負けてるなら、まず相手を研究しろや。
その上で、相手のやり方を理解した後初めて、相手を追い抜くための工夫を加えろや。
デザインなんかも、その会社は酷かったです。
この画面はその会社のアプリでMaplatを使ってくれていたページでの画面だが、左下に何の説明もなく置かれている回転矢印ボタン、普通にタップしても何も起きない。
この意味不明のUI、何の機能だと思います？
正解は、現地で見た場合に、GPSで現在地が表示されるんだけど、そのGPSの場所に視点を戻すボタンらしい、そんなもんわかるか！100人ユーザがいたら100人わからんわ！
アプリ全般を通じてこのノリのむちゃくちゃなUIだらけなんですが、だったらせめてヘルプが充実しているのか？と思ったら、多言語対応アプリを謳っているくせに（確かにUI上の文字は5か国語くらいに切り替わりはする）、ヘルプ見たら日本語ヘルプしかなく多言語対応してない！
おまえ、これ案件が落札さえすればよくて実際にユーザにどう使われて観光の状況がどう改善したか追跡するつもりのない地方自治体から、受注して金取るためだけに適当に機能散りばめただけで、実際にユーザに使わせる気さらさらないやろ！
この辺も、Maplatの機能使いこなしていないのと合わせて、改善するよう何度も何度も提言したが、聞く耳持たず1年経っても2年経っても改善しないままでした。
これならまだ「デザイン馬鹿」のStrolyの方がはるかにマシだし、これで「Strolyに勝てますね！」とかよく言ったもんだと思うわ。
あるいは金集め。
その会社とはベンチャー投資を得るために一緒にベンチャーファンドを尋ねたり、投資コンテストに応募したりしたこともありましたが、1ヶ所に断られただけで、「いや、もううちは投資とか話きても全部ダメなんですよ」とか言って、次に動こうとしない。
Strolyは、「金集めるのだけは得意で、どんな魔法使ってるんだか」とか先に書いたけれど、数社からベンチャー投資を勝ち取るのに、少なくとも数十社VC回りまくってるのくらいは知ってるわ！
私だって金を得る方じゃないけど、MaplatがGeoアクティビティコンテストで初の三冠、みたいなのだって、その前の経産省のビジネスプランコンテストも、総務省の異能ベーションも、全部落ちて、アーバンデータチャレンジとかも毎年門前払いで、それでもメゲずにやってきたから勝ち取れたわけです。
てめえが責任を負うべき金集めの分野で、粘り強くチャレンジを続けずに一箇所二箇所否定されたくらいで引き下がってて、これで「Strolyに勝てますね！」とかよく言ったもんだと思うわ。
ほんま、自分の責任の領域でStrolyに全く勝ってないくせに、Strolyのやり方を研究したり、そのやり方を知ってる私の忠告聞いたりせずに舐めてかかって、企画、労力、金のコストも一切突っ込まずに、どうやってStrolyに勝つつもりだったのか、Stroly打倒しましょう！という話を私のところに持ってこようと言う気になったのか、理解に苦しみます。
技術的に勝ってるMaplatの勝ち馬に乗れば、鼻くそほじっててもStroly倒すところまで連れてってくれるとでも思ってたのか。アホか。
さすがに、その会社と付き合い続けても、Maplatにとって足枷にこそなれ何のメリットももはやないので、付き合いは完全に断ちました。
さすがにこの会社が飛び抜けてむちゃくちゃでお尻を出した子一等賞なので、他の会社はここと比べると全然マシなのですが、それでも少なからずStrolyを舐めてかかっているところ（かつ、同時にStrolyにコンシューマ向け事業のやり方のイニシエーションをした私のノウハウまで含めて舐めてかかっているところ、お前は技術だけ提供してれば良い、とでもいうような、言葉選ばず言わせてもらえばど素人だろうに）があります。
某Maplatを使ってくれている別の会社では、いろんな人から地図を集めるプラットフォームの一部としてサービスを投入する計画だったのですが、Webで機能を提供するのではなくスマホアプリの上に自社メディアアプリプラットフォームを提供し、その中で顧客の地図を配信するという事業計画を立てておられました。
ですが、もはやその頃には、世間のトレンドはアプリからWebに移っているのは明白で、Strolyもアプリ中心からWebに軸足を移している状況でした。
Webに軸足を移すべき理由としては、
StrolyがWebに軸足を移した理由は、これだけの経験のあった後での結論であるわけですが、そこにわざわざリスクに飛び込むように、自社メディアアプリを投入しようとその会社はされていたので、上記のような内容を掻い摘んで話して、今はWebも提供すべき、ということを提言しました。
が、その会社は、「StrolyはWebプラットフォームにしたせいで、低品質の地図も混ざり込んで玉石混淆のメディアになっている、うちは厳選した地図を提供する高品質アプリにするので、十分に勝てる」と、なんか自信満々なんですが希望的観測いっぱいのことを言われていたので、まあそう言われるなら、とその時は引き下がりました。
ところがそれから1年ほどして、その会社がある案件を受注しそうな話を聞いた時、どうも案件の内容的にアプリだけでなくWebも必要になりそうな感じだったので、アプリは御社の既存プラットフォームでいいでしょうが、Web部分は御社の既存ソリューションにないので、Web部分はSIできる会社探してこちらで引き受けますよ、と提案したところ、「いや、この1年営業していてWebの必要性を痛感しました。Webのプラットフォームもうちで用意します」と。
いや、経験からでも気づいたのはエラいですけど、それ、1年前の私の提言受け入れていれば、1年も無駄な活動せずにロケットスタートできてましたよね？
また、今からでもWeb版作るのはいいですけど、Webメディアもノウハウお持ちじゃないですよね？またStroly研究もしないで、自分たちの思い込みだけでメディア作れば、また1年後に「あの時ああやってれば」になりますよね？
その辺わかってるんですかね？
私のアドバイス、10年以上もの経験と、あとそのことばかり考えてきた深みがあるもんなんですけど、軽くあしらわれてむちゃくちゃ舐められてますよね？
まあいずれにしても、Strolyは当然現状では嫌いですが（現状では、というのは協業する道もこちらは提案しているので）、己の対向すべき分野でStrolyのパフォーマンスを超えていないのに、Strolyを舐めてかかる連中にも腹がたちますね。
Maplatの基本原理の申請中特許ですが、無事公開されていました（特開2019-91147）。
6月半ばには公開されていたというのに、審査請求しないといけないのに弁理士さんちゃんとチェックしといてくれよ...週1回くらいはチェックする言うとったやんけ...と言うわけで審査はまだ請求してないのでこれからです。
この記念に、比較等しながら、Stroly社の特許の価値の検証でもやってみようかなと思って記事を書きます。
まず、Strolyの主たる特許は2つあります。
これに先行するほとんどビジネスモデル的な特許もありますが、座標の計算方法や具体的な機能の作り込みに言及してるのはこの2つなので、この2つの価値を検証していきたいと思います。
まず、Strolyのもっとも基本的な特許である、経緯度から絵地図座標方向への座標変換の手法を定義した特許について見てみます。
この特許の本文を読み進めてみましょう。
ご覧の通り、ここでは正確な地図の方の座標が「絶対位置座標」と言う名称で定義されており、そしてその後に、「絶対位置座標とは緯度経度系である」ことが定義されています。
当然のことながら、緯度経度系というのは直角座標系ではなく極座標系です。
ということは、その後の幾何学計算も極座標であることを前提に計算式がたてられないといけないのですが、この特許の中では、直角座標を元にした幾何学計算で式が綴られます。
ぶっちゃけこれだけでも意味のない計算をしているということで特許無効だと言ってもよさそうなものです。
恐ろしいことに、2009年に私がStroly社にジョインするまでのプログラム実装では、本当に「経緯度の座標値を使って3平方の定理で距離を求める」など、極座標値で直角座標の幾何学計算を行なっており、完全に意味のない計算を行なっていました。
それを意味のある計算にするために、絶対位置座標の値として直角座標であるWebメルカトル座標値を用いるように変更したのが私です*1。
ところがそのために、特許では「絶対位置座標 = 緯度経度」と定義されてそれを元にした数式も記されているにも関わらず、実際の実装は「絶対位置座標 = メルカトル座標」となっており、特許と比較して「緯度経度をメルカトル座標に変換する」という余分な計算手順が入っています。
つまり、現行の実装は特許に記された通りになっておらず、この特許で守られていない、という問題が存在します。
まとめると、特許5681920号には、
という問題が存在していると言えます。
上記な問題点があったとしても、特許5681920号が有効でさらに実装も守られていると、飽くまで仮に、しましょう。
しかし、特許5681920号は既にそれを上回る技術で陳腐化してしまっています。
以前から何度か記事に挙げている、MaplatがStrolyに優る部分劣る部分のマトリクスを再掲します。
このうち、特許5681920号と比較できるような性能要件は、
ですが、これらでStrolyの特許は劣っており、既に陳腐化しています。
しかしながら、全単射変換できるかとか、線を線に変換できるかとか、そんなに大切な性能なのでしょうか。
もし、それらが大切な性能ではないなら、別にStrolyが劣っていても全然構わないかもしれません。
では実際にはどうなのか、「Stroly自身がどう考えているか」を見てみましょう。
Stroly側の2つ目の特許、特許5810411号の中の記述を見てみます。
はい、なんと書いてありますか。
この特許5810411号は特許5681920号を前提にした特許なので、ここでの説明は特許5681920号の性能についてですが、ある座標Xa, Yaを順変換Ωと逆変換ωで連続変換してXaΩω, YaΩωを求めた時、「(Xa, Ya) と (XaΩω, YaΩω)が一緒であることは保証されない」と書いてありますね。
そしてそこからの続きは、「特許5681920号では保証されないけれど、保証されているかのように見せかけるための技術」をつらつらと書いて、その内容で特許を取ってますね。
はっきり言うと、Maplatが実現した全単射変換機能は、Strolyができないと自身の特許の中で明言し、なんちゃって機能でごまかした、「(Xa, Ya) と (XaΩω, YaΩω)が一緒であることを保証する」機能です。
つまり、「Maplatができること」を、Strolyは自身の特許のなかで「やりたいけどできないこと」として明言しており、つまりは自らMaplatに対する負けを明言していることになります。
このくらい酷く、Strolyの特許はいまや完全に陳腐化しています。
続いて、その2つ目の特許5810411号の内容について精査してみましょう。
この特許は広範な特許で、Strolyの特許技術のうち、特許5681920号がカバーする単方向の座標変換を除く、ほぼ全ての技術を網羅しています。
ちなみに、発明者は私の単独名特許です（特許を行使する権利はStroly社にありますが）。
余談ですが、Strolyの特許も単方向座標変換以外は私の特許、既にStrolyの性能を超えているMaplatも当然全て私の頭の中から出たものです。
従ってこの地球上に存在する古地図を歪ませずに扱う技術のうち、9割以上は私の頭の中から出ています。
この優位性はStrolyが、どれだけ世の中の普通の意味で優秀な人材、pythonの達人や機械学習の博士や一部上場企業の開発部長やを集めようが、突き崩すことはできません。
今後古地図を扱う技術について、Maplatが様々なブレークスルーを産むことはあれ、Strolyから画期的な新技術が生まれてくることはほぼ100%あり得ません*2。
閑話休題、特許5810411号の内容に戻ります。
今回、この特許がカバーする広範な機能の中で、「方角と縮尺を一致させる変換」について注目してみます。
この機能は、複数の地図を切り替えた際に、中心点の位置だけでなく、地図全体の縮尺や方角も大まかに合わせる機能です。
Strolyは当初中心点の位置合わせや、GPS現在地を青い点で古地図上への表示だけしかできない技術でしたが、それだと現地に行って現在地がGPSで表示された時にしかあまり面白くありません。
なぜなら、古地図には北が上でない地図もたくさんありますし、縮尺も当然現代地図とは違います、すると、中心点だけ一致しててもその周辺の状況が古地図と現代地図の間で重ならないため、ユーザにとっては古地図と現代地図のどこがどう対応しているのかピンと来ず、地図を切り替えても楽しくないからです。
地図を切り替えることが面白いと思ってもらえないならば、Strolyは単なる古地図画像ビューアにしかなりません。
現地に行かなくても地図を切り替えるのが面白いと思ってもらえて初めて、Strolyは何時見ても楽しいソリューションになり得るわけです。
そう言う議論があった上で、実現したのがこの特許の「方角と縮尺を一致させる変換」になります。
では、今現在のStrolyで、この機能がどのように動作しているか試してみましょう。
検証手順は下記の通りです。
ボタンで地図をOSMに切り替える
これは正確に説明すると、「方角と縮尺を一致させる変換」のうち、方角を合わせる機能は動作しているが縮尺を合わせる機能がずれてしまっているために起こってしまっています。
このバグについては、昨年（2018年）11月にStrolyの開発担当に通知済みですが、もう半年にわたり修正されていません。
おそらく、特許の動作原理がわかる人間がもう中に誰もいないので、直し方もわからなくなっているものと思います*3。
これは正直、技術経営的に相当にまずい状況じゃないかと思います。
Strolyはこれまでに5億近く資金を調達してきていますが、その資金を調達するに当たっては、VCにこんな特許を押さえてきていますから、と説明して、自社に価値があると思わせて調達してきたはずです。
が、蓋を開けてみれば、物理的におかしなことを述べていて無効の恐れすらある特許や、現行のやり方を守っていなさそうな特許、完全に陳腐化していてライバル技術が実現している事を「できません！」と高らかに宣言している特許、そして特許でできると宣言しているのにそれを具体化する技術が失われている特許。
この状態を放置しているのって、技術経営の投資家に対する背信状態ではないのでしょうか。
また、過ぎた投資についてはもういいのだと仮にしましょう。
このような特許状況にあったと言うことは掴んでなかったのだ（それ自体問題ですが）、嘘をついたわけではない、と言い逃れられるとしましょう。
しかし、次の資金ショート時に次ステージの資金調達時、どのように投資家にプレゼンするのでしょうか？
私はもう、検証記事を書きました。
いくらこちらを無視していたとしても、年単位で後の次の資金調達までには、Strolyの経営陣に伝わるでしょう。
うちはまともな特許持ってないですけど、次の資金5億10億ください、とプレゼンするのでしょうか？
いや、1万歩譲って、この特許検証がStroly経営陣まで伝わらなかった、そんなわけないのだけど、伝わらなかったふりをして特許はまだ価値があると信じているふりができたとしましょう。
それでも、彼らは既にMaplatを知っています、これは嘘はつけません。
資金調達のプレゼンだと競合分析などもしないといけないと思いますが、どのようにプレゼンして資金調達するのでしょうか？
資金も調達してない個人のオープンソースプロジェクトなのに、うちより機能も性能も上な競合技術が存在しますが、次の資金5億10億ください、とプレゼンするのでしょうか？
果たしてどのようにしてStroly社が次の資金調達を乗り切るのか、なかなか楽しみではないでしょうか。
この記事を書くために特許周りを漁っていて、Strolyが他に出した特許を見つけました。
Google Patentにまだ入ってなかったのでリンクが貼れませんが、特許6537702号です。
地図を処理する技術ではなく、地図DBからユーザのコンテキストにあった地図をリコメンドする機能のようです。
その手の技術についてStrolyが特許を出しているのは掴んでいたのですが、せいぜいユーザの現在地や注視点をベースにした周辺検索で、地図のサイズによって優先順位をつけるとか、その程度の話かと思っていたら、ユーザの人気度や口コミ評価なども加えてスコアリングする事を考えているようで、ちょっと思ってたのと違って面白いです。
が、ユーザの人気度とかによるスコアリングは、メディアとかを運営するレベルの事業者だけが視野に入れればいい話で、単に地図処理システムのユーザ利便性要件としては、現在地や注視点等の経緯度をベースにして、あとは今のユーザが注目している地図スケールにマッチする地図のサイズのコンテキスト等でソートできれば十分だと思います。
そう言った程度のことを考慮して地図DBから地図をソートして抜き出す手法は、このブログで過去に記事にして取り上げています。
この記事は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で、「部屋から出ずとも名所はめぐれる」と題した記事が公開されましたが、まさにその部屋から出ずに古地図を楽しむための技術をダメにしておいて何言ってんだ、と思っちゃいました。
MaplatやStrolyで古地図を扱うには、GCP(Ground Control Point)と呼ばれる、古地図上の座標と正確な地理座標を対応づける対応点データを多数整備する必要があります。
この対応点数点の周りでベクトル計算をすることにより、座標変換計算をするのが古地図座標を扱えるタネなので、このGCPをいかに整備するかが古地図技術のキモとも言えるところになります。
今現在は完全に手動でやるしかなく、簡単な地図ならば10点とかそこらで済む場合もありますが、複雑な地図だと1000点以上打つ場合もあります。
まあ私のような古地図好きにはいかに大変でもご褒美のような作業ではあるものの、それでも時に面倒臭い...と思うようなこともある作業なので、あまり古地図などが好きなわけではない人にとっては苦行のような作業と言えるのではないかと思います。
なので、機械学習などを利用してこれを自動化しようという発想は昔からあり、実現方法の腹案も持っていました(それについて述べるエントリなので、どのような事を考えていたかはあとで述べます)。
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登録自動化方法のアイデアは、次のようなステップを踏んで実現するものです。
という手順でのGCP指定自動化を考えています。
が、画像処理や機械学習の周りは私に完全にノウハウがないので、その辺の所に詳しい方や企業で具体化に力を貸してくれる方、一緒に特許取得を目指してくれる方おられましたら、ぜひ rekishikokudo (@) tilemap.jp までご一報いただけると嬉しいです。
なお、古地図と現代地図の道路/水系ネットワーク間の類似性から対応点、対応線を抽出する技術には、機械学習だけではなく、こちらの会社の技術なんかも使えるんじゃないかなと思って注視しています。
この会社の技術は、異なる会社の生成した、微妙にジオメトリが異なる地図間で、対応付けを生成して各々の地図間での道路属性などをマージしたりできる技術のようなので、古地図の道路ネットワークと現代地図の道路ネットワークのような、似ているけれど微妙に違う関係性などもうまくいけば処理できるのではないかと期待しています。
私の開発している古地図絵地図アプリ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でアカウントお持ちの方、ぜひご協力いただければ幸いです（スター返しなどもお引き受けします）。
スターつける対象のプロジェクトは以下の通りです。
よろしくお願いいたします。
スマホの音ゲー、アイドルマスター ミリオンライブ シアターデイズ（略称ミリシタ）が現在2周年キャンペーン中なんですが、その最中に通常楽曲として、ついに我那覇響の「Rebellion」が配信されました！
この曲は私の大好きな曲で、その歌詞の内容*1が、Strolyに裏切られてたった一人でMaplatを開発していて、何度も心折れそうになっていた時に出会って、私を勇気付けてくれた2つの曲の1つでした*2。
実は、Maplatのテーマカラーである#780508の赤系カラーも、Rebellion Redという色名の色*3から採っています。
その意味で、RebellionはMaplatのテーマソング的にも私は考えています。
まあそれだけの話なのですが、嬉しかったので記事にしてみました。
*1:我那覇響(沼倉愛美) Rebellion 歌詞 - J-Lyric.net
*2:もう一つは、やはりミリシタの、ジュリアの「プラリネ」でした。 プラリネ～アイル - YouTube ジュリア(愛美) プラリネ 歌詞 - J-Lyric.net
www.facebook.com 2021/7/18追加: Facebookがログインしてないと見られなくなっていたので mainichi.jp
作家の寮美千子先生の連載、毎日新聞のならまち暮らしで、奈良京終地域に鎮座する京終天神社（飛鳥神社）が話題に採り上げられました。
記事中で京終天神社の社伝と歴史書に残る史実の違いについて触れられていますが、この記事の作成に、私がそれまでに調べていた情報などを提供して協力させていただきました。
本ブログで、毎日新聞側記事では字数などの問題で載らなかった詳細を補足させてもらいたいと思います。
江戸中期の書物「奈良坊目拙解」には、京終村と高畠村（現在の高畑町）で水争いがあり、百姓を殺害された高畠村が幕府に訴えて出たという血生臭い事件が記されている。このとき、京終村の人々が京都の北野天満宮に加護を祈ったところ、無罪となり、京終村が高畠村より先に取水することを許された。そのしきたりが、いまでも続いているそうだ。
享保15年（1730年）ごろ成立した奈良の地誌、「奈良坊目拙解」の「京終町」の条には上記記事引用の通りの内容が、年月等には触れないままに記載されています。
その訴訟勝利の神恩に感謝するため、天神社の祠を祀ったのが、京終の天神社の始まりだと記されています。
同じような記録は延宝6年（1678年）ごろ成立した別の奈良の地誌、「奈良名所八重桜」の「富士権現」の条にも似たような記録が残っており、同じように京終村が水論で他の村と争って幕府で訴訟になり、勝利を神に祈って勝てたためその神を勧請したという記録がありますが、八重桜ではいくつかの違いがあり、
といった違いがあります。
これらの地誌は現在から比較するとはるかに近い時代の事柄を記録していますが、しかしながらどうしても同時代の一次資料ではないため完全に信じることはできませんが、同時代の一次資料的記録として、「本光国師日記」と呼ばれる金地院崇伝の日記に、慶長19年（1614年）4月20日の条として京終村水論の訴状が残されているそうです。
そのため何らかの史実に基づいているのは間違いなく、奈良坊目拙解と八重桜の記述の違いは似たような事件が2つあって京終には天神と富士権現の両方があったのか、それとも八重桜が天神を富士権現に取り違えて記録したのか*1まではわかりませんが、何れにしてもその他の地誌まで確認しても、江戸期の記録に見える京終の神社は天神または富士権現とした記録のみで、今の飛鳥神社祭神とされる事代主神を祀った記録は一切残されていません。
飛鳥神社の今に残る社伝を信じると、江戸期どころか室町の初めには、元興寺鎮守の飛鳥神社が京終に移転していたはずなのですが、その存在が京終村の記録として奈良の地誌に残っていないのはどう考えても変です。
ここから、「京終天神社」は、明治・大正期には「紅梅殿社」と呼ばれるようになった。
1889年（明治22年）の奈良絵地図 s.maplat.jp
1917年（大正6年）の奈良絵地図 s.maplat.jp
などでは、確かに紅梅殿神社と記されています。
無格社だったこの神社が宗教法人として法人格を取得したのは１９５３年（昭和２８）。申請書に「明日香鎮座の元興寺鎮守社が、平城遷都に伴って平城京に移されたもの。古くは平城坐飛鳥天神社と呼ばれていた」という旨の社伝が記されているので、その名を掲げ、以来「飛鳥神社」と呼ぶことにしたという。
先にも書きましたがこの「明日香鎮座の元興寺鎮守社が、平城遷都に伴って平城京に移され（て、さらに室町初めに京終に移された）」という京終村の記録は、1953年の宗教法人の申請書に書かれた社伝以外には一切残っていません*2。
では、京終村以外では残っているのか？というと、実は残っています。
先にも出た「奈良坊目拙解」の、「西ノ新屋町」の条には、同町内に「飛鳥神並神社」一座が鎮座している、という記録があり、元々元興寺鎮守社で、高市郡の飛鳥法興寺から遷座してきた、と記されています。
それに続けて、「近世（この飛鳥神並神社を）率川明神と号すがよくない説で、飛鳥川は率川と和語が似ているので謬って伝えたので正さなければならない」と「奈良坊目拙解」には記されていますが、これが今に残る西新屋町の率川神社です。
同様の記録は、やはり江戸時代の地誌である「本朝佛法最初南都元興寺由来」や、1890年（明治23年）発行の「平城坊目遺考」などにも、やはり「飛鳥神並社、今は誤って率川神社あるいは率川阿波神社となる」という形で記されています。
京終飛鳥神社の社伝と比較して、
という点で一致しており、これに「室町初期に京終に移された」という項目を加えると、そのまま京終飛鳥神社（京終天神社）の社伝になります。
ところが実際には、飛鳥神社社伝が京終に移ったとするよりはるか後の江戸期資料でも、この元興寺鎮守社が京終に移ったという記録はなく、西新屋町の率川神社こそが飛鳥神社を名乗るべき、という記録しか残っていません。
この事は、江戸時代よりも後の後世に、西新屋町の率川神社の由緒を参考に、京終飛鳥神社の社伝が創作された可能性を強く示唆すると思われます。
それでは、飛鳥神社社伝が創作されたとして、いつ頃創作されたのでしょうか。
まず京終天神社側の状況は、「ならまち暮らし」内にも書かれ先に古地図2枚を引用したように、明治大正期は京終天神社は紅梅殿神社と呼ばれ飛鳥神社とは呼ばれていなかったので、社伝を創作する意味がありません。
西新屋町率川神社の方は、
1889年（明治22年）の奈良絵地図「率川飛鳥神社」と記されており、まだ「飛鳥神社」の名称が残っている s.maplat.jp
1917年（大正6年）の奈良絵地図、「阿波神社（率川阿波神社の略か）」となっている s.maplat.jp
となっており、率川神社＝飛鳥神社であることが大正期に忘れられつつあったのではないかと推察されます。
つまり大正までは社伝を創作する目的がなかったので創作は昭和以降という事になりそうですが、ではいつ創作したのかという事になると、「社伝」などというものを登録しなければいけなくなった戦後、宗教法人として法人格を取得した1953年（昭和28年）その時ではないかと私は考えます。
宗教法人になる際に社伝、由緒を登録する必要が生じて、中世の大火で古文書が失われ伝わってきた社伝がなかった京終天神社が、忘れさられつつあった西新屋町率川神社の社伝を借りて創作したのではないか、というのが私の考えです。
社伝が100%創作物だ、という証拠はありません。
また、社伝が創作物であってもそれがどうした、寮さんもならまち暮らしで書かれているとおり、信仰の場で人々が何を心の拠り所にしているのかこそが大切だ、ということもわかります。
が、一方で私は、京終の鎮守が、そんな国家鎮護元興寺のそのまた鎮守社だった、などと言うような大仰なものでなくても、京終村を昔から水論で勝てるなどの現生利益で守ってくれた、地元密着の身近な守り神だった、それだけで十分ではないかと思うのです。
また心の拠り所だからこそ、それが正しくどのような言われがあってどういう歴史を辿ってきたのか、どう祀られてきたのか、正しく伝えられていくべきだと思うのです。
また少なくとも、伝説の領域を外れた史実を語る場では、今は社伝を元にしてしまっているため、本来は史実が語られるべきはずの奈良市史、奈良県史などでも京終天神社を「元興寺鎮守社だった」と記してしまっていますが、今後はそのようなことがないよう、史実が史実として紛れなく伝わっていくよう、情報を残していかないといけないと思うのです。
そのような思いを込めて、このブログ記事を残させていただきました。
© Code for History
