Code for History

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

璉珹寺通信寄稿『さろんに通って6年、関東からももう4年』

私は毎月1回、関東から奈良京終の璉珹寺へ京終さろんというイベントに参加させてもらうために関西へ戻っているのですが、この度、その京終地域のローカル情報誌である『璉珹寺通信』2020年新年号に寄稿を依頼されました。 その内容をブログにも転載しておきます。


 京終さろんに私が通い始めて、もう6年程度になります。通い始めた頃は高畑に住んでいたのですが、2年ほど通った時に転職の都合で関東に引っ越さなければならなくなりました。でも京終さろんから離れたくなかった私は、それから今まで4年、関東は相模原からほぼ毎月、京終さろんに通い続けました。この12月で、関東で新しい会社に転職したのですが、一つの会社に在籍するのは4年我慢できなかったのに、京終さろんには6年を超え通い続け今後も通うのですから、私の奈良好き、京終好き、京終さろん好きも我ながらあきれるほど大したものです。

 京終さろんに私が通い始めたきっかけですが、私はIT技術者で、古地図を使って街歩きできるアプリ*1をつくったり、ITテクノロジーを使って街をよくしていくボランティア活動団体*2に属していたりしていました。そういった活動をしていくにあたり地域のコミュニティに困っている事を聞いたり、解決すべき問題を見つけたりする機会が欲しくて、地域の人が集まっていると言う京終さろんに参加し始めたのが最初です。ですがすぐに、そういった最初の目的より、京終さろんそのものが面白くて通うようになりました。毎回思っても見なかったような角度から京終やならまちの魅力を語ってくれる講師の皆さん、そしてそれを元に豊富な知識を持って議論する地域の参加者の皆さん。こんな面白い空間が世の中にあるとは私はそれまで想像もしていませんでした。

 奈良だけでなくいまや群馬館林など各地の地誌も読み調べ散らかしている今の私をご存知の方は意外に思うかもしれませんが、ほんの6年前まで、私は地域史とか特に詳しくなかったのです。高校の頃歴史学志望だったり、事業で古地図扱ったりと言う素地はありましたが、基本ずっと技術者だったので、そこまで地域史に興味もなかったのです。それが地誌を読み漁ったり、街歩きでいろいろ調査したりし始めたのは、一重に京終さろんに通って、講師や参加者の人からいろいろ教えてもらった結果です。一度興味を持つと人一倍のめり込むのと、誰もやってない事をやりたいという欲があるので、これやる価値があるのじゃないか?と思って奈良中の地蔵や祠の場所を記録して回ったり、地誌や古地図内で(多分)新しく発見したことを披露してみたり、あるいはこの歴史間違っているのではないか?とか、飛鳥神社の由緒の話などでは多少暴走してご迷惑をおかけしているかもしれませんが、ぜひ暖かく見守ってください。

 私の出身は姫路で奈良に対しては新参者(どころか正確には既に去った者)ではあります。ですが、姫路では多少知られた詩人である祖父((大塚徹)))が、作詞したいくつかの姫路ローカル歌謡曲が、京終に縁のあるテイチクから発売されていて、偶然ですがここに来るのが運命でもあったような、不思議な縁を感じています。そして、そういった地域の隔たりを超えた京終への縁を、あえて遠くに住んでいる立場を活かして、今度は私が作り出したい。11月の京終さろんでは、京都から大学時代のサークルの後輩を呼び寄せて、古典と新作の狂言比較という新しい試みを楽しんでいただきました。私も手伝いですが、6年を経て初めてさろんの講師側に立たせていただいて、嬉しく思っています。特に何が具体的に動いているわけではないですが、寮さんが提唱している中将姫を奈良で盛り上げていく話も、中将姫は東北から九州まで全国に逸話がある奈良を超えたヒーローですので、ぜひ前に進めたい。私の友人の、群馬の歴史研究者が提唱した概念に「大字(おおあざ)史」というのがあり、それは大きな歴史ではなく、小さな大字単位の歴史を住民が主体で掘り起こし、記録し出版し、そうしてできた小さな歴史を関係性で織りなすように繋げて大きな歴史を再構築していく試みですが、もうすぐ京終本を発行される京終は、偶然にもその大字史のような概念が奈良でももっとも進んでいる地域ではないでしょうか。その京終の大字史を、奈良、日本、世界との縁につなげる一助に、今後も関わっていきます。

