ロカポ ブログ

今朝、GoogleGroupのディスカッション「Geocode@japan」でチラっとみたので、確認したところ、
GoogleMapsAPIのジオコーダーで日本（およびイギリス）の住所が再び使えるみたいです。

GoogleMaps APIのドキュメントページで提供している「公式サンプル」で確認してみたのですが、
http://www.google.com/apis/maps/documentation/geocoder.html
たしかに日本語の住所が対応になっています。
公式復活だといいですね。（作ったばかりのコントロールは無駄になりますが・・・・）

GoogleがMapsAPI V1打ち切りで対応したのをきっかけに、久々にV2の機能をいろいろ使ってみて、ロカポマップを作りました。ずっと作りたかったものがやっとできました。
http://www.locapoint.com/map/map.html

まだバグが残っていますが、ほぼ完成です。
機能としては
・キーワードや住所などで場所移動できる（GoogleローカルサーチのAPI）
・ロカポを直接入力しての場所移動
・その場所のロカポと緯度経度の表示
・ロカポ・グリッドの表示
ができます。
また、GoogleMapsAPIV2の機能を活かして、これらの機能をそれぞれ独立したコントロールに分けていますので、後々Google以外の地図APIに移植する際にも最小限の変更で済むように、なるべく気を使ってつくりました。

あとは印刷対応と（グリッドやロカポが印刷に出なかったり、、、）日付変更線またがりの処理です、、

それにしても、こんなものが素人に作れるなんて、Googleってすごいですね。。。。。

先日見つけた、GoogleMapsAPIとGooogleAJAXSearchAPIの連携、海外でもやってる人がいるみたいでした。GoogleMapsAPIユーザーが簡単にアドオンできるように、これをGoogleMapsのカスタムコントロールという形でパックした。

GlocalSearchをカスタムコントロール化しました
にも書いたが、
基本的に今あるGoogleMapやサイトのデザインに一切てを加えることなく、ファイルをインクルードして
map.IntegratedGLocalSearchControl = new　IntegratedGLocalSearchControl();
map.addControl(map.IntegratedGLocalSearchControl);
と2行書くだけで、ローカルサーチが組み込める。

デモ
http://www.locapoint.com/demo/gmaptest/glocalsearch.html

といっても、ロカポのサイトで自分が使いたいから作っただけなのだが。
でも第一作目なので、中のコードは超不恰好です。皆さんが勝手に改良してくれるのを待ってそれを使わせてもらおう！

GoogleMaps APIについているジオコーダーはアメリカの住所は緯度経度が取得できますが、日本の住所はできません。（一時期できるようになっていましたが、、、）

