Code for History

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

MapBoxとZenrin提携が話題ですが、OpenStreetMap創設者Steve CoastのTomTom入りの方が世界的にはインパクト大と思う

前置き

私は某地図会社に勤めています。
その会社の中で、3年前の合流時よりこの会社はこういう方向に向かうべき、というアイデアを社内でことある毎に共有してきたのですが、個人レベルでおもしろいね、と言ってくれる人はいたものの、会社のアクションとしては全く相手にされることはありませんでした。
今回、そのアイデアが今後採用されることがなくなった/採用されても意味がなくなった決定的な出来事が起きましたので、アイデア供養も兼ねてこのブログで公開共有したいと思います。
会社に勤める者として、社外秘の情報は当然公開しちゃダメですが、個人が内部で挙げたアイデアで、経営陣レベルどころかマネージャ層レベルですら揉まれた事のないようなアイデアを社外共有するのに、何の秘密保持違反もクソもないと思うのですが、念のためこの記事中では私の所属は某社として伏せておきます。
ちょっと調べればすぐ分かるのですが(この記事からリンク貼るつもりの資料の中にすら書かれているかと思うし)、まあ直に検索にひっかかるのもよくないかなと思うので。

ICC2019でのショック

先々週は日本で何十年ぶりの国際地図学会、ICC2019の実施週でした。

www.icc2019.org

ちょうど同じ週に、SoftBank Worldも開催され、ICCとSW両方にゲストスピーカーとして呼ばれたMapBoxの首脳陣が、mapbox.jpのローンチと、(これは以前から知られていましたが)Zenrinとの提携、そしてYahoo Japanおよびコマツとの提携を発表しました。

sbw.tm.softbank.jp

blog.mapbox.com

これは日本の地図界にとっては中々のインパクトです。
OpenSourceで技術が磨かれているMapBox社の技術は超一流で確かなものの、使っているデータがOpenStreetMapで、ビジュアライズはともかく地物属性などに不安があるのでエンタープライズの利用には躊躇があったであろうところに、日本ではいきなり、ついこの間まで天下のGoogle様御用達だった超一流地図データのZenrinとのセットで殴り込みをかけてくるわけです。
Google Mapsの一時的データ劣化である種の阿鼻叫喚、狩場になっていたであろう日本のエンタープライズ地図技術市場に、巨大黒船が、ついこの間まで使ってた失われたあの思い出深い地図データをひっさげて上陸してきたわけです。
これむちゃくちゃ顧客流れますよね...せっかくの狩場なところ、某社が日本を投入する頃には獲物残ってるんだろうか...変えたばかりの顧客がまたすぐ変える事はほぼ期待できないの含め、これ相当な危機意識持たないとダメですよ某社...現場はともかく、首脳陣とか危機感持ってるのかな...雲の上の方々なのでよくわからん。

が、日本市場ではこれが大きなニュースですが、個人的にはICCで知った別の事件にもっとインパクトというかダメージを受けました。
事件というか、今年4月には起こっていたことを、アンテナ感度が低かったために掴んでいなかっただけなのですが、

ICCのキーノートに呼ばれたSteve Coastが4月からTomTomのVice Presidentになってる!マジで????????

Steve CoastやTomTomといっても、知らない人の方が多いかもしれません。
Steveは、OpenStreetMap創始者です。

en.wikipedia.org

TomTomは、世界の多くの国の地図データを提供できる、世界的地図の最大手の1つです。

www.tomtom.com

