2006/11/29

GlocalSearchをカスタムコントロール化しました

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

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

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

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

2006/11/25

グローバル ジオコーダー 裏ワザ

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


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

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

2006/11/14

DIYマップが復旧しました

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

2006/11/13

DIYマップ、一部復旧しました

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

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

2006/11/12

DIYマップのトラブル

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

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

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

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

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

2006/11/06

Navito:プロトコルの提案

ここギコ!さんでも紹介して頂きましたが、「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ランタイムとMSXML6が必要)

ちなみにNavitoGatewayが扱えるのは、まだ以下の3つのみです。
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は地図サイトの情報と純粋な位置情報を分離する、いいきっかけになればと思ってます。

2006/11/02

美しさと実用性

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

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

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

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

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

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

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

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

ロカポの

AAN.AAN.AAN.AAN

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

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

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

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

ロカポのエリアコードをシフトする案(2)

※ここギコ!の関連記事へのコメントにも同じ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)みたいな、なんらかの仕組みを構築できればいいのですが。。。。どなたかいいアイデアありませんか?

2006/10/30

ロカポイントのエリア定義を自由にシフトする仕様案

ロカポイントのエリア定義を自由にシフトする仕様案

ここギコ!のねねさんから、すばらしいアイデアを頂きました。
もともと、ねねさんがから頂いた「シフトして使えたら便利」というご意見に応じて、私がリプライしたアイデアを、さらに洗練して頂きました。

エリアの大きさは南北がおよそ3Km、東西は緯度によって違いますが、日本だとおよそ4.6Kmの長方形になります。
この範囲の中で、ロカポはローカルコードだけ分かれば事足りるように出来ています。さらに、ロカポの最高分解能は南北方向約45cm、東西方向は約70cmです。現在の携帯用GPSの精度でもここまで出ないので、「道案内などでそこまでの精度は要らないよ」という時には、ローカルコードの下の数字一文字は覚えなくても南北4.5m、東西7mの精度があります。そのとき、下一桁の数字の処理としては

1.無条件にゼロにしてしまう
例 RZ7.WU8.BX0.MK0
2.エリアコードの数字と同じ数字を入れて「韻」の効果でよりエリアを覚えやすくする
例 RZ7.WU8.BX7.MK8
3.ゴロや音感を考えて自分の好きな数字にしてしまうなどができます。

話が飛びましたが、要するにエリアさえ決まってしまえば、ローカルコードのアルファベット4つだけ使えば、ナビに入力することもできるし、地図上で場所を簡単に見つけることもできます。ここギコ!ねねさんによるシフト案は、所定のエリアに縛られず、ローカルコードだけで運用できるすばらしいアイデアですね。
ここギコ!の記事にコメントにあった「 [] を使うとパーセントエスケープしないといけない」というのも検討に値するご意見ですね。できるだけ多くの人のご意見を取り入れて、本当に使いやすいものができるといいと思っています。

2006/10/27

緯度経度のフォーマットってバラバラすぎませんか?

半年も書き込みがないと、もはやブログとは言えませんが(汗)、公にしておきたいことは書いておくことにします。

現在、Webサイト上のロカポを検出して、GoogleMapsなど指定したサイトへのリンクに変換するJavaScriptなどは公開(http://www.locapoint.com/jp/links.html)しているのですが、予め決めたサイトにしかリンクできないのが不便だなあと考えておりました。

そこで、一つの位置データから、地図サイトを自由に切替え、好きなサイトに飛ばすことができるアプリを開発してます。詳細はおいおい発表するとして、位置データを地図サイト各社のURLに埋めこんでいるのですが、そのフォーマットが、、、、バラバラすぎます。
・測地系は何?
・緯度と経度は別々?セット?
・セットの場合、緯度と経度のどちらか先?
・小数点付きの度、整数の度+小数点付きの分、整数の度+整数の分+少数点付きの秒、全部秒単位
・少数以下の桁数の固定か否か
・たとえば経度の度が2桁のとき、-074度とゼロで左側を埋めるか否か
・符号は常に+/-表示か、-の時のみ表示か、N・Eなど方角の記号か、大文字か小文字か、または符号なしか、

などなど。GoogleMapsだけの時はプログラムの中にハードコードしてたのですが、今度のはユーザーが自分でカスタマイズできるように考えてるので、ハードコードは不可能です。
仕方なく、独自の「位置情報フォーマット記述言語」もどきみたいなものを作って、カスタマイズに対応しています。おかげで、新しい地図サイトをリストに登録するときでも、設定用のテキストファイル をいじるだけで対応できるようになりました。

前置きが長くなってしまいましたが、みなさま、もし世の中に緯度経度フォーマット用のフォーマット記述言語があって、何かご存知であればぜひ御教授頂きたいと思っています。そういうものがあれば、すぐに採用したいのですが。
また、もしなければ、現在の「フォーマット記述言語」をいろいろ叩いて頂いて、もっと良い仕様にしたいなと思っています。

現在仮採用している緯度経度記述フォーマットの説明用文章

実際にアプリのオプションに使っているテキストファイル(XML形式)

皆様からのご意見いただければ幸いです。

追記: ここギコ!さんから緯度経度のデータ種別と、フォーマット情報は分離した方がいいというご指摘頂きました。ありがとうございます。