ロカポブログ

第一回ジオメディアサミット関西、大成功です（感謝！）

noreply@blogger.com (Nao) — Sat, 08 Nov 2008 19:29:00 +0000

※11/14追記写真の講演資料URLを追加しました

　　ジオメディアサミット関西の写真
　　ジオメディアサミット関西の講演資料はこちら

11/8についにジオメディアサミットが関西に上陸しました！
東京でのあの盛り上がりをぜひ関西に、ということで、奈良在住の私が言いだしっぺで、多くの皆さんの力をお借りして実現することが出来ました。

会場はKOF（関西オープンソース２００８）内のFOSS4G OSAKAのセミナー会場。

FOSS4GとはオープンソースのGISを推進している団体OSGeo財団によるイベントで、ソースコード系の人達が多い。
どちらかというとポータルやコンテンツ、マッシュアップといったジオメディアの人達とは、少し違うので、その交流も楽しみにしていました。
FOSS4Gは7日(金)、8日(土)の二日あり、昨日の7日にはKOF全体の懇親会がありました。

さて、今回のジオメディアサミット会場は定員60名。7日にはFOSS4Gの人だけでほぼ満席だったので、今日ジオメディアサミットの人が来て大丈夫かな？と思っていたですが、、、、

今日朝来て見ると、スタート10分前なのに会場はガラガラ。10名くらい。

寒い・・・・

昨日の人たちは・・・・？

考えられるのは

１．昨晩の懇親会の後さらに飲みに行ってたので、朝は来ていない
２．GIS業界の超有名人ハッカーによるハンズオンセッションがあるので、みなそれに出ている

昨日は外国の方（↑の超有名人ハッカー）も来ていたので、プレゼン資料を急きょバイリンガル仕様にしてきたのに、外国人は誰もおらず。うーん・・・・・。

どっちにしてもこの人数では来て頂いてるお客様にも申し訳ないし、講演やライトニングトークをしにわざわざ東京から来て頂いた方も多いので、申し訳ないなあ。

と思っていたら定時の5分過ぎまで待つと8割くらい席が埋まってきました。めちゃめちゃホっとしました。心臓に悪いです。。。

さて、私が司会をさせて頂いて、

怒涛のように講演＋ライトニングトークがスタートしました。講演といっても10分でお願いしていたので、長めのライトニングトークという感じで、
ジオメディアサミットの醍醐味である、「飲みながら多数のライトニングトーク」の一部は再現できるかなとちょっと期待。
直前で話題の「セカイカメラ（頓知・さん）」がご都合でキャンセルされて残念だったのですが、それでもとても充実したプログラムとなりました。
~~まだ写真がないのであとからアップするとして、~~簡単に今日の流れをおさらい。

まず、開会の挨拶はジオメディアとGISの両方にどっぷり浸かっている、もっとも「クロスジオ」なオークニーの森さんによる開会の挨拶。

さて、いよいよ講演のトップバッターは
サイバーエリアリサーチ株式会社中西様による「IP Geolocationとその活用事例」

IPアドレスから位置を割り出すサービスなのですが、広告の配信制御などのマーケティング用とから、スポーツイベントなどを特定の国にしか配信させないようにするコンプライアンス、クレジットカードのアクセス元IPから不正利用を検出するセキュリティへと用途が広がっているそうです。
結構、新鮮なネタで、会場の人はみな熱心に聴き入っていました

次は沖電気工業株式会社福居様による「LocoSticker」

マッシュアップ・アワードではおなじみのAPIで、自然言語からの地名の抽出や、場所からそこに関連するサイトやブログの抽出など。
いつもは5分のライトニングトークで聞いていたのですが、今回は10分でかなり細かく聞けました。沖電気さんは福居さんと同じチームｎ奥村さんという方もFOSS4Gで発表されていて、非常に精力的に活動されているなあ、という印象。

次はヤフー株式会社岩澤様による「Yahoo! JAPAN の新サービス LatLongLab (ラットロングラボ)」の新サービス２本
「猛レース」、「４ｘ３印刷」の紹介。

岩澤さんのプレゼンはいつも独特で楽しい。というか、岩澤さんの居てるLatLongLabやアルプスラボから出てくるサービスって、本当は実用性がめちゃめちゃ高いのに、プレゼンテーションというかサービスの見せ方が「あそびのノリ」のものが多いなあ。単純に楽しそう。

次はマピオンの株式会社サイバーマップ・ジャパン大塚様による「ケータイ国盗り合戦」

言わずと知れたケータイ国盗りですが、ものすごい数のユーザーがいること、いわゆるケータイ層の若者ではなくPC層の35歳前後が多いこと、などマーケティング上の話が面白かった。
どうしても技術に偏りがちなジオメディアサミットですが、実際に技術をビジネスに結びつけるには、こういう視点は欠かせない。
ケータイ国盗り合戦のQRはこちら

ここから、5分のライトニングトークのスピード感を再現したいのと、なるべく沢山のトークを入れたいとの理由で、5分間のライトニングトークを4本挟んで、10分のトークに戻るという変則プログラムに。

講演が終わった後ライトニングトークをやると、飛び込み有の場合など、どうしても「おまけ」感があって、何時まで続くのか、何本あるのかわからず、よほど目を引くプレゼンでないとお客さんの注意がそれてしまう場合が多いですよね。
今回は飲み会でのLTが出来ない分、スピード感を持続させたかったので、間に挟んでみました。結果的に良かったと思います。

さてライトニングトーク一発目は私、有限会社ロケージング（位置情報ロカポ）上田による「位置情報ロカポのご紹介」
なるべく「ジオメディアサミットのLTの楽しさ感」を再現したかったので、笑いを取れれば、とネタの比重を大きくしてみました。うまくいったかな・・・・？

次は有限会社NCプロジェクト西岡様による「汎用性の高い位置情報Ｎコード」

実はＮコードは「位置情報コード」というジャンルでロカポの競合製品でもあるのですが、西岡様はロカポの10年以上前から位置情報の研究をされている、いわば大先輩。特許のデータベースではいつも名前を拝見していたんです。
堺市の方というのは知っていたので、今回関西でジオメディアサミットをやるということで、私からお願いして出ていただきました。競合なのに快く訪問させていただいて、サミットにも出て頂いて大変嬉しかったです。

このあと10分休憩。この時点で5分くらい押しているので、ほぼスケジュールどうりでいい感じ。
セカイカメラ（頓知・）の講演キャンセルは残念だったのですが、時間的にちょうどになりそう。
休憩の後は引き続きＬＴで。

株式会社shiganet 志賀様による「Navitte!」

グーグルのストリートビューをマッシュアップしたサービスで、実際の道路画像でナビをしながら、そこに書き込み（落書きも！）できる。
これなら地図を読めない人にも簡単にナビができそう。

次は株式会社シリウステクノロジーズ関様（ジオメディアの発起人！）による「AdLocal」

FOSS4Gのコピーに「敵にジオを送る：儲からない位置情報サイトを運営して、他業種を儲けさせるさま」という思わず笑ってしまう標語があったのですが（この標語を考えたのは位置情報系の某有名人）、
アドローカルは儲からない位置情報サイトで広告収入を得る貴重な手段。

さて、ここからまた10分枠に戻って講演再開。

マルティスープ株式会社那須様による「アナタノ地図脳ST＠MP（スタンプ）」

場所に関連していろいろな事柄をスタンプしておくアプリ。代わりに覚えておいてくれるというのは、私みたいに記憶力が超乏しい人間には非常に使えそう。補助脳という表現、とてもナイスです。

次は富士通テン株式会社沢田様による「カーナビと携帯電話の連携」

カーナビとケータイの赤外線通信を利用して、いろいろな連携とさせる「ケータイリンク」や「モクテキチネット」のなど話。Yahooのアプリとも連携しているほか、APIも使えるそうで、携帯アプリを作っているなら、そのまま「ECLIPSE」カーナビに目的地設定ができる、というのはなかなかおもしろい。後でいろいろ話を聞いているとマッシュアップ魂を刺激された人が結構多かったようです。

さて、トリはまたまたマピオン（株式会社サイバーマップ・ジャパン）笹田様による「DGRadar：iPhone対応未来型空間レーダーアプリ」

「ジオメディアサミットのトリ」にふさわしく、エンターテイメント性とか、作った人のこだわりとかが前面に出ているアプリ。この発表をみて、「今日の帰りにiPhoneを買う」と言っていたのは、今日のカメラマンをしてもらってた美方システムデザインの濱野さん。
プレゼンも「笑い」あり「おぉぉぉー」ありで、イベントの最後が締まりました。ありがとうございました！