緊急提言:行政だからこそ、プロプライエタリなStrolyではなくオープンなMaplatを使うべき

[注:本記事はほぼ同内容のQiita記事のシャドーです]

東京都が開催したスタートアップイベント、UPGRADE with TOKYOの情報が入ってきましたので、急遽その結果に対する提言を述べる記事を書くことにしました。

東京都副知事の宮坂さんのツイートによると、Maplatと似た機能を提供している、Stroly社がこのイベントで優勝したそうです。

ツイートの内容を見ると、都庁観光センターにある700種類のイラストマップを、今後デジタル化し位置情報もついた状態でスマホでナビゲーションできるシステムを、競争入札あるいは随意契約でStroly社に依頼する可能性もあるというふうに受け取れます。
が、ここで情報提供しておくべきなのは*1、Strolyはこのようなシステムを作り得る世の中で唯一の技術ではなく、おなじこと、いやそれ以上ができるオープンソース技術が、Maplatとして、世の中に存在するということです。
対抗技術がオープンソースで存在する以上、行政は随意契約など行うべきではなく、競争入札を行うべき案件であろうということになります。
行政なればこそ、Stroly社サーバ上でしか動かない技術ではなく、本来はオープン技術を使うべきであろうと思いますので、随意契約など論外であろうと思います。

そしてMaplatには、Strolyを上回るいくつもの性能、機能上の特徴があります。
その辺を網羅した最新の機能対応表は下記の通りになりますが*2

f:id:kochizufan:20191222133319p:plain
StrolyとMaplatの機能差一覧
このいくつかについて、行政システムに対応する際の利点、問題点なども交えて説明を加えますと、

  • MaplatはStroly技術と違い、古地図/絵地図上の点と正確な位置座標が必ず1対1で対応する事を保証することができるので*3、人命危険性のない観光、エンタメ用途のみならず、防災など人命がかかるような用途にも使っていただける技術です。
    Strolyは正しい場所に位置が表示される保証がないため、人命がかかった災害用途など(例:ハザードマップ)に使うことは困難です。
  • Stroly技術と違い、Maplatは古地図/絵地図上の線と、正確な地図上の線(たとえば道路、線路形状など)の形が異なっても、双方の対応点が必ず線の上に乗るように変換させることができます。
    なので、抽象的に描かれたバス路線図、鉄道路線図上に車両の位置を表示したりといった用途にも利用できます。
  • Stroly社のサーバの上でしか動作せず、継続して公開しようと思えばサービスの継続フィーをStroly社に払い続ける必要のあるStrolyと違い、Maplatは東京都様のサイトの上でも、サーバサイドの開発の必要なくWebサーバに静的ファイルを配置するだけで動きます
    サーバサイドがないので、都のWebサーバが落ちない限り障害が発生することもありません。
  • Stroly社のサーバの上でしか動作しない、すなわちインターネットに繋がった環境でしか動作しないStrolyと違い、オフラインでも動作可能なMaplatは、たとえばネットにつながらないスタンドアローンな公共博物館内でのシステムなどでも、館内システム開発の部品としてご利用いただけます。
  • 決まった動作の地図サイトしか提供できないStrolyと違い、Maplatは動作を外部からAPIで制御できるので、先にも書いたようなバス路線図、鉄道路線図上にリアルタイムな車両の位置をAPIで制御し表示したりと言ったことにも利用可能です。
    Stroly社も、特別に機能追加を依頼すれば作り込みでできるかもしれませんが、公開されたAPIをStrolyは持たないため、その作り込みができるのはStroly社のみになりますが、Maplatはオープンソースですので、どちらの業者様でも使い方さえ覚えれば競争入札に参加できることになります。
  • スマホのネイティブアプリの部品として組み込めるようなネイティブSDKライブラリも用意しておりますので、観光アプリなどの中でも部品として使うことができます。
    Stroly社もスマホアプリを作ることはできますが、SDKがないため、古地図絵地図表示に関係ない部分含めて随意契約でStroly社に発注して作らせることしかできません。
    MaplatはオープンソースでネイティブSDKライブラリを用意していますので、どんな会社でも使い方さえ覚えれば作れるので競争入札させることができます。