最大手と言っても、某社の方がシェアも規模も大きいのですが、Googleは世界的に地図サービスを展開しているものの地図データは販売していないので、世界的に多くの国のデータを共通データ仕様で提供できる会社というと、世界探してもほぼ某社とTomTomしか存在しないと言っても過言ではありません。
ちなみに、Appleマップは日本ではiPCのデータを使っていますが、海外ではTomTomです。
その中でもシェアは今のところ某社の方がTomTomより圧倒的に多いのですが、しかし某社にとってもTomTomにとっても、OpenStreetMapは徐々にシェアを奪う大きな脅威になりつつあります。
リッチな道路属性などデータ品質保証が必要な領域では、OpenStreetMapはまだまだ足元にも及ばないというか比較するの自体が馬鹿らしいような存在ですが、しかしながら地図というのはそんな道路属性が必要な用途だけではないので、単に地物の形状を描画するだけの用途であれば、OpenStreetMapは着実に某社やTomTomのシェアを奪いつつあります。
つまりは、某社やTomTomにとってOpenStreetMapは商売敵扱いであり、私もよく社内で、冗談ではありますがOpenStreetMapに取り組んでいることに対し「裏切り者(笑)」と言われることがある存在です。
そのOpenStreetMap創始者、ようするに持ち主が、TomTomの二番目に偉い人ですよ。
「両者をリンクさせず、単に仕事ではTomTom、プライベートではOpenStreetMapの両方やる」なんてのは、もはや利益相反(Conflict of interest)とかってレベルじゃなくて背信行為に近いでしょう。
明らかに、TomTomの地図とOpenStreetMapの地図をリンクさせることを狙っています。
予言しますが、近いうちにTomTomは、OpenStreetMapの最大のContributor企業になるでしょう。
そして、それを元に、TomTomはOpenStreetMap上の成果をTomTomのデータソースとしても使うようになるでしょう。

なぜ自信を持って言えるかというと、それが私が某社の中で、3年前からずっとそうすべきと言ってきたことだからです。
某社の地図とOpenStreetMapの地図をリンクさせて、某社はOpenStreetMapの最大のContributor企業になるべき、それを元に、某社はOpenStreetMap上の成果を某社のデータソースとしても使うようになるべき、というのを、ずっと私は主張してきました。
が、SteveがTomTomのVPになった以上、その戦略はTomTomが採るだろうし、TomTomのVPが率いる組織であるOpenStreetMapに、某社がContributeすることはもうないでしょう。
さようならマイアイデア
供養のためにここにどんなことを考えていたか晒します。

OSM利用レベル1:変更をウォッチする

OpenStreetMapを競合扱いしかしていない某社の中では、OpenStreetMapを忌避こそすれそれを調査したり、有効に活用しようとする機運はありませんでした。
が、ご存知の通りOpenStreetMapはあらゆる存在にとって敵でもなんでもなく、単にルールに従えば誰でも編集したり利用できたりする、データの置き場でしかありません。

なので、私はことある毎に、OpenStreetMapを敵視するな、むしろ某社の利益のために有効に使え、ということを主張してきました。
その中でも一番簡単な利用法として、OpenStreetMapを使っているということを公にしなくてもできる施策として、「OpenStreetMapを監視せよ」ということを言ってきました。

私は1年くらい前まで、販売後の地図製品についてお客さんのクレームをサポートする部署にいました。
そういう部署にいると、「◯◯国で◯年前に開通している高速道路、おたくの地図だとまだ反映されてないけどどうなってんだ!」みたいなお叱りを受けることがありました。
某社全世界の精密な地図を持ってますが、力の傾斜配分があるので先進国だとまず瞬時に高速道路の新規建設などは反映されますが、やはり発展途上国などだとどうしても新しい発展に気付くのが遅くなり、反映が遅れてしまう時もあります。
そういう時に、競合の状況比較で他社の状況を調べた時に、某社の地図では反映されていない道路がOpenStreetMapでは反映されていることが、全てのケースではありませんがいくつかのケースではありました。

反映されているOpenStreetMapのデータをそのまま盗用してデータとして使うと当然大問題ですが(その視点で、他社の状況を調べたというと、反映のために他社のデータを盗用したのか、と疑われるかもしれませんが、某社の地図は詳細な地図属性を整備する必要があることもあり、整備自体は実際に現地確認しないと反映されませんので、その点は大丈夫です)、しかし、OpenStreetMapの変化点の履歴は誰でも使える形で公開されているデータであり、それを監視することは別に誰に対してでも認められていることです。
監視していると公言する必要すらありません。
OpenStreetMapの変化点を随時監視し、自分たちの地図と大きな差があれば、それを現実変化のセンサーとして検知し、現地調査に向かって変化を反映する。
この体勢が作れれば、現実の反映がOpenStreetMapより遅かったとしても、年単位で差をつけられるようなことはまず起こり得ません。