前回までのジオメディアサミットでは、企画メンバーではなく、講演者集めなどをお手伝いしただけだったのですが、今回企画してみて前回までのメンバーの皆さんの苦労が良くわかりました。。。。
司会も難しいですね。。。シリウスラボの関さん、いつもご苦労様です。

なにはともあれ、なんとか無事に終わってほっとしています。

マッシュアップアワード４に応募しました

noreply@blogger.com (Nao) — Mon, 29 Sep 2008 08:28:00 +0000

二週間も経ってしまいましたが、マッシュアップアワード４に今回も応募しました。
応募後もどんどんバージョンアップを続けています！

前回のMA3では
・マップサーファー(富士ゼロックスネットプリント賞)
・日産de旅ログ！？(日産自動車 CARWINGS賞)
・AB-ROAD Map plus (リクルートエイビーロード賞)
という「地図」に関連した３作品を作りましたが、
今回は地図や位置情報とは全く関係のないジャンル（なんと私には全く縁の無い「アート」「エンターテイメント」）での応募です！！
位置情報関連の作品も作成していたのですが、MA4には間に合いませんでした。これは今後ロカポからガジェットとして発表します。お楽しみに！

これまでMA2、MA3とチームで技術ブレインとして頼りにしていたここギコ！さんが多忙のため、今回はパスされるとのことで、同チームでデザイン担当のANNAIさんのお二人と私の3人体制に。ちょっと厳しい。。。

ひとつはもともとANNAIさんが企画されていたサービス、

「フライヤー・コレクション」

さすがデザイナーさんだけあって、非常にお洒落なサイトです。
これに、東京アートビートというアート情報のAPI等をマッシュアップして出品。後に、ニューヨーク・アートビートのAPIも取り入れで、一気にインターナショナルな雰囲気に！ほとんど99%アンナイさんの作品なので、「ANNAI with Locapo」という名前での出品となりました。ロカポとしては、

世界初！ロケーションビューとGoogleストリートビューを並べて表示！

というくらいです。本当は両方の画像をシンクロしたかったのですが、手が回らず時間切れ。
並べてみた感想としては、グーグルの方が高精度な画像という印象。でも移動が瞬間移動の繰り返しみたいな感じ。一方、ロケーションビューは画像サイズは小さいが、ドライブしているようにスムーズ。画像サイズか、画像の枚数か、トレードオフで両社がとった戦略の違いが分かって非常に面白いです。
フライヤーコレクションのサイトで（東京アートビートからデータを取っている都合で）都内のイベントの詳細画面を見れば、二大ビューの比較ができます。

もう一つは、マッシュアップ・キャラバン大阪で発表のあった富士フィルム・顔ラボの顔認識APIによるマッシュアップ。

「人面ですが、ナニか？」

当初は、顔判定機能ももAPIにあると勘違いして企画を練っていて、後でその機能は公開されていないことを知り、焦る。MA3マッシュ賞のクリエイトシステムさんと飲みに行ったとき、「富士フィルムは競争率高そうですよ。みんな使いたいですよ」というような意見を聞き、正攻法で実用性や便利性ではとても他の参加者の方にはかなわないとギブアップ。ここギコ!さんも居ないので、三流技術者の私ではあまり凝ったこともできません！

という訳で、人の顔を認識するAPIに人の顔以外を判断させる、という逆転の発想（というか単なる天の邪鬼？）で、人面魚、人面岩、人面木、などの人面の「人面度合い」を競うというサイトを思いつきました。富士フィルムさんにとっては、人でないものを人の顔と認識する訳ですから、いわゆる「誤認識」となってしまうのですが、逆に言うと限界領域でのテスト用のデータがたくさん集まるというメリットを提供できるかな、と考えました。

人の顔を入れると、当然ハイスコアになるので、それは反則としました。それでも人形とか人間に近いものは高得点が出て当然なのでおもしろくない。ANNAIさんとブレストの末、人面と判定されなければ失格だが、判定されるギリギリの最低点を競う、というコンセプトに決定。これが意外と面白く、楽しくテストできました。

企画スタート時は人面魚でも人面の判定が出ていたのが、途中から人面判定が厳しく（？）なり、全然合格しなくなりました。良く分からない画像を大量に送ってしまったので、富士フィルムさんがアルゴリズムをバージョンアップしたのか！？どうかは不明ですが、サービス開始直前なのにトップランク５までの画像がそろわないというハプニングも。

技術的には初めてPHPで本格的にプログラムしました。富士フィルムのAPIはJPEGしか受け付けないので、一般的なBMP,PNG,GIFでも投稿できるように画像変換＋サムネイル作成、富士フイルムから返ってきたデータで顔と検出された部分に赤の四角をはめ込む合成など、画像を扱うのも実は初めてでした。あと、一度投稿された写真を別の人が名前を変えて投稿できないように画像の重複防止のアルゴリズム、メールをトリガにしてPGを起動し、結果をメールで返す機能など、いろいろ今後役に立ちそうな知識が増えたのは思わぬ収穫でした。

みなさん、ぜひ「人面」を投稿してあそんでください。WEBで見つけた画像URLの貼り付け、アップロード、写メールの３つの投稿方法が選べます。メールは entry@jinmen-ranking.un-nai.com 宛に、タイトルに写真タイトル、本文にはニックネームを入れて送るだけです。

とにかく、「くだらね～～」と言いながら遊んでほしいです！
個人的にはMA2の「HANAABI!!」　が大好きなので、そんなノリのサービスがいつか作れれば・・・と思っていたので、結構満足してます。
やはり作りたいものを自分で作れる、というのがマッシュアップの良いところですね。

第二回ジオメディアサミットへ行ってきました

noreply@blogger.com (Nao) — Thu, 31 Jul 2008 11:14:00 +0000

第一回に引き続いて、第二回ジオメディアサミットへ行ってきました。
地図好き、位置情報好きの会社の枠を超えた交流会、というような感じで始まった「ジオメディア新年会」に端を発する、勉強会兼交流会です。音頭を取って頂いているのがシリウスラボさんですが、商業セミナーではなくて、運営側も基本的に「地図好きの人がボランティアでやっている」手作りイベントです。

今回はYahooさんの後援でYahooのミーティングルームをお借りして、なんと100名超の規模。

○ 無線LANから位置情報を取得する「PlaceEngine」のクウジットから「ロケーションアンプ」、
○ Google、
○ 不動産オークション「マザーズオークション」の子会社で道路の360度画像配信をしている「ロケーションビュー」、
○ Yahoo、
から20分の発表、
続いて5分間一本勝負のライトニングトークが4本
○ 日産自動車モビリティ研究所からCARWINGSキャスティングについて
○ リクルートメディアテクノロジーラボからホットペッパーfor iPod Touch(iPhone)
○ KBMJから電脳メガネなど拡張現実について
○ 再びメディアテクノロジーラボからライターの火とWiiのリモコンとGoogleMapsのマッシュアップ（おもしろい！）

と非常に盛りだくさんで、最新テクノロジー満載、エンターテイメント満載で、
「たのしい～」とニヤニヤしっぱなし。地図好き、位置情報好きにはたまらないイベントとなりました。
まわりを見るとみんなニヤニヤ。

今回、少しだけ企画側お手伝いをさせて頂いたこともあり、皆さんが満足されている様子はとてもうれしかったです。
次回はまだ決まってませんが、少しでも「地図」とか「位置情報」にアンテナが反応しそうな人にはどんどん紹介したいイベントになりました。

昨年、Gungiというイベントで「チズトーク」というマピオンラボvsアルプスラボ対談みたいな企画があって、その後両ラボのコラボサービスが出ていましたが、
今回GoogleMapsの方とYahoo!地図の方が談笑しているのを拝見して「この二つがコラボしたら楽しいだろうなあ」と勝手に想像してしまいました。
両者がガチンココラボするのは現実的には難しそうですが、両方のAPIを使って勝手にコラボ作品を作るのはマッシュアッパーの自由なので、ある意味現実的かも。

すごく熱くて楽しい一日でした。
位置を切り口とするサービス、めちゃめちゃホットです。個人的な感想ですが、2007年から2008年にかけてOSGeoができてGIS関連でもオープンソースが使える／普及するようになり、
GoogleMapsAPI、Yahoo地図API、GoogleEarth、VirtualEarth、携帯電話のGPS化、IPから位置情報の逆引き、PlaceEngineなどGPS以外の手段、などインフラ面がとても充実しました。
2007～2008年は位置情報マーケットが爆発すると言われていましたが、なかなか、まだでした。
なぜか？。昨日応えが分かりました。人間がついていっていなかったのではないか、と。
ここにきて、それを作る／使う人間の側の熱がかなり上がってきたように感じます。インターネットやメールなどの「ツール」が出揃いかけたばかりの「IT業界」みたいな感覚。
位置情報関連ビジネスのマーケット、今度こそ爆発しぞうです。