といった特徴があります。

単に誰でもアクセスできるオープンソース技術があるだけでなく、これだけ

とこれだけ悪条件が重なっている以上、Strolyが随意契約になどなり得る根拠などありません。
むしろ、前の3条件は性能や動作原理に関わるものである以上、追加開発でなんとかできる類のものではないので、逆にこれらが競争入札の発注仕様に入っていると、Strolyの方が競争入札に参加できないような類のものです。

逆に残念ながら、StrolyにあってMaplatにないものもあります。
それは、ユーザが無料でオンラインで地図を編集し、発行できるオンライン地図エディタです。
これは残念ながら、開発工数およびシステム運用含め、技術力の深さよりマンパワーで解決される類のものなので、多大な資金を持って人を集めているStrolyに比べ、オープンソース活動でしかないMaplatはこれを準備できていません。
しかしながら、お金のない一般個人を相手にするB2C案件では、無料オンライン地図エディタの存在は大きいですが、行政から請け負うようなB2B案件では、無料オンライン地図エディタの存在はほとんど意味がありません
たとえば都の案件でも、700枚の地図のマッピング作業を、お客様側である都の職員が、自らエディタを使ってデータ編集し、サイトの運営だけStrolyに任せるでしょうか?
そうではなく、700枚の地図のマッピング作業まで含めて、発注仕様に含めるでしょうし、そうなると無料オンライン地図エディタの存在は特に意味がありません。
もちろん、基本データの作成は発注するものの、微修正は都の職員がやりたい、という要件も出てくるでしょう。
が、これも、Maplatはオンラインエディタはないもののオフラインエディタはちゃんとあるので、これも都の職員にオフラインエディタで編集してもらって、データだけ納入してもらうという形で、即時性にさえ目をつぶれば運用でカバーできるものです。
あるいは、性能が足りていないのではなく機能が足りていないだけなので、この案件のためだけに必要十分最低限のオンラインエディタを追加開発するというのもアリでしょう。
いずれにしましても、Strolyがオンラインエディタを持っていることで、お客さんがコンテンツを少し改変できる自由度で多少優位なのは事実ですが、しかしながらもっと広い意味の自由度では、Strolyサーバの上でしか動かないStrolyサービスと違い、全てをお客さんのサーバの上で動作させられる(全てのコンテンツをお客さんが持っている)Maplatの方が、はるかに自由度が高いのも事実です。

今回、Strolyがこのイベントで1位を取り、宮坂副知事が言及したことで、700枚もの地図を扱うシステムを都が開発する可能性が見えて参りましたが、

  • 一般庶民の都民としては、このシステムが随意契約で劣った技術と高価なフィーの会社に案件がわたり、税金が無駄にされることのないよう監視していく必要
  • 公共団体向け受注を生業とされる企業様においては、この大きなシステムの競争入札が出てくることに備え、Maplatを勉強し、対応できる提案を磨いておく必要

があるのではないでしょうか。

*1:というか、既に宮坂副知事にもUPGRADE with TOKYO運営事務局にも情報提供済みですが。

*2:表のオリジナル含め、Maplatの基本的な機能はこちらのリンクで見ていただくことができます。>> http://bit.ly/maplat_flyer

*3:専門用語で「同相変換」というものを保証できます。Strolyはその保証ができず、双方向に変換した際に元の場所に戻ってくる保証がありません。

Apple地図で小字が大大と地図面に表示されるのは仕様なのか?

約一年前に、Facebookに以下のような投稿したんだけど、