この提言を社内に対して行いましたが、おそらく地図製作担当部署の責任者までは届いていないので、私の提言を起点としてこの施策が採られたということはないと思います。
(ただ、別にやってると公言する必要のない施策なので、地図製作担当部署内で同じことを考えた奴がもしいれば、始めている可能性はあります。なので某社がこれをやってるのかどうかは私にはわかりません。)

まあこれは、効果的だけども地味なOpenStreetMap活用法ですが、私の本論はその次の提言で、もっとアグレッシブにOpenStreetMapを活用する案でした。

OSM利用レベル2:OpenStreetMapのデータに某社の地図データを貢献する(競争力に問題のない範囲で)

市場では、某社やTomTomの地図データが、OpenStreetMapの地図データと同じ俎上に並べられて、優れている劣っていると評価されます。
が、これ、本当に同じ俎上に並べられるもんなのでしょうか?
私は全くそうは思いません。
道路を扱う上で、重要な情報である属性 -- 一方通行、右左折禁止、制限速度、一時停止、Uターン禁止、レーンの数、路側帯駐車スペースの有無、交差点でのレーンの接続関係、駐停車禁止、信号の有無、交差点の形状、通行可能な車種、通り抜け禁止、優先車線、中央分離帯の有無、中央分離帯が物理的かゼブラか、トラックの高さ制限、幅制限、長さ制限、爆発物積載車禁止、道路の種別、道路の路面状況、道路の名称、スクールゾーン、環境地域、有料道路の通行料 -- 思いつくだけでもこの程度、普通の身近な道路でも200以上、特殊な道路だとそれ以上の属性が、某社では4000ページ以上の整備仕様書で定義され、どんな道路でも確実に付与されます。
TomTomでもそうでしょう、が、OpenStreetMapではこのような属性の整備は全く保証されません。
このような特殊な属性も定義する仕様はOpenStreetMapでも存在するのですが(例:ターン禁止の仕様)、ボランタリーなOpenStreetMap整備者にそれを整備することは全く徹底されていないため、整備は全く保証されません。
実際問題OpenStreetMapの道路では、属性というと道路種別の1属性しか整備されていない道路なんてザラにあります。
200種以上の属性整備が「保証されている」地図と、属性があるのかないのかさっぱりわからない地図 -- この両者が並べられようはずがないのですが、しかし実際には、共に独立した「地図データ」として市場に並べられるため、詳細までデータを精査した人以外には、両者の品質の差の詳細はわかりません。

が、市場に並べられる前に、両者の品質の差を明確にできる仕組みを作れたら?
それが私が某社内で提案していた施策です。
OpenStreetMapの弱い地域での道路ジオメトリや、あるいは某社の属性整備の優位性を侵害しない範囲での一部の属性などを、OpenStreetMapにデータとして寄付すればよいのではないか。
OpenStreetMapが全世界で、たとえば一方通行と制限速度属性だけを完璧に整備しても、その他の200以上もの属性を整備している某社地図の優位性は揺るぎませんが、それら程度ですら完璧には整備されていないOpenStreetMapにとっては、大きな貢献になります。
それだけではなく、某社のごく一部のデータを寄付してOpenStreetMapに貢献という構図を作ることは、OpenStreetMapデータの上位バージョンが某社の地図データ、つまりはLinuxでいうところのOpenStreetMapCentOS、某社地図がRedHat Linuxみたいな関係性に持ち込めるので、「うん、低品質なデータが使いたい人はOpenStreetMap使えばいいよー。でも高品質な地図が欲しい人は某社地図使ってねー」という構図に押し込めることができます。
こうなると、俎上に並ぶ前に既に差がついていますから、営業としても対OpenStreetMapで優位な主張ができる分、アピールがやりやすくなるでしょう。