楽しいなあ。
ロカポは会社としてはあまり儲かっていないですが、この時代にこの業界に居合わせていることはとても幸せだと思います。

GIS Development 6月号記事の日本語訳

noreply@blogger.com (Nao) — Tue, 01 Jul 2008 05:44:00 +0000

先日お知らせした GIS Development 2008 June Issue の記事、
「GIS Data Compression and its need for LBS」
の日本語訳を用意しました。

こちらのURLからダウンロードできます。
http://www.locaport.com/docs/gisdev2008jun40Japan.pdf

注意：
（本記事はGIS Development Magazine 誌 2008 June Issueに掲載された記事「GIS Data Compression and its need for LBS」の筆者による日本語訳です。）

ロカポ上田の執筆記事が海外のGIS専門誌に掲載されました

noreply@blogger.com (Nao) — Thu, 26 Jun 2008 00:49:00 +0000

アジアからヨーロッパ、アメリカにかけて、メジャーなGIS系カンファレンスで販売されている雑誌「GIS Development 2008 June Issue」に、弊社代表の上田が執筆した記事「GIS Data Compression and its need for LBS (訳：GIS
データ圧縮とLBSにおけるそのニーズ)」が掲載されました。
英語圏の雑誌ですが、日本人の書いた文章です。とっても読みやすいのでぜひ読んでください。

位置情報圧縮・可搬化技術 LocaPorter （英語圏では LocaPort の名称）のプレスリリースの後、GIS Development編集部から記事執筆の依頼があり、書いていたものです。バックナンバーをみると4月号ではオートデスクのGeoff Zeissさん（OSGeo財団日本支部設立記念カンファレンスにきていたあのZeissさん！）など超大物の記事もあったので、採用されるかどうかドキドキだったのですが、なんとか無事採用されました。

英語圏の人に読まれるので、以前このブログでもご紹介した英語編集サービス「Edit Avenue」で技術系文章に強そうなハーバード卒のエディターを探し出して添削・編集してもらいました。記事の内容の良し悪しは変わりませんが（苦笑）、英語の文章としてはほぼ完璧になるもんですね。強い味方です。

位置情報コード「ロカポ」と位置情報圧縮技術「ロカポーター」の売上の一部を災害救援基金へ寄付することにしました。

noreply@blogger.com (Nao) — Thu, 15 May 2008 02:52:00 +0000

プレスリリースでも発表しましたが、「ロカポ」「ロカポーター」の売上の一部を災害の援助、特に捜索や救援などの初期活動に継続的に寄付することに決定しました。

もともとロケージング社は海や山のレジャー向けの救難信号サービスをやろうとしていました。その過程で、緯度経度を電話や無線でしか伝えられない場合、伝え間違え、あるいは伝達途中で伝言ゲームになって別の場所に救助が行ってしまうと助からない、間違えやすい緯度経度よりも確実に場所を伝達できるコードはないか、ということでロカポの開発がスタートした経緯がありました。ですので、災害、遭難、漂流などの場面ではロカポが今後社会の役に立つ可能性があり、常に情報をウォッチしています。

先日、中国・四川での地震災害の痛ましい情報が入ってきました。普段はこのような時は個人として少しばかり寄付をしています。寄付はAOLが母体になっている Network For Good というところで、クレジットカードからDonateできますし、ここから自分が思う慈善団体を選んで、場合によっては用途を指定して募金することができます。なにより、ここに載っている団体は信用できます。
いるのですが、今回寄付をしたあと、ふとロケージング社として、売上の一部を寄付することはロカポ開発の原点というか、本来目指していたものと整合するので、ロケージング社としてこういう活動に参加したほうが良いと考えました。

スターバックスでは発展途上国のコーヒー農業に支援を行っていますし、売上の一部が熱帯雨林保護に使われる自然派洗剤などもあります。もともと遭難時の救助をより的確にというところからスタートしたロカポは、やはり災害などの支援、それも特に行方不明者の捜索・救援などの初動体制に関わる団体への寄付としたいと考えました。

Network For Good のサイトはこちらです。目的を決めて寄付する（例えば今回の中国地震向けの援助）こともできますし、団体に委任することもできます。英語のサイトですが、ぜひ除いてみて、皆様、よければ少しばかりの寄付をしてみませんか。

ロカポの特許を米国、欧州にも出願しました

noreply@blogger.com (Nao) — Mon, 14 Apr 2008 00:44:00 +0000

位置情報『ロカポ』の特許を米国特許庁と欧州特許庁に出願していた手続きが終わりました。
ロカポの特許は日本国内では特許取得済み（特許第3885157号）のものです。

手続き的にはPCT（特許協力条約）という手続きに従って、PCT出願というのをやっておいたもの（これだけでは出願の権利を確保しただけで、各国に出願したことにはならない）を、希望する国ごとに出願する必要があり、審査は国ごとにおこなわれます。日本で特許を取得したものは米国では通りやすいそうですが、ヨーロッパではどうなるか分かりません。
PCT出願後は韓国やインドの特許事務所からダイレクトメールなども来ていたのですが、なにせ一国につき100万円オーダーのコストがかかるので、とりあえずのビジネス展開を考えていない（＝できない）国にまで費用が回らず、泣く泣く米国とヨーロッパ（EU）にのみ出願です。
ちなみにEUは欧州特許庁という中央機関に審査（1回で済む）してもらって、通ってからEU加盟各国の特許庁に登録する方法と、最初から各国の特許庁にダイレクトに出願して国ごとに審査してもらう方法の二つがあります。なんだかミニPCTですね。２～３カ国以上出す場合は欧州特許庁を経由したほうが結果的にコストが低いそうです。

日本の特許は自分でやりましたが、さすがに海外は専門家に依頼しました。手続きが全くわからないし、米国では専門家でないと手続きできない、というような話もどこかで聞いたことがある。
今回、ドリームゲートという起業支援団体で知的財産のアドバイザーをされている窪寺先生という米国在住の弁理士さんに依頼しました。窪寺先生には、何度もドリームゲート経由でアドバイスいただいていたので、安心して任せることができました。一番肝心な請求項のところは、ほとんど先生に作り直してもらっています！本当に親身になってやって頂きました！
でも時間が無かったので、明細書などの書類の翻訳は自分でやりました。自分で書いた日本語を翻訳するので簡単だろうと思っていましたが、これが結構きつい！

国内特許との一番の違いは、、、やはりコスト。特に欧州は高い！資金繰りが、、、、、！

でもこれを機会に、海外のマーケットに積極的に出て行きたいと考えています。
なにより、日本国内でこれだけ地図や位置情報の周りに楽しい人達が集まっているのだから、その輪を海外に広げるともっと面白い人達と出会えるのでは、とそっちの方がわくわくします。

海外の地図や位置情報関係の面白い人がいたらご紹介頂けると嬉しいです。

ロカポーターのしくみ（５）

noreply@blogger.com (Nao) — Wed, 20 Feb 2008 10:42:00 +0000

５．可変精度の例

前回のデータの途中部分、電車の駅の部分は、駅であることが分かれば良いので200mほどの精度でも十分でしょう。この例では手を抜いて本当に駅だけですが、途中経路の形をもう少しこまかく（たとえば高速道路のカタチで）取りたいというような場合、重要度の低い部分を非可逆圧縮にして精度を落とすことで、もう少し圧縮できるようになります。

駅の部分だけ２００mの精度（４桁にコード化したもの）にしてみましょう。

ここで、青字にしたところが、精度を下げたところと、元に戻した（上げた）ところです。
ともに「_」（アンダースコア）が精度変更のサインになります。コードがアンダースコアで終わる場合は精度を下げる（桁を減らす）記号、反対にアンダースコアのあとコードが続く場合は、これまでの桁数にプラスしてアンダースコア以下の桁数を増やすという記号となります。
ここで、アンダースコア直前の文字は、全データと同じであっても省略しないことに注意してください。これにより「アンダースコアから始まる省略データは存在し得ない」というルールができますので、連結時にコードの境界にアンダースコアがある場合（例 AAAA_bbbb）、そのアンダースコアは前のデータに属していることが明確なので、例では（ＡＡＡＡ＿と bbbb）に分離します。（AAAAと _bbbb にはなりません）
詳細はロカポーターのサイトからダウンロードできる仕様書ご覧ください。