某超大手地図サービスにデータ解釈のバグ見つけた。 マニアックといえばマニアックだが、普通に普段使ってれば気付く範囲に出てくるバグ。 関係者にレポートしたのでいずれ直ると思うが、うちの会社も今日本地図対応しようとしてるけど、実装部隊に日本人いないので、ちゃんと解釈できるのかやきもきしたり絶望的になったりしてた。 でもあれほどの巨大サービスでもまだ解釈バグあるんだから、うちも公開してからちょっとずつ叩かれて直せばいいかー、と少し気が楽になった。

これ、1年経っても直ってないけど、この地図サービス的には仕様という判断でいいのだろうか?
どこのサービスか明かすとAppleの地図で、バグ?の内容は、正式住所じゃない小字部分(例:奈良市高畑町の小字、破石町、本薬師町など)が、あたかも住所でございと表示されてる問題なのだけど。

f:id:kochizufan:20191203075319p:image


これ、生じてる原因は、Appleが使ってるiPCの住所データには小字か小字じゃないかを判定するフラグが付いてるんだけど、それを無視してデータ投入してるから。

 

ちなみに、Google Mapでも、今年4月の地図データ変更直後には、同じ問題が起きていた。
それが、データ変更後のGoogle Mapsが住所データはiPCのデータを使っている、と私が判定した根拠の一つだったんだけど、今見たら直っている。

f:id:kochizufan:20191203075438p:image

直った理由が、小字フラグをきちんと判定するロジックに修正したのか、それともそもそもまた違うデータソースに変えたのかはまだ不明。

オープンデータの文脈で見た場合の、StrolyとMaplatの比較について

先日、OpenStreetMap界隈の人とオープンデータやMaplatについて議論したけど、オープンデータの文脈でMaplatについて強調しておきたい点は、Strolyはオープンデータを消費するだけのプラットフォームにしかならないのに対し、Maplatはオープンデータを新たに生み出す基盤にもなり得る点です。

StrolyもMaplatも、古地図などの地図画像と、それを現実に結び付けるマッピングデータの組み合わせで動作する点は違いがありません。 が、Strolyは、オープンデータなどで他所様で公開されている地図画像を利用するだけで、自らのプラットフォームで生み出すマッピングデータについて、その帰属ライセンスを明らかにする事を、明示的に要求されてもこれまで全く行っていません。 つまり、Strolyはオープンデータの文脈において、他者の生み出したオープンデータを消費するだけで生み出すことのない、オープンデータのブラックホールでしかありません。

それと比べてMaplatは、そういうStrolyへの批判を視野に入れて開発されたこともあり、マッピングデータのライセンスをデータ中に明示できるように作られています。 つまり、Maplatはオープンデータを消費するだけではなく、生み出す基盤としても機能するという点が、オープンデータの観点から見たStrolyとMaplatの大きな違いです。 この違いを意識して、オープンデータ界隈の方々がもっとMaplatに興味を持っていただけると嬉しいです。

Stroly社社長の高橋真知さんに、Strolyの競合技術比較と特許に関する疑義について内容証明を送りました

最近このブログで取り上げている、Stroly社と私のMaplatの間での競合技術比較(Maplatが「線を線に変換する」新機能に対応しました。実証サンプルとして宇野バスのバス運行路線図Webアプリ作成。 - ちずぶらりHackers)や、Stroly社の特許に関する疑義(Stroly社の特許の価値を検証してみる - ちずぶらりHackers)について、Stroly社社長の高橋真知さんに、2019年8月12日投函で内容証明を送りました。
内容証明といっても、何かを要求するとかそういうものではなく、内容はあとでこの記事の末尾にも引用しますが、単に競合技術比較や特許に関する疑義を提供する記事へのポインタを列挙した程度のものになります。
送った目的は、今後同社が追加投資を募るための投資家への技術プレゼンをする際や、あるいは案件獲得のために見込み顧客へ技術プレゼンをする際レベルまで含め、「競合技術のない、世界唯一の技術です、特許で守られてもいます」などといった虚偽のプレゼンをすることがないよう、Maplatの存在やそれとの技術比較、また特許への疑義などを「知らなかった」等と逃げられることのないよう、虚偽のプレゼンをすれば本日以降、確実に「意図的に虚偽を伝えた、嘘をついた」と言える状況を整えるためです。