その他にも、この施策を行うとマーケットで良い立場に立てる可能性がたくさんあります。
まず最前提として、それだけ全世界で一部属性の整備がほぼ完璧になるほどの貢献をすると、OpenStreetMapのコミュニティの中で某社がまず押しも押されぬ一番貢献している会社、ということになると思いますが、そうなると全世界の優秀なOpen Source 開発者や地図技術者の興味を某社に引くことができ、優秀な人材の確保にも役立つことでしょう。

また、OpenStreetMapに大きな貢献をすることによって、逆にOpenStreetMapになされた多大なボランタリーな更新なども、某社地図データに取り込むことがやりやすくなります。
いまやOpenStreetMapは、多数の暇で奇特なボランティア集団が空き時間にシコシコ更新してる趣味データベースではなく、MicrosoftAppleFacebook、Mapbox、Grabといった巨大企業が投資をつぎ込み、OpenStreetMapを更新する人間を雇用して雇って、OpenStreetMapに対する更新も平日夕方や休日より、平日日中の方が活発になっているような状況になっています。

FacebookはこんなソリューションもOpenStreetMapに投入しようとしています。

gigazine.net

世界を牛耳るGAFAMのうち、3つまでが投資しまくっている成果がOpenStreetMapには集まるんですよ!
今でこそ道路形状だけかもしれませんが、これだけの投資があれば、将来的には某社が必要とするような属性もOpenStreetMap上に自動整備されたりできるようになる可能性もあります。
そしてその成果を自社地図データに取り込んでも誰にも文句言われないような関係性をOpenStreetMapとの間に作っておけば、GAFAMのGとA以外がつぎ込む豊富な資金から生まれた成果を、堂々と自社地図データに取り込めるのです。
投資金額ではGoogle一社に負けないエコシステムを、作れる可能性すらあります。

そういう提案を、私は某社の中でしてきました、いつか採用されるだろうと思い。

OpenStreetMapとTomTomが繋がることにより、私のアイデアの採用される可能性はなくなった

が、SteveのTomTom入社により、某社とOpenStreetMapが繋がる可能性はなくなりました。
さようならマイアイデア
私のアイデアなんてしょせん組織を経営したこともないどシロウトの思いつきなので、SteveのOpenStreetMapとTomTomは、もっと世界を驚かすような関係性を示してくるかもしれません。
が、もう少し抽象性を高めて確実に言えることは、繰り返しになりますが、TomTomは、OpenStreetMapの最大のContributor企業になるでしょう。
そして、TomTomはOpenStreetMap上の成果をTomTomのデータソースとしても使うようになるでしょう。
自分のアイデアが潰えたのは悔しいですが、Steveがどんな未来を見せてくれるか、楽しみではあります。

Maplat - Historical map viewer technology that guarantees nonlinear bijective conversion without distortion

This is html-based mirror of ICC2019 paper.
Original paper is here:

www.slideshare.net

and presentation slide is here:

www.slideshare.net

Historical map viewer technology that guarantees nonlinear bijective conversion without distortion

Kohei Otsuka, Code for History

Abstract

Historical maps rich in historical information play an important role in fields such as tourism and history education. However, for ordinary people without knowledge of historical studies, it is difficult to understand inaccurate old maps that have not undergone surveying and to comprehend them in comparison with the current city townscape. Therefore, conventionally in GIS, a large number of corresponding points are prepared between an inaccurate historical map and an accurate map, the coordinates of the historical map are converted by forming a triangular mesh and conducting coordinate complement calculation, and the entire historical map image is re-represented by coordinate conversion. However, as shown in Figure 1, with this method there is a serious problem that causes distortion in the aesthetic appearance of the historical map, and remarkable impairment. It can be said that this problem has greatly damaged opportunities to use historical maps for tourism and historical education.

f:id:kochizufan:20190718100350p:plain
Figure 1. Examples of historical map distorted by coordinate conversion by conventional GIS method.

In this paper, we introduce our technology to solve this problem. Our technology has been implemented in the historical map viewer named Maplat, which is available at https://github.com/code4nara/Maplat as MIT-licensed open source.