これによって、データがさらに圧縮できる場合があります。
この元データの例では、対象となるデータ数が少ないので、ほとんど変わりませんが、少しだけ短くなってきます。

可変精度前（データ部分のみ）
RZHBZwuimjCAjBZmAKnKrGZWqSrRtIoSABWSeyuYCjzELOkfDIBAxcdzuJEAhpNiyGCjqITluWwWxUmaTlz

可変精度適用後（データ部分のみ）
RZHBZwuimjCAjBZmAKnKrGZWqSrRtZ_m_SABWeyYjELkDIBxcdzJEhE_Ni_yGCjqITluWwWxUmaTlz

以上がロカポーターの基本的な仕組みになります。

次回から、ロカポーターがどのような用途に使えるのか、いろいろ検討していきたいと思います。

ロカポーターのしくみ（４）

noreply@blogger.com (Nao) — Tue, 19 Feb 2008 06:53:00 +0000

４．実際の圧縮の例

例として、奈良県香芝市にあるロケージング本社から渋谷にあるゴーガさんへのルートを圧縮してみます。
元データ

緯度経度をそれぞれコード化すると、次のようになります。コード化の詳細は、別に機会に解説しますが、ここではとりあえず6文字の固定長文字列になることだけ頭においてください。このコードの精度はおよそ1mです。（コード化の手順はロカポーターの仕様書に記述してあります。）

圧縮して、接続する工程は次のようになります。
赤字で示してあるのは圧縮される部分です。

右端の合成値をそのまま接続し、以下のようになります。これが圧縮したデータの部分です。
RZHBZCwuimjfCAEhBZJmaAKIndDreGZWHqcSJriRFtaIDodSABWSDeyuiYCBjzcELOAkfgDIBAJxcdzugJEAHhpdNCiybGCEjqdITAlufWBwgCxiUImadTDlzh

ロカポーターのフォーマット規格は以下のようになっており、圧縮したデータ以外にも、ヘッダ、データセットのデータ種情報とターミネータを付けることが必要です。

● ヘッダの作成
ロカポーターのバージョンは「1.0」なので、整数部分は「1」です。
小数点以下の部分は、下記表にしたがって数字を英文字に置換します。少数以下は「0」なので「A」となります。この両方をつなげて「1A」となります。この変換は次の対応表を使います。

カスタムコードは使用しないので省略します。したがって、ヘッダは「1A」となります。

● データセットのデータ種類
今回のデータは「経路」ですので、2進法で[01]
高度、日時、時刻、カスタムIDとも不使用なので2進法で[0000]
→［010000](2進法) = 16(10進法) = [g]
2進数6ビットから文字への変換は以下の表を使います。

よって、データ種類は「g」となります。

データセットのターミネータ
最後のデータの省略しない表記は「SDJITDxcdlzh」となるので、これをターミネータとします。

これらをまとめると
[ヘッダ][ピリオド][データ種類][データ][ターミネータ]
となるので
「1A.gRZHBZCwuimjfCAEhBZJmaAKIndDreGZWHqcSJriRFtaIDodSABWS
DeyuiYCBjzcELOAkfgDIBAJxcdzugJEAHhpdNCiybGCEjqdITAlufWBwgCxi
UImadTDlzhSDJITDxcdlzh」

がロカポーターとなります。
QRコードにするとこうです。

もし、道案内などの目的で、精度が8m程度でよければ、コード化の際に5桁の固定長文字列になり、次のようになります。

データの圧縮工程は以下のようになります。

右端の列を連結すると圧縮データになります。左の緯度の表で「K」と「W」が強調されている箇所があります。これは、データが前のデータと全く同じ場合ですが、空文字列にしてしまうとデータの再分離ができなくなるので、緯度経度データの場合、全く前のデータと値が同じ場合でも1文字残す仕様になっています。

圧縮データRZHBZwuimjCAjBZmAKnKrGZWqSrRtIoSABWSeyuYCjzELOkfDIBAxcdzuJEhpNiyGCjqITluWwWxUmaTlz

ターミネータ
SDJITxcdlz

ロカポーター
「1A.gRZHBZwuimjCAjBZmAKnKrGZWqSrRtIoSABWSeyuYCjzELOkfDIBAxcdz
uJEhpNiyGCjqITluWwWxUmaTlzSDJITxcdlz」

QRコードにするとこうなります。

次回は、このデータの途中部分、電車の駅は200mほどの精度でもいいや、という場合の例です。
重要度の低い部分を非可逆圧縮にして精度を落とすことで、もう少し圧縮できるようになります。

ロカポーターのしくみ（３）

noreply@blogger.com (Nao) — Sat, 16 Feb 2008 15:46:00 +0000

３．データ途中の精度変更

高度を考えて見てください。仮にデータが1メートル単位として、地上付近では1メートル精度のデータが欲しい。でも飛行機で上空へ行けば10ｍ単位や100ｍ単位でも問題ない。このデータをどうやって混在させればよいのか。

高度　　　　欲しい精度
00001　　　　1m
00002　　　　1m
00003　　　　1m
00010　　　　10m
00020　　　　10m
00100　　　　10m
01000　　　　1000m
02000　　　　1000m
05000　　　　1000m

ロカポーターには答えがあります。
ロカポータ圧縮の前提は、「固定長文字列であること」ですので、その「固定長」の長さを途中で変えてしまえばいいのです。つまり、

高度　　　　欲しい精度
00001　　　　1m
00002　　　　1m
00003　　　　1m

0001(0)　　　10m
0002(0)　　　10m
0010(0)　　　10m

01(000)　　　1000m
02(000)　　　1000m
05(000)　　　1000m

の３つのセットに分けます。括弧の中は精度を落とせば不要となるデータです。
ところが、単に括弧の中を省略すれだけでは、不十分です。例えば、1000m精度のつもりの「01」が5桁の固定長と思われて「***01」と解釈されてしまいます。
そこで、精度を落とす記号を導入します。

高度　　　　欲しい精度
00001　　　　1m
00002　　　　1m
00003　　　　1m

0001_　　　　10m　<-　固定長5桁をこのデータ以降、1桁落として
　　　　　　　　　　　　　　　（アンダースコアが1つ）固定長4桁に変更
0002　　　　　10m
0003　　　　　10m

01__　　　　　100m　<-　固定長4桁をこのデータ以降、2桁落として
　　　　　　　　　　　　　　　　（アンダースコアが2つ）固定長2桁に変更
02　　　　　　100m
05　　　　　　100m

省略すると
00001　　　　　00001
00002　　　　　　　2
00003　　　　　　　3
0001_　　　　　　1_
0002　　　　　　　2
0003　　　　　　　3
01__　　　　　　1__
02 　　　　　　2
05　　　　　　　5

仮にこれらのデータをカンマ区切りでつなげてみるとこうなります。
（実際はカンマの部分には緯度経度など他のデータが入り込むことになります。）

00001,2,3,1_,2,3,1__,2,5

ちなみに可変精度を使わないと

00001,2,3,10,20,30,100,200,300

となります。

逆に精度を高めていくには、固定長の長さを増やします。
これにもアンダースコアを使いますが、現データの後に、アンダースコア＋増加するデータを加えます。

高度　　　　欲しい精度
05000　　　1000m
02000　　　1000m
01000　　　1000m
00100　　　10m
00020　　　10m
00010　　　10m
00003　　　1m
00002　　　1m
00001　　　1m

上記のデータは精度を変更すると、次のようになる。

高度　　　　欲しい精度
05　　　　　1000m
02　　　　　1000m
01　　　　　1000m
00_10　　　　10m　　<-　固定長２桁をこのデータ以降、２桁増やして
　　　　　　　　　　　　（アンダースコアの後の値が２つ）固定長4桁に変更
0002　　　　　10m
0001　　　　　10m
0000_3　　　　1m　　<-　固定長４桁をこのデータ以降、１桁増やして
　　　　　　　　　　　　（アンダースコアの後の値が１つ）固定長5桁に変更
00002　　　　　1m
00001　　　　　1m

圧縮すると次のようになる。

05　　　　　　　05
02　　　　　　　 2
01　　　　　　　 1
00_10　　　　　　0_10
0002　　　　　　　 02
0001　　　　　　　　1
0000_3　　　　　　　0_3
00002　　　　　　　　 2
00001　　　　　　　　 1

カンマ区切りでつなげてみるとこうなります。
（実際はカンマの部分には緯度経度など他のデータが入り込むことになります。）

05,2,1,0_10,02,1,0_3,2,1

ちなみに可変精度を使わないと

05000,2000,1000,0100,020,10,03,2,1