もちろん、内容証明の中でも書きましたが、これらの技術比較や特許への疑義は完全に私の方からの一方的な主観ですので、適切な反論や否定見解をStroly社側がもしプレゼンの場で加えることができれば、今後も投資や受注がゼロになるということはないでしょう。
また、Stroly社が現在、ソリューションの売りを古地図を扱う技術そのものから、古地図絵地図プラットフォーマーとしての価値の方に軸ずらししようとされているのは感じるので、その辺でうまく訴求できれば、同様に今後も投資や受注がゼロになるということはないでしょう。
しかしながら、より性能の高いMaplatがオープンソースで出ている以上、単なるプラットフォーマーだとより大きな資金で競合が参入することは極めて容易ですし、先行優位性についても数百万件、数千万件先行しているならばともかく、現在Stroly社が所有しているであろう1万件程度のコンテンツでは、とても先行優位などと言えるレベルではありません。
やはり、プラットフォーム事業を展開するにしてもそれを裏打ちするのはより優秀な要素技術、ということになると思われるので、その意味でもこの内容証明受領後、Stroly社が誠実な技術プレゼンに移行した場合はゼロにはならなくても投資や案件の成約が著しく困難になることが予想されますし、逆に今後Stroly社の投資や案件の成約がこれまでと変わらないペースで続くようならば、同社は不誠実な、虚偽を含むプレゼンをその後も続けている蓋然性が高くなります。
そうした不誠実な、虚偽を含むプレゼンをStroly社が今後もする、と仮定した場合に、何らかの理由でStroly社のプレゼン先の方がMaplatの存在やStroly社特許への疑義に気づいた場合、Stroly社が気づいていなかったからそれらを無視したプレゼンをしたのではなく、確実に嘘をついた、投資家や見込み顧客に虚偽を意図的に伝えた、ということが証明できる状況を作るべく、行動したのが今回の内容証明とこの記事の目的になります。

id:otsune とかこういうこと好きそうなのでメンションしておく。

以下、Stroly社に送った内容証明全文です。


株式会社Stroly
高橋真知様

Maplat大塚です。
お世話になっております。
突然内容証明を送らせていただきますが、特に要求事項などがあるわけではございません。
昨今、当方では御社のお持ちの特許や技術の検証や、当方の技術と比較した記事や、学会発表などを何度か行わせていただいておりますが、御社が今後行われるであろう資金調達の場での技術プレゼンテーションや、あるいは日々の営業活動の中でのプレゼンはじめ、様々な技術アピールの場で事実と異なる内容を発表される場合に、Maplatの存在やその比較、検証内容を御社が「知らなかった」と逃げられる余地を全くなくすよう、当方主観からの分析内容を証明できる形で高橋様に共有させていただくのが目的となります。

共有したい記事、発表内容などの一覧は以下のようになります。
Maplatの国際地図学会2019での提出論文
http://bit.ly/maplat_paper_icc
Maplatの国際地図学会2019での発表資料
http://bit.ly/maplat_icc
Maplatの機能概要説明チラシ(Strolyとの比較あり)
http://bit.ly/maplat_flyer
最新の「線を線に変換する機能」含む、MaplatとStrolyの機能比較記事
http://bit.ly/maplat_line2line
御社特許の価値分析記事
http://bit.ly/stroly_patent

もちろん、上記は単なるURLの羅列ですので、実際に上記を訪問してその内容を確認されるか否かは高橋様の自由ではあります。
しかしながら、高橋様は当然出資者から投資を受けて会社を経営する者として、競合技術などの動向調査、対策のマネージメントなども職責にある方である以上、情報の方からそちらに来ているにも関わらずそれを確認することを怠ることは背任的な行為にあたるのではないかと存じますので、高橋様が上記URLを確認されるようがされまいが、私がこれを証明できる形で送った以上、今後御社はこれらの比較や分析の存在について「知らなかった」と言い逃れはできない状況になったと考えます。