In the Maplat technology, the method used for coordinate conversion between an inaccurate historical map and an accurate map is not different from conventional GIS, which is a coordinate complement calculation using a triangulate network of the corresponding point (as shown in Figure 2.).

f:id:kochizufan:20190718100457p:plain
Figure 2. The method of coordinate conversion using triangulate network of the corresponding point.

However, Maplat does not distort the image of the historical map when switching over or superimposing inaccurate historical maps and accurate maps. Instead, whenever the user scrolls the map to change the viewpoint, coordinate conversion calculation is performed in real time, and the overlapping state is corrected so that the position is perfectly fitted only at the center point of the screen. At the same time, coordinate conversion is performed at a plurality of points surrounding the center point at a fixed distance, and the pixel to actual distance ratio (scale) and the rotation angle (direction) on the currently displayed map are calculated using these points. Then the scale and direction of the corresponding map is modified to match the obtained scale and direction, and it is superimposed with the displayed map. With this method, we succeed in positioning and overlaying a historical map with an accurate map to a certain extent without damaging the aesthetic value. Figure 3 shows the behavior when multiple historical maps and an accurate map are successively switched in Maplat.

f:id:kochizufan:20190718100553p:plain
Figure 3. Behavior when switching maps successively in Maplat technology.

A similar approach, roughly overlapping multiple maps by matching the center point, the scale, and the direction, is also adopted by another technology, implemented in a service called Stroly (https://stroly.com/en). This technology began commercial distribution in 2010. However, Stroly uses a newly developed calculation method of coordinate conversion, and because it abandons the calculation method of GIS backed by long-term achievement, there is inaccuracy in the coordinate conversion result. Especially when bidirectional coordinate conversion is repeated between multiple maps, there is a problem that the converted coordinates cannot return to the original place. In contrast, in Maplat, it is possible to guarantee bijective conversion, which always returns to its original location even when conversion is repeated, in coordinate conversions between inaccurate historical maps and accurate maps. Figure 4 shows the result of using Maplat technology and the Stroly technology to convert lattice point sequences on a 1784 Paris map once to longitude and latitude and then inversely convert it back to the coordinates on the historical map. The dark red line is the conversion result of Maplat, and the yellow line is that of Stroly. The conversion result of Maplat is correctly returned to the original lattice shape, and the average conversion error also falls below the rounding error for the number of pixels, but in the Stroly technology the lattice structure is disturbed, and the average conversion error reaches 11 pixels.

Figure 4. Comparison of bidirectional coordinate conversion accuracy in Maplat vs Stroly technology.

In this way the Maplat technology, which does not distort the historical map and does not impair the aesthetic value while guaranteeing the bijective coordinate conversion as in the case of conventional GIS, has been used in fieldwork aimed at historical education (as shown in Figure 5.). As a result, a positive evaluation was obtained that there was a good educational effect through the characteristics of the Maplat technology.

f:id:kochizufan:20190718100814p:plain
Figure 5. Fieldwork using Maplat technology.

Contact: Kohei Otsuka (kochizufan at gmail.com)
Github account: kochizufan Repository: code4nara/Maplat

ICC 2019 TokyoでMaplatの発表をしました

ただいま開催中の国際地図学会2019東京(ICC 2019 Tokyo)で、昨日(7月17日)Maplatの発表をしました。

www.icc2019.org

Open Sourceカテゴリーの枠で発表したのですが、今日18日に古地図関係の枠がたくさんありました。
こちらで発表すればよかった...。
しかも今日は早々に名刺を切らしてしまい...胃が痛い。

論文、発表で使用した資料を公開いたします。

論文

www.slideshare.net

発表資料

www.slideshare.net

己の対向部分でStrolyのパフォーマンスを超えていないのにStrolyを舐めてかかる連中に腹がたつ

連日Strolyを貶める投稿(もちろん嘘や誹謗中傷ではなく、事実を示して、ですが)をブログで続けている私ですが、それは私が開発しているMaplatで、技術の分野で、Strolyを上回る技術を開発しているという実績を既に残しているからです。
Stroly社の技術マネジメント能力は最低最悪ですし、その結果として5億円近くも投資を受け何人もの技術者に専業させているにも関わらず、個人が本業の余暇にお小遣いで作っているオープンソースに技術力で劣っているという、その結果があるので行っていることです。
(もちろん、優っている部分があるからといって相手を貶めていいのかという話もありますが、それは、感情的には私がStroly社から過去被った信義則に反する行いに対し怒っていることと、冷静な理由としても、後述するとおりStroly社が得意な分野に対抗するため別の私の得意な分野で対抗する必要があるから、ということがあります。)

では、Strolyの技術以外の分野はどうなのでしょうか?
別に全く超一流ではないものの、Strolyのそれぞれの分野でそれを上回る成果を出してない奴が、安易に舐めてかかっていい状態ではないのがわかります。

たとえばデザイン。
StrolyのCEOはデザイン馬鹿で、自分の評価指標がデザインしかないために、技術やその他の要素をマネジメントすべき時でもひたすらデザインデザインしか言わず、元同社CTOの中川氏(id:monomoti)も言ってましたが、技術の開発にコストを使わずにひたすらデザインを作っては壊し、作っては壊ししかやっていない人です。
ですが、ちゃんとプロのデザイナー投入した上でそれだけ作っては壊ししてますから、トータルな生産性の面ではともかくとして、結果的に仕上がってるデザインとしては、それで何か状況が好転するほど優れたものではないにしても、ちゃんとまあ見た目的にはよくできてるよね、的なものに仕上がっています。

Strolyのデザインは超一流ではないにしても悪くはない

翻ってMaplatを見てみると、現在のところMaplatにはデザイナーの協力者がいませんから、デザインに力が入れられていません。
私もそれなりにシステムに携わってきた経験があるのでその範囲で、UXが壊滅しているようなUIは作ってないつもりですが、アイコンなどもフリーフォントの流用ですし、ボタンなども地図ライブラリの標準ボタンのカスタマイズです。

デザインの面では、MaplatはStrolyに勝てていない

別にデザインの面で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に軸足を移すべき理由としては、

  • スマホアプリが目新しくてブーストがかかっていた時期ならば別ですが、いまや目新しくも無くなった状況では、基本的にWebはスマホの所有関係なくほぼ全ての人、日本だけでも1億人を母数として訴求するメディアですが、スマホアプリはスマホの持ち主、数千万人を母数として訴求するメディアでしかありません。
    地方自治体その他の主体も、スマホアプリがもてはやされていた頃はどこもかしこもスマホアプリ、でしたが、徐々にそれに気づき始めているので、今はWeb回帰、あるいはスマホアプリ作るにしてもWebとセットで、になりつつあります。
  • しかも、それでもスマホアプリが「数千万人を母数として訴求する」のは、各顧客相手に各顧客専用アプリを作ってあげた場合の話です。
    各顧客専用アプリではなく、自社メディアアプリを1つ作って、その中で各顧客コンテンツを提供する形ですと、訴求力はその自社メディアアプリのダウンロード数の範囲でしかありません。
    自社メディアアプリが1万件しかダウンロードされなければ、メディアとしての訴求力は1万人でしかありません(しかも、そのアプリユーザのアクティブ率にも影響しますし)。
    そういった1億人に訴求する可能性のあるWebに比べ訴求確率が1万分の1の超超弱小メディアに、お金を払ってまでコンテンツを提供したいと言うお客様の割合は、極めて小さくなるでしょう。
  • また、自社メディアアプリの場合は、ユーザの満足度の面でも大きな問題があります。
    たとえば各顧客専用アプリを作る場合、大阪と仙台と福岡の顧客のアプリを作ったとすると、多分それらのアプリは大阪と仙台と福岡のユーザしかダウンロードしないでしょう。
    東京、名古屋のユーザがダウンロードして、なんだこんなアプリ使えないじゃないか、とクレーム低評価をつける恐れはありません。
    ところが、自社メディアアプリの場合、それ自体は位置に対してニュートラルですから、東京、名古屋のユーザがダウンロードする可能性があります。
    それらのユーザが中に大阪と仙台と福岡のコンテンツしかないのを見た場合、確実にこんなアプリ使えねえじゃないか、とクレーム低評価をつけるでしょう。
    そういう危険性が、位置情報系の自社メディアアプリを作る際には常に存在します。
  • Strolyはながらく各顧客専用アプリを作ってきましたが、それはスマホアプリがもてはやされていた頃にスタートしたと言うのが理由の1つ、次には当時のWebはStrolyやMaplatのような歪まない地図を重ね合わせるという技術を表現するにはまだ不十分だったのが1つ、もう1つは、Webに直接載せるほどではないにしても、各顧客専用アプリならばAppStoreなどの中で数千万人の十分に多い母数のユーザに訴求できるからです。
    ですが、私がStrolyに在籍していた時代から、AppleのAppStoreでの方針が変わり、ほぼ同じソースコードで複数の顧客向けにほぼ内容が同じでコンテンツだけが違うようなアプリを量産することを、Appleがスパム行為とみなすようになってきました。
    そしてAppleは、各顧客専用アプリを作るのではなく自社メディアアプリを作り、その中で顧客コンテンツを提供する形に切り替えるよう強制してきました。
    ですが、自社メディアアプリには先に述べたような、訴求力が格段に落ちることで顧客がコンテンツを提供する魅力が落ちる、自社メディア内でコンテンツを提供していないクラスタを引き込み評価が下がる、などの危険性があり、あまりに魅力がありません。
    なので、私がいた頃のStrolyは何とか各顧客専用アプリ提供を引き延ばせるようAppleと交渉してきましたが、さすがにもうこれ以上引き延ばせなくなったのでしょう、その時に、リスクの多い自社メディアアプリではなく、Web側に出て行く決断をStrolyがしたのであろうことは想像に難くありません。

StrolyがWebに軸足を移した理由は、これだけの経験のあった後での結論であるわけですが、そこにわざわざリスクに飛び込むように、自社メディアアプリを投入しようとその会社はされていたので、上記のような内容を掻い摘んで話して、今はWebも提供すべき、ということを提言しました。
が、その会社は、「StrolyはWebプラットフォームにしたせいで、低品質の地図も混ざり込んで玉石混淆のメディアになっている、うちは厳選した地図を提供する高品質アプリにするので、十分に勝てる」と、なんか自信満々なんですが希望的観測いっぱいのことを言われていたので、まあそう言われるなら、とその時は引き下がりました。

ところがそれから1年ほどして、その会社がある案件を受注しそうな話を聞いた時、どうも案件の内容的にアプリだけでなくWebも必要になりそうな感じだったので、アプリは御社の既存プラットフォームでいいでしょうが、Web部分は御社の既存ソリューションにないので、Web部分はSIできる会社探してこちらで引き受けますよ、と提案したところ、「いや、この1年営業していてWebの必要性を痛感しました。Webのプラットフォームもうちで用意します」と。
いや、経験からでも気づいたのはエラいですけど、それ、1年前の私の提言受け入れていれば、1年も無駄な活動せずにロケットスタートできてましたよね?
また、今からでもWeb版作るのはいいですけど、Webメディアもノウハウお持ちじゃないですよね?またStroly研究もしないで、自分たちの思い込みだけでメディア作れば、また1年後に「あの時ああやってれば」になりますよね?
その辺わかってるんですかね?
私のアドバイス、10年以上もの経験と、あとそのことばかり考えてきた深みがあるもんなんですけど、軽くあしらわれてむちゃくちゃ舐められてますよね?

まあいずれにしても、Strolyは当然現状では嫌いですが(現状では、というのは協業する道もこちらは提案しているので)、己の対向すべき分野でStrolyのパフォーマンスを超えていないのに、Strolyを舐めてかかる連中にも腹がたちますね。

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:三角網の形成する三角同士が、もう一方の地図で重なり合ったりしてしまうこと

© Code for History