となります。

圧縮のアイデアは、このように高度のデータについて考えている時に出てきました。
当初は対数を使って、地上付近を密に、上空を粗くするコード体系を用意していたのですが、精度を可変にすることで、1番目のデータのみフル精度が必要であり、あとは好きな桁に落とせば良いことから、もっとも扱いやすい10進法のまま高度を扱うことにしました。

以上の
・固定長データの圧縮
・不定長データの接続
・精度記号によるデータの接続

が基本的なロカポーターの実装に必要なロジックとなります。

続く

ロカポーターのしくみ（２）

noreply@blogger.com (Nao) — Fri, 15 Feb 2008 23:21:00 +0000

２．圧縮したデータ群の接続方法

ロカポータ圧縮で圧縮した各データは、可変長（というか不定長）のデータの羅列となります。

データが接頭符号であれば、そのまま接続できますし、接尾符号でデータの区切りが分かる場合もそのまま接続できます。

接頭符号など、情報圧縮全般についてはここが詳しい！

情報と通信のハイパーテキスト（詳しい！）

しかし、接頭符号でも接尾符号でもないデータをそのまま接続すると、今度分離しようとした時に、どこで分離したらよいか分からず、一意にデータを復元できなくなる恐れがあります。

そのばあい、区切り文字を使うこともできますが、仮にデータが１００個あれば区切り文字が1文字としても99文字余分に必要になってしまいます。なんだかもったいない。。。

二進数であれば、このようなデータを接続するには（各データの値が小さい場合は）ワイル(weyl)符号化、ガンマ(γ)符号化、(δ)デルタ符号化、などの方法が良く使われ、これらの符号化により接頭符号化するものです。よく考えられていますね！

ワイル符号化
　０　　　　　　　　　表現不可
　１～４　　　　　　　0xx
　５～８　　　　　　　10xxx
　９～１６　　　　　　110xxxx
　１７～３２　　　　　1110xxxxx
　３３～６４　　　　　11110xxxxxx
　６５～１２８　　　　111110xxxxxxx
　１２９～２５６　　　1111110xxxxxxxx
：
xxxの部分に数値を2進数で表現したものが入る
（出展：「圧縮アルゴリズム　符号化の原理とC言語による実装」昌達Ｋ’ｚ著　ソフトバンクパブリッシング）

ガンマ符号化
デルタ符号化
については、下記サイトの説明が良く分かります。
　　　　参考
　　　　http://codezine.jp/a/article/aid/475.aspx
　　　　CodeZine：δ符号によるデータ領域の節約（CODEC, δ符号, データ圧縮）

さて、ロカポーターでは二進数での処理はせず、文字列で圧縮しているので、文字列ベースでもう少し簡単なものは出来ないか、と考えたのが以下のロカポーターの方式です。

とても単純なアイデアですが、せっかくデータが緯度、経度、高度・・・とあるのでそれぞれを全く違う種類の文字で並べれば人間が目で見ても区切りがすぐわかる。

緯度　　　　　　　　　　　　　　　　経度
５桁固定　　　ロカポータ　　　５桁固定　　　ロカポータ
10030 　　　　10030 　　　　　　　20013 　　　　20012　
10028 　　　　　　28 　　　　　　　20035 　　　　　　　35
10022 　　　　　　　2 　　　　　　　20135 　　　　　　135
10019 　　　　　　19 　　　　　　　20135 　　　　　　(空)→必ず1文字は残すルールにして[5]とする
09998 　　　　09998 　　　　　　　20029 　　　　　　　29
09997 　　　　　　　7 　　　　　　　20025 　　　　　　　　5

とします。ここで緯度データの方を 0->A, 1->B, 2->C,,,9->J というように単純に文字を置換します。

緯度　　　　　　　　　　　　　　　　　経度
５桁固定　　　ロカポータ　　　　　５桁固定　　　　ロカポータ
10030 　　　　BAADA 　　　　　　　20013 　　　　　20012
10028 　　　　　　　　CI　　　　　　　20035　　　　　　　 35
10022 　　　　　　　　C 　　　　　　　20135 　　　　　　　135
10019 　　　　　　　　BJ 　　　　　　　20135 　　　　　　　　5
09998 　　　　　　AJJJI 　　　　　　　20029 　　　　　　　29
09997 　　　　　　　　　H 　　　　　　　20025 　　　　　　　 5

で、緯度、経度、の順に並べる

BAADA 20012 CI 35 C 135 BJ 5 AJJJI 29 H 5

先ほど、全く同じデータの際でも必ず1文字は残すルールとしたので、このまま接続しても、文字種によってデータの境界が明白なので、区切り文字などを使用しなくても、そのまま接続してＯＫ

BAADA20012CI35C135BJ5AJJJI29H5

できあがり。

分離するときは、文字か数字かで単純に分ける。手作業でもできる！

BAADA 20012 CI 35 C 135 BJ 5 AJJJI 29 H 5

はい、もとどおりです。

なんと単純な仕組みですが、これでも「差分をとって、二進数にして、ガンマ符号にして、最後のホフマン符号で圧縮して、6ビットづつ64進法の文字に戻す」とやる場合と比べて、2倍も差はないです。2倍というのは適当な言い方ですが、仮に１００００文字の元データをギュウギュウに圧縮して１０００文字とすると、ロカポーター圧縮のような簡易形式でも、たいてい２０００文字以内には収まる、という意味です。

ちなみにこの例では、データの種類ごとに使う文字の種類を変えたが、要するにデータの最後の文字と、次のデータの（どこになるかわからない）先頭部分とが違う文字であればＯＫです。ですので、たとえば、各データを

ＡＡＡＡ０（Ａのところは26進法、０のところは10進法、全部で０～４５６９７５９まで）
というロカポのような記述を使うと、最後が数字ひとつとわかっているので

ＡＡ０ＡＡ０　→ （ＡＡ）ＡＡ０と（ＡＡ）ＡＡ０
ＡＡＡ０００ → 　（Ａ）ＡＡＡ０と（ＡＡＡＡ）０と（ＡＡＡＡ）０

のように、問題なくデータを再分離可能です。

ロカポータでは、この両方の方式を組み合わせています。緯度経度には前者の方式をベースにしたもの、高度や日時などの付加データには後者の方式をベースにしたもの使用しています。

次回は、ロカポーターの目玉である、データ途中の精度変更です。

なお、ご質問等があれば、このブログに投稿頂くか、ロケージングまでお問い合わせください。

それとロカポーターのホームページ（突貫で作ったので、まだ１ページモノですが・・・）からロカポーターの仕様書をダウンロードできるようになっていますので、どうぞご利用ください。

ロカポーターのしくみ（１）

noreply@blogger.com (Nao) — Fri, 15 Feb 2008 01:26:00 +0000

これから、ロカポーターによる位置情報圧縮の基本的な仕組みを紹介していくことにします。

１．ロカポータ圧縮技術のもっとも基本的な考え方
まず、データはデータ種ごとに、すべて固定長の文字列データにします。

例：5桁（5文字）固定のデータにする場合

元データ５桁固定
10030 10030
10028 10028
10022 10022
10019 10019
9998 09998
9997 09997

通常、このような数値のデータで、データ値が近いデータ群の圧縮には、差分形式がよく用いられます。

元データ５桁固定差分
10030 　　10030 　N/A
10028 　　10028 　-2
10022 　　10022 　-6
10019 　　10019 　-3
9998　　　09998 　-19
9997 　　 09997 　-1

ロカポーターでは、差分ではなく、同じ桁を比較して、『文字列の違う箇所』を記述します。
ただし、比較は左側から行い、違う箇所より右は同じ値の場合すべて記述します。

元データ５桁固定ロカポータ方式
10030 　　10030 　　10030
10028 　　10028 　　　　　28
10022 　　10022 　　　　　 2
10019 　　10019 　　　　　19
9998 　　　09998 　　09998
9997 　　　09997 　　　　　7
赤字の桁は直前のデータと同じなので、省略する

ちなみにデコードは、上から順に足りない桁を借りてきて埋めるだけ。
固定長と決まっているので、たとえば5桁固定長のところ3桁しかなければ、上位2桁が前のデータと同じ（冗長）と判断する。

ロカポータ
10030　10030
　　28　10028 ->10028
　　　2　　　　　　　10022 ->10022
　　19　　　　　　　　　　　　　10019 ->10019
09998　　　　　　　　　　　　　　　　　　09998 ->09998
　　　7　　　　　　　　　　　　　　　　　　　　　　　　09997

赤字の桁は、足りないので直前のデータから借りてきて補完した部分。復元したデータは、次のデータの補完の基準となる。