また、やはりこれも当然、上記の各分析、比較は当方の主観に基づくものであり、御社としては異なる見解、反論などもおありだろうと存じます。
そういった反論、御社見解の展開は、もし公開の場で表明いただけるならば、私のブログなどの表現の場でもきっちり紹介させていただきますし(私は御社を打ち倒そうとは考えておりますが、正々堂々と打ち倒したいと考えておりますので、反論などをご提供いただければ責任持って当方でも公開させていただきます)、あるいは公開しない営業や投資家向けプレゼンの場のみで反論、見解を展開されるのも自由です。
また昨今、御社が私の技術と真っ向競合する古地図絵地図を扱う技術そのものを売りとするのではなく、古地図絵地図を共有できるプラットフォームを売りにする形に軸ずらしを進めておられているのも感じておりますので、その軸ずらしの方向性が評価されて、要素技術としてはMaplatに負けていたとしてもアプリケーションが評価されて追加投資を受ける可能性もあるでしょう。
その意味で、当方がこのように見解を御社に共有したからと言って、必ずしも100%御社が投資家様などにアピールできることがなくなるわけでもなく、追加投資などが絶対に見込まれないわけではないという点は理解しております。

ただ、Maplatを担ぐ私の方も、余暇の範囲内でぼちぼちですが投資を募る活動なども若干はやっておりますが、Maplat技術の優位性、有用性は評価いただいても、プラットフォームサービス事業に投資するという話になった際に、「Maplatがオープンソースで展開しているのであれば、より大きな資本が資金を投下してオープンソースMaplatを使ったプラットフォーム事業に乗り出した場合、勝てる理由がないのではないか、というような指摘をいただくなどして、現状投資が成約したことはありません。
ましてやMaplatに劣る要素技術をベースにされておられる御社でも、単にプラットフォーム事業で訴求する形だと同様の疑問を投資家様に持たれるのは当然ではないかと考えており、相当すばらしい極秘の腹案を示されるのならばわかりませんが、単なるプラットフォーム事業の訴求だけで追加の投資が得られる蓋然性は極めて低いと当方では見ております。
先行して事業されていることによるコンテンツの確保も、何百万何千万件クラスのコンテンツをすでにお持ちであれば確かに大きな投資を呼び込む要素になり得ますが、1万件前後の今の御社のコンテンツ数程度であれば、大きな投資を呼び込める訴求要素になるとは到底思えません。
投資を呼び込める事業計画はやはり、要素技術での優位が前提にあっての、プラットフォーム事業であると思うのですが、その意味では当内容証明を受け取られた今後の御社は、投資家や営業先でのプレゼンの際に、競合技術比較や特許に対して向けられた疑義に対して見解を示すことが道義的に必須になると感じており、もし今後の営業や投資家向けプレゼンの中で、Maplatとの競合分析や特許に示された疑義に反論などもなく一切触れないままのプレゼンを続けられたとして、何らかの形で後にMaplatとの機能比較や特許への疑義がプレゼン先に知られた場合、「知らなかった」というような言い逃れはできなくなった点は指摘、強調させていただきます。

さて、今回お伝えしたい技術比較や特許への疑義などの資料は以上になりますが、それに加えまして、これまでも何度か様々な経路で御社にはお伝えしておりますが、適切なライセンス費用などを支払っていただけるならば、MaplatをStrolyの代替エンジンとして差し替えていただくのも全然構わない、という点はお伝えしておきます。
ライセンス費用、というのはもしStrolyのエンジンをMaplatに置き換える場合、私の協力で御社向けだけのクローズソース版Maplatを作らないといけなくなると思いますので、それに対するMaplatの知的財産権ライセンスの名目になりますが、Maplatはオープンソースですので、もし私の手助け一切無しに御社の尽力だけでStrolyエンジンのMaplat差し替えを実現いただき、必要なライセンス表記などもサービスに加えていただけるならば、別に当方にライセンス費用を一切払うこともなくエンジンをMaplatに差し替えていただくことも可能です。
これにより、Stroly技術より優秀なMaplat技術をベースにした、先行優位もあるプラットフォーム事業を投資家や営業先にアピールできるので、御社にとっても得こそ多くあれ損はないのではないかと存じます。
よろしければご検討いただければ幸いです。

以上、よろしくお願いいたします。


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

© Code for History