ところが裏ワザ発見。GoogleMaps　APIとはどうも別グループが作っているらしい Google Search API には「ローカルサーチ」という機能がついています。
で、GoogleMapsAPIと、GoogleSearchAPIのキーをそれぞれ取得して、これを連携させると、
「(住所を入力して）ローカルサーチをした結果」の「位置情報」を取得して、GoogleMapsに渡す、ということができます。これは、本件Google検索の結果と同じなので、結果的には本家GoogleMapsのジオコーダーと同じで、グローバルジオコーダーのできあがり！

裏ワザと言っても本家Googleでサンプルが公開されているのだから、別に裏じゃないですよね。でもこのサンプル、MapsのチームじゃなくてSearchAPIのチームからの情報っぽいです。
http://www.google.com/uds/samples/places.html

で、これをこのままコピペして、取得したキーに差し替えるとちゃんと動きます。

http://www.locapoint.com/searchtest.html


早速、ロカポのサイトに組み込もう！

でも、この情報が広まって、この手が使えなくなったらこまるなあ・・・・

DIYマップがやっと復旧しました。ご利用の皆様には大変ご迷惑をおかけしました事をお詫びいたします。
障害のご連絡を頂いてから3日もかかってしまいましたが、やっとほっとできます。
DIYマップで評判の悪かった「リロードすると作業中の地図が消える」もこの機会に（やっと）対処しました。常に作業中のデータをクッキーに落としているので、一旦ブラウザを閉じて再度作業を開始しても前回の最後のデータから、再スタートできます。ただし、履歴は消えてしまいますので、Undoはできません。
しばらくGoogleMaps APIを触らない間に、随分機能が増えていました。これをまたDIYマップに取り入れたいと思います。皆様からリクエストを頂いていた分も順次やっていきたいと考えてますが、とりあえずはタブ付きWindowの対応と、マーカーやラインの「ドラッグ＆ドロップ」による位置修正や削除、などが便利でしょうか。

DIYマップの障害でご迷惑をおかけしております。

DIYマップの「作るほう」「見るほう」のうち、「見るほう」が復旧しました。復旧というよりはGoogleMaps API Version2に対応しました。結果的にきれいな地図と衛星写真が付いてきました。
「作るほう」はコードが大変多くて、まだ対応中です。しばらくお待ち下さい。

今日、ロカポDIYマップのお客様から連絡があり、DIYマップが使えなくなっているとのこと。
急いで確認してみると、JavaScriptのエラーが出て動かない。
DIYマップをご利用頂いている皆様には大変ご迷惑をおかけして、申し訳ございません。

GoogleMapsAPIのグループの記事にも書いてあったが、昨日からGoogleが急にAPI V１の何かを変更したらしい。 もともと、バージョン１の「隠しコマンド」はバージョン２への上位互換は保障されないが（当たり前だ）、バージョン１を停止するならするで、突然はやめてほしい。が、考えようによっては、「正規の」バージョン１を停止する前に、「隠しコマンド」から停止すれば、正規のAPIだけを利用している利用者には迷惑をかけずに、それなりのワーニングになるという事であろうか。

・・・と思ったら、Googleから事前予告があったみたいです。気づかなかった・・・
http://googlemapsapi.blogspot.com/2006/10/revision-266-of-maps-api-v2.html
これによると、V2のAPIにもV1のインターフェースもあるから、V2を使ってね。でも隠しコマンドは知らないよ、ということらしい。。。

でも利用する側としてもなにも好き好んで隠しコマンドを使っている訳じゃなくて、当時は他に求める機能を実現する選択肢がなかったからしたのであって、まずは「この関数は●月●日で使用できなくなります。」というメッセージボックスを出す、なんてしてくれないかな・・・

Googleは早めにバージョン２にアップグレードしろと言っているのだが、DIYマップはまだ対応できていない。早急に対応しないとまずい。うーん、困った！でも早くやりますね。

ここギコ！さんでも紹介して頂きましたが、「navito:」というプロトコルを提案しようと思っています。

Mailto:XXXというハイパーリンクをクリックすれば、メーラーが開きます。またCallto:XXXというハイパーリンクをクリックすればMSNメッセンジャーやSkypeが起動します。
Mailtoの場合はメールアドレスやタイトルやCC、Calltoの場合は電話番号やSkypeIDなどを渡しますが、同様に「位置情報」をアプリケーションに渡すプロトコルがあってもいいんじゃないの？というのがNavitoです。
PCにはレジストリに登録してあげれば、Navitoプロトコルが有効になります。
Callto、Mailとと並べてレジストリのエクスポートを書くと分かりやすいと思います。

Calltoプロトコルはこう登録されています。（私のPCの場合。Skypeと関連つけられてます）

[HKEY_CLASSES_ROOT\callto]
@="Skype Protocol Handler""EditFlags"=hex:02,00,00,00"URL Protocol"=""
[HKEY_CLASSES_ROOT\callto\DefaultIcon]
@="\"C:\\Program Files\\Skype\\Phone\\Skype.exe\",-1"
[HKEY_CLASSES_ROOT\callto\shell][HKEY_CLASSES_ROOT\callto\shell\open][HKEY_CLASSES_ROOT\callto\shell\open\command]
@="\"C:\\Program Files\\Skype\\Phone\\Skype.exe\" \"/callto:%1\""

Mailtoプロトコルはこう登録されています。（私のPCの場合。Outlookと関連つけられてます）

[HKEY_CLASSES_ROOT\mailto]"EditFlags"=dword:00000002"URL
Protocol"=""@="URL:MailTo Protocol"
[HKEY_CLASSES_ROOT\mailto\DefaultIcon]
@="\"C:\\PROGRA~1\\MICROS~2\\OFFICE11\\OUTLOOK.EXE\",7"
[HKEY_CLASSES_ROOT\mailto\shell][HKEY_CLASSES_ROOT\mailto\shell\open][HKEY_CLASSES_ROOT\mailto\shell\open\command]@="\"C:\\PROGRA~1\\MICROS~2\\OFFICE11\\OUTLOOK.EXE\"
-c IPM.Note /m \"%1\""

そして、Navitoプロトコル。現在Navitoを扱うアプリケーションはもちろん存在しないので、『NavitoGateway』というアプリを作って、それに関連付けています。

[HKEY_CLASSES_ROOT\navito]
@=URL:NaviTo Protocol"
BrowserFlags"=dword:00000008"
EditFlags"=dword:00000002"
URL Protocol"=""
[HKEY_CLASSES_ROOT\navito\DefaultIcon]
@="C:\\Program Files\\NavitoGateway\\NavitoGateway.exe"
[HKEY_CLASSES_ROOT\navito\shell]
@=""
[HKEY_CLASSES_ROOT\navito\shell\open]
@=""
[HKEY_CLASSES_ROOT\navito\shell\open\command]
@="C:\\Program Files\\NavitoGateway\\NavitoGateway.exe %1"

ちなみにNavitoGatewayとは現在作成中のアプリですが、Navitoで受け取った位置情報を任意のフォーマットの緯度経度に整形して、各社MapサイトのURLに埋め込み、サイトを表示させるアプリです。
まだVB6で作った試作品しかありませんが、オプションリストでNavitoで開く地図サイトを自由に切り替えることができます。サイト以外ではGoogleEarthやWildWindも開きました。よかったら試してみてください。なお、余計なコンポーネントをインストールする必要のないよう、Exeファイル一つで完結するNavitoGatewayをただいま製作中です。

NavitoGateway（VBで作ったプロトタイプ。たぶんこれ以外にVB6ランタイムとMSXML６が必要）

ちなみにNavitoGatewayが扱えるのは、まだ以下の３つのみです。
Navito:ロカポ
Navito：緯度,経度
Navito:緯度；経度

もともと、ロカポには自動検出できるパターンがあるので、XXX@XXXとあればメルアド！というように、AAN.AAN.AAN.AANとあれば位置情報！という風にロカポを使ってもらいたくて、そのためにはMailtoならぬMaptoかNavitoみたいなものが必要だな、と思ったのがきっかけなのですが、考え始めるとNavitoは別にロカポじゃなくても全然かまわないわけで、
Navito+ロカポ
Navito+緯度経度
Navito＋住所
Navito+出発地＋目的地
Navito+経路
Navito+KMLファイルのURI
など、受け取る側のGISアプリによって好きな「位置情報」を送れるわけです。
そうなると、Navitoにはもっと大きな可能性があるように思えてきました。

現時点での地図サイトのURLは、業者情報と位置情報が不可分になっており、あえて言えばこんな感じとおもいませんか？

MicrosoftIE/http://www.locapoint.com
MozillaFirefox/http://www.locapoint.com
とか
OutlookExpress/info@locapoint.com
Thunderbird/info@locapoint.com

Navitoは地図サイトの情報と純粋な位置情報を分離する、いいきっかけになればと思ってます。

昨日、ロカポについて書いて頂いているブログを見つけました。その中に

特に複雑な変換は行っていないものの、その発想が面白い。

　AAN.AAN.AAN.AAN (A:アルファベット, N:数値)

のIP的な組み合わせで、ある地点を一意的に示そうってんですから。シンプルで、美しい。

と書いていただいていて、たいへんうれしい思いをすると共に、偶然同じ日に読んでいたダニエル・ピンク氏の「ハイ・コンセプト」という本で、美しさと実用性に関するテーマがあって、いろいろ考えさせられました。

ピンク氏によると、分析や逐次処理といった左脳的能力の相対的価値が低下する一方、全体的思考や直感的処理などの右脳的能力の価値が重要になってくる、のだそうだ。

これまで分析・戦略・ロジカルシンキングなどをトレーニングしてきて、論理的思考を一生懸命鍛えてきた反面、芸術、特に絵画に関しては「もう才能がないから」と既にあきらめてた私には、結構ショッキングな内容！。でも、内容には完璧に納得。うーん、なるほど。

その中の一つによると、これからは機能だけでなくデザインも重要とのこと。

ロカポの

AAN.AAN.AAN.AAN

というフォーマットには、『数学的』な美しさがあると密かに自負していました。、、が、数学的とか考えている時点で、これは既に左脳的思考に偏っているのかもしれない。。。。

著者が引用している家具デザイナーの言葉には

『実用的なものが美しいというのは間違っている。美しいものこそ実用的なのだ。美しさは、よりよい生活や考え方を私たちにもたらしてくれる。』

というものがある。ロカポはその意味で本当に「使う人にとって良いデザイン」なのだろうか。・・・・と妙に考えさせられました。もし本当に数学的にせよ何にせよ美しさがあるのなら、ロカポをより多くの人に知ってもらい、良い生活や考え方をもたらすようにするのが、私の使命だな、などと考えさせられる本でした。

※ここギコ！の関連記事へのコメントにも同じPOSTをしてしまいました。トラックバックが何故かうまくいかなかったので。。マルチポストで申し訳ありません。


シフト済みエリア（英語ならShifted Area Code かな？）

SD9.XC4[NA]

で[]がURIでパーセントエンコードが必要だと不便というご意見がありましたね。

URIの予約文字は :/?#[]@!$&'()*+,;=　なんでそれ以外で、、、元プログラマーなんで「シフト」という言葉のイメージから

SD9.XC4>>NA

なんていうのも考えましたが、もしXMLで使うとなると、>は予約文字なんで、やっぱり不便かな。

非予約文字だと -._~ があるので、

SA2.WU4~SK

などどうでしょう？フォーマットの美しさからすると

SA2.WU4.~SKの方が個人的に好きかな・・・

ところで、ここギコ！ねねさんの案では
>上記新エリアSD9.XC4[NA]の中で皇居の位置はBI7.FB2と表せますが、これをフルスペックのロカポにした場合は飽くまでSE0.XC4.BI7.FB2であって、SD9.XC4[NA].BI7.FB2ではないということです。

とありますが、上記の書き方をすると

SD9.XC4.~NA.BI7.FB　=> 2SE0.XC4.BI7.FB2

で左側の書き方も「あり」としたほうが柔軟性があるかもしれません。この場合、これも書き方を考えないといけませんが
SD9.XC4.~NA
の部分を「IPに対するドメイン名」のように「ロカポエリア＋シフト　に対する ロカポエリア名」みたいにすれば
SD9.XC4.~NA　を tokyostation などにすると

tokyostation.BI7.FB2　=>SD9.XC4.~NA.BI7.FB2　=> 2SE0.XC4.BI7.FB2

となりませんかね？この場合は、
「(tokyostationエリアの) BI.FB」
だけでほぼナビ完了です！あとはtokyostation　から　どうやって SD9.XC4.~NA　を引いてくるかですが、DNS（Domain Name System）ならぬ、LPANS（LocaPoint　Area Name System）みたいな、なんらかの仕組みを構築できればいいのですが。。。。どなたかいいアイデアありませんか？