差分方式との違うは、

差分方式はプラスマイナスが発生するので、（マイナスの場合は）符号用に1文字必要となること。二進数ではデータごとに1ビットづつ余分に必要となることがあります。ロカポータ方式では、マイナス値は発生しないので、符号処理が不要です。
対象が数値ではなく文字列でも、数値演算の必要がなく、文字列の比較のみの簡単な処理で実現できます。
上記データの＃１、＃４のように、圧縮したデータの中に、生のデータを挿入してもまったく処理が破綻しません。

差分方式の符号処理の場合、2進数なら符号の為に1ビット確保する必要があります。
たとえば固定長データのとりうる値が０～２５５としましょう。２つのデータの差分のとりうる値は-255～+255ので、510種類の差分値を表す必要があり、9ビットの差分表現領域が必要です。これは元データの255=８ビットから符号の分の桁が増えるためです。
ただし、うまいやり方もあります。
現在の値が１００とすれば、次のデータの差分は-100～+155までに限定されます。これは幅が255なので、実質8ビットに抑えられるちう方法もあります。この場合、復号には差分値を足して、255をオーバーした分はマイナス扱いにするなど、一工夫必要です。
ロカポーターの場合は、何の符号制御も必要なく、ただ文字比較をするだけです！

最後の生データの挿入ですが、差分方式だろうとロカポータ方式だろうと、基準とする点に誤差があれば、その誤差は以後のデータに順に引き継がれてしまいます。ですので、時々生データを使い、その間を差分データ等で埋めることになります。ロカポータだと、任意の場所に生データを埋め込むことが出来、しかも生データと圧縮データの違いはデータ長がフルの固定長あるか、それより短いかという違いのみです。
それによって前後の処理が変わることは全く無く、全データを同じアルゴリズムで処理できます。差分方式では、生データか、差分データかという区別するための情報を各データ毎に付加する必要があり、ロカポータではその分、節約できます。

元データ　５桁固定　ロカポータ方式
10030 　　　10030 　　　10030 <-生データ（先頭は必ず生データ））
10028 　　　10028 　　　　　　28 <-圧縮データ
10022 　　　10022 　　　10022 <-生データ（意図的に挿入）
10019 　　　10019 　　　　　　19 <-圧縮データ
　9998 　　　09998 　　　09998 <-圧縮データ（結果的に生データと同じ）
　9997 　　　09997 　　　　　　7 <-圧縮データ

この方式のデメリットは、たとえば9999と10000のような桁上がり付近のデータ同士の場合、差分なら１で済むところ10000と大きな表現になってしまうことです。

経路情報やエリア情報は、構成する各点の値が少しづつ変化すると考えられるため、単なる数値や数値を表すＮ進法文字列表現のような、左側に上位桁情報が、右側に下位桁情報がくるような（狭義の単調増加関数である）固定長データを利用すると、左側の桁が同じ値となって省略できる可能性が非常に高くなります。
反面、縦横の座標を基にしたような、メッシュコードなどの文字列では、必ずしも上位桁が左側一方（あるいは右側一方）に偏る可能性が少ないため、この方式による圧縮の効果は少なくなります。

ちなみに、現在N進法でM桁あるとすると、差分を使うと最大M桁の可能性があるのと、符号に１桁使うので、ひとつのデータ当たり最大 log2(Nの(M+1)乗)の情報量となります。ロカポーター方式では桁数は変わらない代わりに同じ場合は空白を使うのでN+1進法のM桁となり、最大 lon2((N+1)のM乗)の情報量となります。どちらがより有利かは N^(M+1) と　(N+1)^M　の大小関係によりますが、実際のデータによって結果は大きく変わります。

計算してみると、元が2進法の場合、ロカポータ方式のメリットのある可能性は非常に少ないです。ただ、元が10進法などNの値が大きい場合、ロカポータ方式が有効になる場合があります。

次回は、この圧縮したデータ群をどうやってまとめるかについてです。

続く

位置情報圧縮・可搬化技術『LocaPorter（ロカポーター）』発売開始しました

noreply@blogger.com (Nao) — Wed, 13 Feb 2008 10:27:00 +0000

大変お待たせいたしました。
スケジュールが延び延びになっていました『ロカポーター』の発売を、バレンタインデー前日の本日２００８年２月１３日に開始いたしました。

とりあえず、仕様バージョン１．１ですが、皆さんのご意見を取り入れて、どんどん使いやすいものに変えていきたいと思っています。

よろしければロカポーターのサイトから「ロカポーター仕様書」をご請求ください。

これから、ロカポーターのアルゴリズムを、このブログでも分かり易く解説していきたいと思います。

今後は「位置情報ロカポ」と共に「ロカポーター」も、どうぞよろしくお願いいたします。

ロケージング
代表取締役
上田直生

ロカポーター誕生の記録（８）最終回

noreply@blogger.com (Nao) — Wed, 06 Feb 2008 10:03:00 +0000

８．「LocaPorter」名前の由来

開発の経緯の記録の最後に、ロカポーターの名前の由来を残しておきたいと思います。

最初、「ロカポ圧縮」というベタな名前だったこの技術、位置情報系サービス間のパラメータとして使ってほしい、ということでジオメディア２００８新年会では「LocaParam」という名前でご紹介させて頂きました。

ところが、LocaPointおよび Locazing（位置情報ロカポで知られてますが、実は「ロケージング」という会社名なんです。）の名付け親でもあるネーミング・コンサルタント Graeme Tickins氏に聞いてみたところ、Paramというのがいまいちしっくりこないとのこと。どうせならParameterの後半のmeterをとって「Locameter」とか「Geometer」にしてはどうかとアドバイスをもらいました。でもgeometerってそのまんま「幾何学の数学者」だし、meterというとメートルと思ってしまいます。インチ・ヤード法の国の方はあまりイメージしないんでしょうかねぇ。
さらにマッシュアップアワードでご一緒させて頂いた、ここギコ！さん！からもロカプレスという名前候補をもらったり、同じくご一緒させて頂いたAN-NAIさんからも「ロカポ」という音がいいので残した法がいい、などいろんな方にアドバイスもらいました。難しいなあ。

いろいろ考えた末、圧縮という特性よりもやはりサービス間の連携能力にフォーカスを当てたかったので、位置情報をＬＢＳ間で持ち運ぶ、ポータブルにする、あ、これは番号ポータビリティーならぬ、
位置情報ポータビリティー！

ということで Loca/Geo ＋ Port/Porter/Portable に絞る。GeoportはMACのポート名だし却下。ネーミングコンサルタントのGraemeはLocaPortの方が短いし、Portable も Porterの意味も暗示しているからベターだ、と言ってくれたのだが、私には locaport≒local airport＝国内線しか飛んでいない空港みたいに聞こえるし、IT系の人にはそのまんま「ローカルポート」みたいに聞こえる。

Porterの方は、私が鞄好き（といってもウィンドウショッピングだけでほとんど買わないのだが）なので、吉田カバンのPorterのイメージから、本来のポーター（運ぶ人）よりもカバンという印象が強い。
そういう勝手な思い込みと、「運ぶ」ということを前面に出したかったので、最終的に『LocaPorter』に決定！

ちなみに、ここで出てきた名前、取れるものはほとんど全部ドメイン取ってしまった。。無駄なお金を使ってしまいました。

今回はどうでも良い話で失礼しました。

さて、いよいよ次回から、ロカポーターのアルゴリズムの紹介に入っていきたいと思います。
請うご期待！

ロカポーター誕生の記録（７）

noreply@blogger.com (Nao) — Tue, 29 Jan 2008 22:14:00 +0000

７．（データ途中）可変精度のアイデア

ロカポータの一番前面に出したい特徴として、精度の途中可変能力がある。
仕組みは追々説明させていただくが、これによって、いろいろな精度のデータを混在させることが可能になる。これは他の圧縮技術ではあまり見かけないが、どうでしょうか？

一番に思いつくのは、マップマッチング技術（NI-Lab. さんのサイトより）との相性。マップマッチング技術を使えば、経路情報に多少の誤差があっても、ぴったり道路に合わせて修正することが出来る。それを見越して経路情報はかなり荒い精度に落とし、情報量を減らすことができる。

同時に、出発地点、目的地、経由地点（お店）などはピンポイント情報にすることにより、精度を損なわずにデータを混ぜることができる。

たとえば、高速と一般道が平行している道路で、どちらか判別がつき難い程度に情報量を落としても、料金所の場所を経由地点としてピンポイントで表すことで、高速を利用することが表現できる。ロカポーターでは、エンコードした際にどの精度でエンコードしたかの情報も保存できるので、あとから「このデータは精度が粗いから重要度は低い」「経路の中でここだけピンポイント精度にしてあるのは、重要な場所である」というように、解釈することが可能です。

海外旅行の経路＋立ち寄ったお店、写真をとった場所、あの公園のあの銅像！などにも使えます。

保存精度を選ぶことで、データを削って効率を稼ぐ（ある意味、非可逆圧縮）ことと、本当に精度を保ちたい場所（可逆圧縮）を自由に混在させることができる。

実は、この可変精度（というか混在精度）のアイデアを思いついたのは、年が明けてから。白状してしまうと、ジオメディア２００８新年会でライトニング・トークをさせてもらうことになり、プレゼンの原稿を考えないと、、、と思っている時に急に思いついたものです。正月休みも一部返上で働いていた帰宅中の電車の中でした。

それまで、実は軽量アルゴリズムの「ロカポ圧縮Light版（現ロカポーター）」と、いろんな情報圧縮理論を組み合わせて圧縮効率を追求する「ロカポ圧縮Max版」の二本立てでいこうと思っていました。プレゼンも二本を紹介する内容でした。
でもこの可変精度ができることで、Light版の地位がいきなりアップ！。
さらに、これによって「サービス間連携ツール」としての利便性が格段にアップすることに気づく。

逆にMax版は可変精度が出来ないので、圧縮技術としては良いかもしれないが、サービス関連携にはあまりメリットがすくなさそうになり、開発を中止することにしました。それに、単なる圧縮効率の追求だけなら、頭のいい人がちょっと考えればすぐによりよい物が作れると思いますし。というわけで、可変精度で必要なところだけ可逆圧縮、どうでもいいところは非可逆圧縮にできる Light版一本でのデビュー決定！プレゼンも作り直し！

これがジオメディア２００８新年会のお披露目発表の前夜23時ごろ。そのまま徹夜でやっつけのプレゼンを作って、東京へ移動！なんと余裕のないスケジュール！

ライトニング・トークの後、ずっとロカポ圧縮の相談にのっていただいていたここギコ！さんから「可変精度のことは初めて聞きました！」と驚かれましたが、それもそのはず。思いついてからほんの数日しか経ってないのですから。。。。

実際の利用場面においては、そこそこの経路情報でも結構な大きさのテキストデータになってしまうと思います。しかし、この可変精度の特性と、マップマッチングを前提にしたデータ量の間引きの組み合わせによって、ロカポーターは位置情報ポータビリティーの現実的な手段になると確信しています。

続く。

ロカポーター誕生の記録（６）

noreply@blogger.com (Nao) — Tue, 29 Jan 2008 21:59:00 +0000

６．位置情報のポータビリティー

ヒアリングで出てきた「他社と連携する」「経路(エリア)丸ごと渡す」という二点。
このジャンルならロカポ圧縮を活かせる。いや、活かせるどころか、

業界のパラダイムを１８０度変えてしまう可能性がある！

とおもいました。これは、単なる圧縮ツールじゃない。LBS/GISサービス間の複雑な連携を可能にするプラットフォームなんだ！

今まではワンストップサービスの大手地図サービスサイトがユーザーを引きつけていました。それは自社内でしかデータの流用が効かなかったので、必然的に総合サービスを提供できるのは体力のある巨人だけでした。でもITの流れをみてみると、ワンストップサービスのAll-In-Onポータルがもてはやされた時代は過ぎ、いまや特化戦略が必須です。

位置ベース・サービスでも各機能に特化した位置情報ベンチャー同士が有機的に連携して、総合的なサービスを作る。あるいは、各ベンチャーを部品として、アマチュアが複雑なマッシュアップを作る。そのためには、複雑な位置情報を簡単に流通させるプラットフォームが必要だ。

いわば、サイトで扱う情報・扱った情報の『位置情報のポータビリティー』。

つまり、業者やサービスを問わず自由に位置情報データを流通できるかどうか。
ロカポーターなら単なるテキスト。十分通用する。

これで特化型位置情報ベンチャーの時代が来る。ベンチャーは連携と前提に最小限のリソースでビジネスを立ち上げることができる。All-In-Oneの巨人の時代は廃れていく。少し前、IT業界に起こったパラダイムシフトが、LBS/GIS業界にも起ころうとしている。これでカーナビ＋αからなかなか抜け出せなかったLBS/GIS業界に革命を起こすよう位置情報ベンチャーが出てくるきっかけになるかもしれない。

その起爆剤というか、触媒というか、そういう部分に貢献できると思うと、なんだかとてもうれしい。
これまで『位置情報ロカポ』の普及活動をやってきたが、社会に対して、今すぐ貢献できるのはロカポよりもロカポーターかもしれない。そんな気がしています。

ところで、2/4現在、ロカポータ発売開始予定が準備が遅れており、2/8に延期させて頂きました。大変ご迷惑をおかけしております。

ロカポーターの実際のアルゴリズムについてもこのブログで徐々にご紹介させて頂きますが、次回は2/8とさせていただきます。

ロカポーター誕生の記録（５）

noreply@blogger.com (Nao) — Tue, 29 Jan 2008 21:50:00 +0000

5. 使い道は？？？ヒアリング道中記

2007/10/11にアルプスラボさんに伺って、ロカポ圧縮について相談させて頂きました。
それで、それまでロカポ圧縮が実際のところ役に立つのかどうか、疑問に思っていた大きな点を改めて再認識。それは

「データベースにさえアクセスできれば、キー情報だけ持っていればいいので、圧縮する必要はない」

という点。
ＱＲコードにしてもキー情報だけ掲載していればよいので、そこに経路情報がそのまま載っているメリットは、パケット代節約とか、通信速向上程度にしかならず、本質的なメリットではない。
だから、圧縮が役に立つのは、電波の入らない地下街（今時そんなところあるのか？）とか、登山中の山奥とか。

2007/10/12にリクルート・メディアテクノロジー・ラボを訪問。フナミタカオさんにお会いして、ロカポ圧縮の利用アイデアを聞いていただいた。
その中に「経路検索サイトなどで検索した結果を、そのままホットペッパーに持ってきて、経路沿いのレストランのみを検索する」みたいなアイデアがあったのですが、これに対してフナミさんが仰るには「物理的にデータベースにアクセスできる環境でも、他社のデータベースはアクセスできないのと同じ。企業をまたがった連携には有効ではないか」というコメントを頂いた。
さすがフナミタカオさん！
このコメントが以後ずっと頭の中に残っていました。(あとで考えると、これがアイデアの起爆剤となりました。フナミさん、どうもありがとう！)

2007/12/12
フリーマップレット「マップサーファー」の件で、大手地図系システム会社さんを訪問。
余談時間にロカポ圧縮を紹介。「経路情報をそのまま渡せる」といった時に技術の方が「それならあれもできる、あれもできる、、、」といろいろ考えておられる様子。これまでＬＢＳサービスでは「経路をまるごと渡す」という選択肢は少なかったのかもしれない。
それが「もし経路ごと渡すことが可能ならば、、、」というお題目があれば、技術者のクリエイティビティを刺激するのでしょう。

この「他社と連携する」「経路(エリア)丸ごと渡す」という二点を、ずっとずっと頭に引っかかっていました。年末にいろいろな仕事が重なり、ものすごくハードだったのですが、そのフラフラの頭のときに突然ひらめきました！

６．に続く

ロカポーター誕生の記録（４）

noreply@blogger.com (Nao) — Tue, 29 Jan 2008 21:44:00 +0000

４．既存の圧縮技術

ここで、先行事例で見つけた面白いもの、を紹介します。
松下電器産業の足立晋哉さんというITS分野らしい（？）方の発明。

（特許公開２００７－１０４５４３『緯度経度データ列の圧縮装置及び圧縮方法』
※私の説明はアバウトなので、詳しくは特許電子図書館でこの文献を見てください）

基本的には道路を記述する方法です。

同じように基点と差分を記録していく方式なのだが、通常は
「緯度の変化量」
「経度の変化量」
とするところを

「移動距離は道路上で等距離となる点に振りなおして」
「角度の変化量の変化量」
と一種のベクトルに変換したデータで経路というか道路を記録する。
でなにか凄いかというと、まず移動距離は等距離で一定なので省略できる。これで1次元分のデータ省略（すごーーーい！）
で、もっとすごいのが「角度の変化量の変化量」のところ。
正確には角度の変化量の予測値と実測地の差分だそうですが。
簡単にいうと、一定のRのカーブを曲がっている時は、各点間を結ぶ線がなす角度は常に一定となるので、次の予測値と実測値の差はほとんどゼロとなる。
さらに、右左折した場合、差分はほぼ90度となる。
経路に一定曲率の道路（直線を含む）と９０度の交差点が多いばあい、経路をトータルすると、差分データの分布は0度と90度の周りにかなり集中すると考えられる。これだけデータの偏りがあれば、ホフマン符号などその他の情報圧縮でかなり圧縮できる。

この人天才だなあ。。。一度お会いしたいです。
12月にITSの学会でこの人の発表があったのですが、予定があっていけなかった。残念！

ロカポーター誕生の記録（３）

noreply@blogger.com (Nao) — Tue, 29 Jan 2008 21:42:00 +0000

３．試行錯誤と勉強のやり直し！

その後、どうせ圧縮するなら敢えてロカポを使う必要もないし、いろいろなフォーマットの位置情報コードを作って、それぞれで圧縮効果とか、可逆性が保障されているかを検討しながら試行錯誤することにしました。

同時に、本格的な情報圧縮技術について、昔やった記憶があいまいなので再度勉強開始。ホフマン符号化、ＬＺ法、ランレングス法など。難しいなあ。。。考えた人凄ーい、と思いながら、エクセルベースで簡単なプログラムを組みつつ、いろんな経路情報を実際に符号化して、どれくらい圧縮できるかテスト。こちらはアルゴリズムが複雑怪奇でもいいから、とにかく圧縮効率だけを追及する「ロカポ圧縮ＭＡＸ」として別バージョンで出すつもりでした。

経路や領域の情報は、隣り合う点同士は値の変化が少ないので、データ同士の差分を取る方式やMPEG（画像の中の動く部分だけを検出して保存）みたいな方法が向いている。でも一般の情報圧縮は主にFAX画像や音声や映像、テキスト文書をターゲットに開発された歴史もあるので、なんとか経路や領域という地理情報特有の特徴をうまく利用した圧縮アルゴリズムができないか、いろいろ考えました。

たとえば、都道府県とか、マピオンの国獲りみたいな、ある面を複数の領域を分割したデータでは、県境などの境界にあたる部分は二つの領域で共有されている。一辺が接している二つの正方形を思い浮べて頂くとわかりやすいが、この場合接している辺の情報は、二つの正方形領域の情報にそれぞれ含まれている。両方の正方形を、４つの辺の集まりとしてバラすと、共有している辺は順番の正逆はあるかもしれないが、符号以外は同じデータ列なので、これを利用して圧縮できないか、など。
このアイデアはまだLocaPorterでは実現できていないが、領域分割のデータを圧縮するにはとても効果的かなと思っている。（ここで発表してしまったので、特許にはできないですが。笑）

こんな感じで、いろいろ考えたというよりは、エクセルでマクロとVBAでプロトタイプを作っては比較するということを繰り返しました。

４．に続く

ロカポーター誕生の記録（2）

noreply@blogger.com (Nao) — Tue, 29 Jan 2008 21:11:00 +0000

２．「doodle」でおなじみのゴーガさんとの雑談にて

2007年8月31日、ゴーガさんから「位置情報を利用するサイト間で取得したGPS情報を共有する」GISゲートウェイの企画を聞き、『これはすばらしい！』と渋谷にあるゴーガさんに飛んでいきました。以前から各社URLの緯度経度のフォーマット（ついでに測地系も！）に全く統一性がなく、連携しようにもいちいちフォーマット変換する必要がありました。私も以前からnavitoGatewayというフリーウェアやマップサーファーというガジェットを作ったりしていて、位置情報の流通という事に非常に関心があったので、二つ返事で参加させていただきました。

ロカポはコンテンツ商売ではないのと、私が元々携帯サイト系の技術が苦手なのもあって、これまで携帯サイトにはあまり関わっていませんでした。

その話の中の雑談で、ゴーガさんから携帯電話のブラウザではURLの文字数制限が厳しいものがあると聞きました。１点の位置情報なら問題ないが、４点、５点と増えてくると厳しくなってくるという話でした。

私はロカポ開発時に情報量と表示桁数の関係といろいろ調べたことがあったのですが、１メートル前後の精度で場所を表すには、緯度経度あわせて１５文字の数字が必要です。小数点や区切り文字を考えると一箇所に付き約20文字。元のサイトアドレスなどで20文字使うとすると、4箇所の情報であっという間に100文字を超えます。

そんな話をしていて、「ロカポＤＩＹマップ」というサービスで経路情報の圧縮をしていたので、その技術がありますよ、という話をしていました。

家に帰って、改めてロカポＤＩＹマップの圧縮仕様（現在のロカポ仕様Ｖｅｒ２．０では削除）を見直していて、ふと、さらに圧縮できるアイデアを思いつきました。

その時点での名前は「ロカポ圧縮」。なんとベタな名前（苦笑）

2007/9/22にリクルートでマッシュアップ･アワード応募者のパーティがあり、ここギコ!さんにロカポ圧縮のアイデアのお披露目、というか相談にのってもらいました。

３へつづく

ロカポーター誕生の記録（１）

noreply@blogger.com (Nao) — Tue, 29 Jan 2008 20:48:00 +0000

位置情報圧縮技術（LocaPorter)発表後の各方面より多数のお問合せを頂きました。どうもありがとうございました。現在ドキュメント整備など、販売の準備を進めておりますので、もうしばらくお待ち下さいませ。

それまでに順次、LocaPorter開発の歴史を記録に残しておこうと思います。

１．ロカポDIYマップ時代
2006年1月にロカポＤＩＹマップという、グーグルマップにマーカーや線を引いて、それぞブログに貼り付けられるサービスを始めました。（今やこんな機能はどこのサイトにもありますよね）
その当時はまだ数社しかそういったサービスをしていませんでした。他社さんは、（推測ですが）ユーザが作った経路情報をデータベースに入れて、キーとなる文字列のみをＵＲＬ化する方式だったのですが、ロカポでは借りているサーバーの容量が小さかったので、ユーザーさんが増えた場合、すぐに対応できなくなってしまう心配がありました。結果、ユーザーさんのデータはユーザーさんに持ってもらおう、という他力本願の思考回路となりました（笑）。
でもユーザーさんに渡せるのはＵＲＬのみ。ＵＲＬに経路情報を入れるには長すぎるし、、と考えていたとき、
「そうかロカポのフォーマットの左右非対称性を活かせば簡単に可逆圧縮できるぞ」
、、、ということでロカポをベースにした経路圧縮を作りました。

もう少し説明すると、ロカポは「文字、文字、数字」のパターンなので、「省略するのは左側のみか、右側のみのどちらか」という制限さえ設ければ
「文字、文字」－－－数字が省略されている（精度を荒くしている）
「文字、数字」－－－左の文字が省略されている（上位桁の省略）
「文字」－－－－－右側の文字と数字が省略されている（精度を荒くしている）
「数字」－－－－－左側の文字＋数字が省略されている（上位桁の省略）
ということが明確です。
で、ロカポはエリアコードの上位桁と、詳細情報のローカルコード下位桁に分かれているので、
エリアコードは同じことが多いので、同じ部分は省略（上位桁の省略・左側のみ）
ローカルコードは、多少精度を粗くしてもナビ用には問題ないので右側のみ省略
というようにすれば、かなり文字数を減らせる、という原理です。

これはロカポの仕様Version 1.0 には書いていたのですが、まずは素のロカポを知ってもらう上で返って邪魔となるので、現在の仕様 version 2.0では消された、いわば幻の仕様です。（その他、余談ですが、ロカポVersion 1.0 には圧縮仕様の他に、経路情報、領域情報、点のグループ、を表す仕様がありました。）

その後2年間そのままにされていましたが、このときの幻の仕様がロカポーターの卵となりました。

２へ続く。

訂正！

noreply@blogger.com (Nao) — Wed, 23 Jan 2008 01:01:00 +0000

hatenaブックマークで指摘いただきました（ご指摘感謝！）

｢｢精度１ｍで情報を取るのと､精度１０ｍで情報を取るのでは､元の精度を再現するのに必要な情報量は当たり前ですが10倍になります｡｣→ﾀﾞｳﾄ！ :-)

そのとおりです！すみません。
情報量という意味ではlog2(10) ≒3.3219倍です。（logの底は２）

で、表示上何桁必要かは、何進法を使うかで変わります。10進法なら一桁増えるだけなので、今N桁で表示しているところを、N+1桁必要となるので、表示上必要な桁数の増加は（N+1)/N 倍です。

適当なセールストークになってしまいまして、申し訳ございません（反省）。

ロカポ ブログ