秋葉原から隅田川への距離とかあまり判ってなかったが、この距離ではかなりしょぼかった。
...とモブログでは書いたが、後のほうで打ち上げ箇所が複数になって、連射とかが入ってくると、一望できる分結構すごかった。

Mailogは動画もOKだったっけのテスト　→　駄目やったね。家のネットが復旧しだい後で挙げよう。

昔はこんなの見る度に足を停めていたもんだが
余裕のない人間になったもんだ
今日は待ち合わせだから聞いてるけど

【GPS情報】
http://walk.eznavi.jp/map/?datum=0&unit=0&lat=+35.41.55.53&lon=+139.46.21.21&fm=0

お待たせいたしておりました、光ケーブルの引き込み工事が本日完了いたしました！
工事完了後4日から6日で接続設定済みルータが届きますので、それで接続設定を行って下さい。
なお、VDSLとADSLは同じ周波数帯を使っていますので、同一回線上のADSLは繋がらなくなる恐れがあります。
速やかに他社ADSLサービスをご解約下さい。
それでは、ブロードバンドの世界をお楽しみ下さい！

……。
おい！
おい！
お楽しみ下さいじゃねーだろ！ 

予期せぬ、そっちの都合で工事が完了した日から突然、1週間近いネットからの孤立宣告かよ！
なんで工事完了が見えた時点で、前もって手続き→ルータ送っておいて、ユーザがすぐにでも繋げられる状況を確保してから工事を完了せんのよ？
それが無理なのだとしても、なんで前もって何時何時からどの位繋がらなくなりますので、対策してくださいとか予告できんのよ？
予告さえしてくれていたなら、携帯モデムなんかもあるんだし、普段使わないからドライバもAP情報も散逸しちゃってるものを、事前にDLしておくなり準備できていたものを。
結局、外出用のPCにモデム設定が残っていたので、そっちで繋げてドライバやAP情報DLして、俺は何とかなったけど...。
何ともやりようのない人とかで、今日重要な連絡がメールで来る事になってた人なんかもし居たらどないすんねん。
というか、その書いてよこした「他社ADSL解約」すんの1つにしたって、ネット接続できんかったら手間が輪をかけて面倒臭いぞ。

というか、それでもこっちが事前に何も聞いたりしていなかったら、同じDSL信号が1本の銅線上に乗るんだから不通期間があるのは当たり前です、仕様です、で済む話なんかもしれんけど、
逆に容易に予想できる状況だから、こっちは事前に説明会の時に、乗り換え時の不通期間について担当者に質問してるのね。
その時の担当者の返答が、乗り換え日は事前に通知させてもらうので、その日に合わせて解約手続きとってもらい、その日のうちにSo-net側の機器設定すれば、不通期間なしで乗り換えられる、というもので、
それを聞いてたからこそ安心して何の対策も打ってなかっただけに、怒りも倍増、3倍増、4倍増。

もっとも、その説明を行った担当者はSo-netではなくUSENインターネットの職員（元々光ファイバの引き込みはUSENが行っているのだが、サービスの選択肢を増やすために接続業者としてはSo-netがUSENの線上に乗っかる形で、USEN/So-netが選べるようになっていた）なので、USENでの扱いはそうだけどSo-netは違う、というものだったのかもしれないが、乗り換え時の不通期間の有無なんて重要な項目でのサービスの差があるにもかかわらず自社の担当説明員を派遣せず他者任せにしている時点で逝ってよしなので、何のエクスキューズにもならない。

ほんまね、なんかお役所仕事みたいに、相手の都合も考えず自分の都合と流れだけで仕事するんじゃなくて、同じ事を自分の家でやられたらどう思うか、とかの視点でサービスを行ってくださいよSo-netさん！
ほんまむかつく。今からでもUSENに乗り換えようかな...。

＃余談だけど、普段ブロードバンド定額接続で繋いでるからこそ、SPAMメールのフィルタリングはクライアント側でいーやー、Thunderbirdかしこいしー、で済んでたけど、
＃こうしてたまに携帯で従量接続してると、SPAMほんまにうっといね。
＃誰も「貴婦人との交際を楽しんでいただくために」貴重なパケット代払う気なんてさらさらないんだけどなあ...。
＃やっぱサーバで対処しないとアレかなあ。

MSNも地図サービスをはじめたと言うのは知ってますが、触ってみて琴線に引っかからなかったのでスルー。
順/逆ジオコーディングAPIが提供されたとか、そんなGoogle Mapsの諸機能並みにエポックメーキングな情報でも入ってこない限り、ちょっとパス。

でもこんな話題があったのでちょっと取り上げてみる。

Microsoftの地図にAppleはない？

Microsoftの新しい「Virtual Earth」サイトでApple本社を鳥瞰すると、11棟の近代的な建物が美しい中庭を囲んだAppleの広大なキャンパスではなく、特徴のない倉庫1棟とさびれた駐車場に見える粗い航空写真しか見えない。 　

Microsoftは、これは写真が古いためだとしている。

　　　.........

 衛星専門家の1人は、インターネットユーザーがこれらの画像を理解できるよう、各社はそれぞれの写真の日付など、もっと詳しい情報を提供するべきだと指摘している。

わざとか、わざとでないかは、多くの人にとって欲しいのは真実ではなくネタ？なので別にいいんだけど、最後のとこの「それぞれの写真の日付など、もっと詳しい情報を提供するべきだ」ってとこ、
一つの案として、せっかくインタラクティブなUI採用するために衛星写真も細切れになっているんだから、それぞれの画像毎にHTTPヘッダのLast-Modified属性や、或いは新属性として、撮影日時の情報を提供するというのはどうかな、とオモタ。
他にも欲しい情報としては、どこの衛星の撮影画像か、とか辺りかな。

要するに付加情報はHTTPヘッダで送っては、というアレなんですけど、どうですかね。
複数の画像がマージされた画像はどうするかとか、鬱陶しいアレもありますけど。
あ、後タイトルに書いときながら言及忘れてましたが、地図も何時までの情報が更新されているか、とか属性情報としてあったら嬉しいですな。

私やMapping Hacksの中の人が提唱している街角QRコードですけども、リンク先のエントリの中でも書いたとおり、アンビバレントな問題点があって、

1. 単なる汎用的な位置情報を埋め込んだQRコードだと、Java/BREWアプリなりを開発しないと活用できない（そんなもの、誰が作ってくれるのか？）
2. 特定のサイトへの位置情報リンクを埋め込んだQRコードでは、全国的な勝手基盤インフラを作ろう、なんて発想であるにもかかわらず、特定サイトに依存してしまうことになりよくない
   （飽くまで有志が勝手でやる場合。特定会社が自社リスクで配置するのならば、自由に自社サイトに誘導してくれればいいけど）

というアタリで足踏みしてしまってるわけだけど、

ケータイ版Googleローカルと言う最初にして最強のソリューションが登場した以上、それをベースにQRコード配置やってもいいんじゃないかという気がしてきた。
もちろん測地系の問題や、ａｕで地図が見えるように、とかその辺が安定してからだけど、Googleは特定のサイトながらある意味もはや究極のインフラと言ってもいいような部分があるので、これをベースなら、1.のアプローチでも誰か、或いはどっかの企業、が祭り気分でGoogleローカルへ飛ばす対応アプリを作ってくれそうな気もするし、2.のアプローチでも、Google依存になるとはいえ十分基盤インフラとして成立するような気がする。

ただ、一方で、逆にQRコード今更貼らなくてもいいのかな、という気も一方でしてきているのは、「QRコード貼れ！」と俺が声高に言ってきたのは、それをベースにどこかの企業なりが位置情報基盤を今のうちに整えておけば、2007年から10年の、来たるべき全ケータイ端末位置情報端末化時代に位置情報ポータルとして覇者になれるんじゃないかと思ったからだけど、
Googleが既にこの界隈に進出してきた以上、それに勝つのは生半可な事じゃないし、もうぽっと出のベンチャーではなくGoogle（もちろんMSNとかの、Googleと張り合えるプレーヤーもここでは含んでます）が勝つ事が見えているのならば、無理してQRコードで今位置情報基盤を作らなくても、いずれ2007年をすぎれば全ケータイにGPSなりが付くし、Wi-Fiの位置情報基盤なんかも整うだろうし、他にも可視光通信とかも実用化されてくるだろう。
そしたら、何も今急いでQRコードを整備する必要もないかな、という気もしてきてたりする。

語学学習の上で、幼い子供の耳は素直で正しい発音を覚え易い、みたいな話をよく聞くけど、そんなの嘘っぱちだ。

前、息子の歌っていた「へろへろ、爆笑ね！」という歌の本当の歌詞は何だろう、みたいなエントリを書いたが、その正体が判った。
"Hello, Hello, What's your name?"ではなかった...答えは...

"Finger, finger, What's your name?"って、英語版「この指パパ」みたいな歌だったわけですが、あらゆるところ全部間違っとんのかい!!
あまつさえ、"Hello, Hello, What's your name?でしょ？"と親が聞いたら、「違う！爆笑ね！」って、間違ってる「Finger→Hello」のところを指摘せんと、合ってるところを否定すんのかい！

なんかこれだけでクラクラきますが、さらにショッキングだったのは昨日の事、
なんか息子はCMで流れる曲でも洋楽が比較的好きみたいで、よく真似するようなのですが、家内によると、「WE WILL ROCK YOU」の歌詞を真似して、

「WE WILL WE WILL ワッチュアネーム」

と歌っていたという話...。
"What's your name?"と言っているのが「爆笑ね！」に聞こえるあなたには、なぜか全然違う"ROCK YOU"が「What's your name?」に聞こえるのですか...ＯＴＬ

流石にそれは、家内に修正されて、俺が帰ってきた頃には「ROCK YOU」で歌ってたんだけど、でも一方で相変わらずのノリノリな「爆笑ね！」が...。
うーん、彼は国際化できるのでしょうか。

位置情報関係のHACK4題です。

まずはMapServer関係のHACKから、Nakamura-KU ADDICTさんとこで、自分のサイトを訪れた人の所在地（国）をGeoIPで解析して、訪問者数を色の変化で表してくれるHACKが公表されてます。

GeoIP + Shapelib + MapServerで国別の主題図

GeoIP(Python) + Shapelib(Python) + MapServerでApache logの国別の主題図を作ってみました.

Blogを飾るマスコットとしてなかなかかっちょいいです。
うちで導入してから紹介しようと思ってたのですが、pythonなので慣れてなくてなかなかうちでは環境が作れないので、お先に紹介しました。
一応うちで掴んでる限り、

• GeoIP Library　（C及びpython）
• Shapefile C Library
• pyshapelib

アタリをインストールしないといけないみたいです。
これだけでよいかは、まだ環境作成に成功していないので不明ですが。
あ、もちろんMapServerもね。

続いて、なおっきさんちの、京ぽん位置情報を使ってGoogleローカル携帯版でのサーチを行うHACK。

Google LocalをAIR-EDGE PHONEの位置情報対応版！さらに便利に

Google LocalをAIR-EDGE PHONEの位置情報対応版！さらに便利にしてみました！

Googleローカル携帯版の登場自体は、私にとっては、ここギコを始める一つの契機にもなった1998年NTTソフト研のモーバイルインフォサーチ２実験を知った衝撃から、大昔にこの辺の記事を書いたあたりの、個人の思いの系譜に一つの区切りがついた感じで、語りだすと長暑苦しいアレになりそうなのでまたの機会にまわすけれど、

このHACK、同じ方法でauのGPSケータイでもできそうですね。
というか、単にau版のGoogleローカルで同じ事をやっただけでは、地図画像が配信されないので（なんでいつもGoogleはauをみそっかすにするのか！）ゲートウェイを作る必要がありますが。
とりあえず地図画像部分は、地図部分のURLが取得できさえすれば、auで叩いても画像の閲覧ができる事は確認しました。
あと、アイデアとしては、DoCoMoのオープンiエリアでも、東京とかの大都市圏だけですが、取得できるエリア名がまさにGoogleローカルの地名としてそのまま使えそうなアレなので、エリアを取得した後そのエリア名（／で複数地名があるものは選択するようにして）を地名欄に突っ込むHACKとかもできそうですね。

お次はジオコーディングのHACK。

日本の住所のGeocoding - Digital Life Innovator

Google Maps APIを使っているとリアルタイムに住所を経度緯度情報に変換したくなります。
そこで、他力本願ながらGeocodingのRESTサービスもどきを作成してみました。

これで、Nakamura-KU ADDICTさんとこの逆ジオコーダと合わせて正逆そろったので、いろいろ応用が効きそうですね。
ただ、負荷的には、同じく公開サービスである CSVアドレスマッチングサービスへの外注なので、できる人はそっちを直接叩いた方がいいでしょうが、
とはいえそちらは取り合いがファイル交換を模してやらなければならず、結構鬱陶しいところを、こっちはRESTでお手軽なので、非常に有用そうです。

最後に、Google Mapsで世界測地系を透過的に扱うように、Google Maps APIを拡張するHACK。

wgsgmap.js - Tociyuki::Diary

Google Maps APIと合わせて使うための、世界測地系(WGS)の経緯度座標と長方形領域を扱うjavascriptのクラス・ライブラリです。
昨日のものと同等ですが、もしもGoogle様がきまぐれで測地系を修正しても、修正個所が少なくて済むように作り直しました。
BSDライセンスです。

測地系の変換法としては平行移動を採用されているので、マップモードで使う場合は　こちらのエントリに書いた誤差が生じる可能性があるので注意が必要。
というか、比較的正確な測地系変換を採用した方がいいと思います＞作者の方
三角関数を使わない方法と、Molodensky法では、私のPC上でfirefoxでやる限りでは、100件くらい変換してベンチマークを取ってもほとんど変わらない、というか平均する限りMolodensky法の方が速い（そんなはずはないので、何か三角関数を使わない方でミスしてるかもしれないけど...でも計算結果は両者でほぼ一致）ので、他のところでも有意差がなければMolodensky法を使った方がよいかと。

うちでも同じ事を考えてて作っているところだったんだけど、うちの場合、開発の実力や時間がないのもさる事ながら、計画力がないのが最大の問題かな、という気がしてきた...。
もともと、JSANモジュールの形態でPerlのLocation::GeoTool互換に近いものを作ろうと取り組んでいたんだけど、でもGoogle Mapsと連携して動作させるならGPointクラスのラッパとして動作する方がいいかなと方針転換、でもいざある程度できてみたら、テストの際に変換結果を表示させてみて度表示でしか出てこないのが気に入らなくて、度表示をdms表示にフォーマット変換するインタフェースも欲しいな、やっぱりLocation::GeoToolベースで作るか、Location::GeoToolのオブジェクトから対応するGoogle APIのオブジェクトを生成する形の方がよいかも...と仕様が2転3転。
もうちょっと事前に計画してから物事進めるようにしましょう　＞　俺。

Google Mapsの日本近辺測地系は、世界測地系を平行移動しただけの疑似日本測地系だという話があったけど、
俺も最近まで勘違いしてたけど、それは飽くまで世界測地系で作られているサテライトモードの画像の話であって、
元々日本測地系で作られているZENRIN地図上にプロットするにあたっては、疑似どころか正真正銘の日本測地系なわけですな。

よってHACKするにあたっては、よくあるGPSデータなんかを日本地図上にプロットするような場合は、正しい世界測地系のデータを正しい日本測地系へ変換するのだから、平行移動ではなくある程度まともな測地系変換が求められるはず。
サテライトモードを主用途と考えているか、或いはマップモードが主用途でも、判ってて誤差が出るのは覚悟の上で計算負荷を抑えるために平行移動を採用するのはいいけど、マップモードを主用途にまともにやりたいと考えているなら、まともな測地系変換すべきだろう。

そうなるともっと厄介なのは沖縄。
沖縄地図が世界測地系で表示されるのは、沖縄だけまともに日本測地系→世界測地系変換された地図データを持っているとは考えにくいから、恐らくはサテライトモードでの日本本土が「疑似」日本測地系になっているという逆パターンで、日本測地系地図を単純に平行移動しただけの「疑似」世界測地系地図として提供しているのではと思われる。
（飽くまで推測だが確度は高そう）
もしそれが正しければ、正確な世界測地系で得られたデータを沖縄マップに正確にプロットしようと思えば、一旦まともなやり方で日本測地系へ変換→平行移動で疑似世界測地系へ変換、と二段階を経なければいけない事になる。
大間違いでございました。
最初に書いたとおり測地系に関する問題をマップモードとサテライトモードで混同していたので、自分で確認せずに沖縄のマップモードも世界測地系、と思い込んでました。
そうですか、沖縄はマップとサテライトで400mもずれてるんですか...これは酷いですね...。

まとめると、
　　日本サテライトモード：疑似日本測地系
　　日本マップモード：　　日本測地系
　　沖縄サテライトモード：世界測地系
　　沖縄マップモード：　　疑似世界測地系日本測地系
になっているのでは、という事。
ああややこしい。

さらに邪推を進めれば、デュアルモードの投入で日本が出遅れてる事について、ベクタデータを今手配しているのかなあ、とか書いたけど、
もしかするとこの、サテライトモードとマップモードの測地系の違いのせいで、デュアルモードがうまく重なり合わないのが遅れてる原因なのかもしれない。
Nowralさんの変換式ページを見ると、行列計算を交えたある程度マシな変換を用いてさえ、場所によっては5m近い誤差が出るとの事。
5mといえば、中程度の道ならば道幅一つ分くらいは軽くずれるという事です。
これが単なる平行移動だと、どれだけド派手にずれてくれる事か…。
日本のデュアルモードで、小縮尺では出てくる県境データ等さえ、大縮尺になると消えてしまうのは、案外この辺が理由かもしれません。

もしこの推理が正しければ、さすがにGoogleも、日本版のデュアル提供前に、測地系問題に関する最終解決を投入してくるんじゃないかと思いますけどね。

きょうは、煙草を約束したいです。

*このエントリは、BlogPet(ブログペット)の「ここ」がHS' Blogを読んで書きました。

Google Mapsまで強烈にGISGISしてきた昨今ですが、改めて最近発売された話題の洋書入門書2冊を紹介いたします。

まずは出たばかりのWeb Mapping Illustrated。

えっと、最初に書いとくと、3月頃とか、この本の噂が出た頃に即効でAmazonで注文した方。
もしかするとまだ入手されていないかもしれません。
なんでうちには届かんのやー、とかイライラされているかもしれません。
そんな時は、一度先の注文をキャンセルして、再度注文してみてください、即効で届きます。
なんかよう判りませんが、3月頃予約されていたら、購入額が5,000円以上での注文になっているはずですが、実際に今発売されているのは4,000円弱です。
その辺もあって、Amazon内でうまく処理できていないのかもしれません。 うちがそうでした。ちゃんとして欲しいなあ...。

さて、この本、MapServerを中心に、WebMappingの基本から、色々なデータ形式、また地図利用上の色々な概念、それこそうちでもよく出てくる測地系や投影法といった概念も、またMAPFILE等の仕様についても、基礎から詳しく丁寧に解説されています。
また特筆すべきは、この作者の英語、とても平易ですごく判り易い。すらすらページがめくれる。
私程度の拙い英語力でも、行き帰りの電車の中で読めば1ヶ月もあれば通しで全部読めるんじゃないかなあという感じ（数日で読めるよという人は、その辺から私の英語力を推し量っていただきたく）。
MapServer入門書としてだけではなく、Google Mapsなんかも支えているGIS全体の入門書としてもいいんじゃないかと思いました。是非オススメ。

お次はMapping Hacks。

こいつは文字通りのHACK、今巷で流行ってるGoogle MapsのHackと同じような次元のTipsの集まり。
とはいえGoogle Mapsなんてなかった時期に書かれているアレなので、それがなくても同じくらい面白い事をどう実現するか、というのに皆知恵を絞っている。
Google Mapsを使ったHACKを考える際にも、何と連携させるかで多いに参考になると思う。

色んな人が集まって色んなHACKを集めているので、その技術のレベルも文章のレベルも様々。
オープンソースGISの知識バリバリ要求するものから、先日紹介したQRコードを街に貼りまくろう！な話みたいなの、果ては「地図サービスのURLって、長ったらしくてメールとかで配信するのに鬱陶しいよね？そんな時はURL短縮サービスを使えばCOOL!!」みたいな「どーでもえーやろ」みたいなもんまで、一杯詰まっています。
なので、正直興味のない話題も多いし、読み易さもWeb Mapping Illustratedに比べると天地の差ですが、でもまあ逆にそれがHACKS本の良さであり魅力であると思います。

驚いたのは、これまで位置情報の盛り上がってこなかった日本にいると、MapServerのMapScriptが主対応しているのがPHPという事もあり、オープンソースGISでの開発言語といえばPHPでしょ、みたいな空気があるように感じていたのだけども、この本を見るとほとんどのHACKがPerl、或いはPythonで行われているという事。
Shapeファイルとかの、GISで重要かつ一般的なデータ形式をPerlで扱うモジュールとか、たくさん紹介されていてすごく参考になる。
日本では少々寂しい思いをしてきましたが、世界に目を向けたら、位置情報のエキスパートでもPerlをメインに使っている人、或いは位置情報に興味のあるPerl使い、もこんな本ができるほどいっぱいいるのだ、という事が判って中々嬉しい思いをしました。
というわけで、Perl使いにもオススメの一冊です。

とまあそんな感じで、Web Mapping Illustrated、Mapping Hacks、どちらもオススメです！

Google Mapsの地図/衛星画像の投影法一致、したのはいいんだけど、地図のメルカトル図法の方に揃えたのね。
衛星画像の 正距円筒図法（？）に合わせて欲しかったな。
巨大な南極大陸にとてつもない違和感が。

まあメルカトルだと局所局所の経緯度の縮尺比が一緒になるはずだから、グローバルに提供するローカルサービスとしてはいいのかもしれませんが。

それはそれとして、日本だと県界・主要都市の位置レベルで、大縮尺にすると衛星画像と一緒になってしまうGoogle Mapsデュアルモードですが、USA・UKで表示してみると、なんと街区レベルまでオーバーレイされていました！

すごい...ラスタ画像にベクタ地物の重ね合わせ...もうこれは完全にGISの世界ですね。
Google Maps APIでも、そのうちベクタ情報の重ね合わせに対応してくるかもしれません。
（今でもGPolylineクラスとかはありますけど）
そうなってくると、ますますGeoボキャブラリやGeoURLでの位置埋め込み等では力不足になってくるので、GML、G-XML、goSVGあたりと繋がってきそうな感じがします。

日本でも、今はベクタ地図を入手中、くらいのフェーズなんでしょうか。
いずれ投入される事は間違いないでしょう。
楽しみです。

この辺に触発されて（というか同じ事考えてたんだけど先越された感じですが）GPointクラスが日本測地系でも世界測地系でも扱えるよう改造中なのですが、
（で、やっぱり俺のやる事なので遅々として進まないのですが、）

その動作チェック中に突如、いつもの「マップ」「サテライト」ボタンに加えて、「デュアル」のボタンが出てきました。
なんじゃこりゃ？と大縮尺のモードで切り替えても、どう見ても単なるサテライトモードで、何も差がない...。

何だろうと色々切り替えているうちに、何かおかしい事に気付きました。
マップモードとサテライトモードで地図の投影法が違うために、今まで重ならなかったマップモードの地形とサテライトモードの地形が、完全に重なるようになっている！！
すげえ！何時の間に！日々進化してるぞGoogle！

でも、デュアルモードって？
その謎は、小縮尺にしてみて解けた。

答えは、地形として衛星画像を表示した上に、地名や行政界等をオーバーレイしたものでした。
すごく面白い。

ほんとについさっき、何度かリロードしてる時に突如変わりましたよ！
この開発速度、そして素早い実サービス展開...マジ気合入ってるんだなあ。
日々勉強してるんだろうなあ。ちょうどWeb Mapping Illustratedとか発売されたところだし。 

位置情報SNS「ポジタル」にMixiへの現在地投稿機能等、Mixi連携機能が追加されたようです。

mixi連携機能追加

mixiの日記をMyブログに取り込んだり（RSSリンク自動生成）、 mixiの自己紹介欄へ現在位置への地図リンクを自動で張ることができます。

早速試してみました。

確かに、プロフィールページの一番下に、現在地へのリンクが張られています。

これはMixi仲間に今いるところを通知する方式として、中々面白いかもしれません。
できればリンクだけでなく、住所も直接載った方が判りやすく面白いのでは？とも思いましたが、その辺はプライバシーの問題とかも絡めているのかもしれません。
リンク先はポジタルの地図表示ページのようなので、そちらならばポジタル内でも仲間同士のユーザでないとアクセス不可になるとか、そういうプライバシー配慮なのでしょうね...。

mixiの認証情報は、サーバには一切残しません。
利用者がお使いのブラウザのクッキーへ認証情報（IDパスワードではありません）を保存します。

クッキーを利用できない携帯電話には対応していません。

という事ですが、この辺はCookieの使えないキャリアは今でも決して少なくはないはずなので、ちょっと残念。
でも、画面メモの機能とかをうまく使えば、サーバサイドでデータを保存しなくてもやりようはあるはずなので、その辺また開発者さんにレポートしてみたいと思います。

先のエントリにトラックバックをいただいた。

Googleマップの測地系について - Watching from Yokohama

ここで話題の韓国は日本の占領下から引き継いでいた旧東京測地系とKTRF2000といういわゆる新測地系が混在している。
韓国の国土地理情報院も2種類の測地系での地図提供を行っている。
最終的には2006年12月31日までは後者に移行することになっている。

なるほど。
東京測地系は明治時代からという事ですし、韓国の測量も占領下でかなり進んだはずなのでその可能性も感じてはいたんですが、一方で米軍との連携もあるので世界測地系なのかなとも思っていましたが、混在しているんですね。

でも判らないのは、

日本では、世界測地系で地図資産を蓄積している信頼できる地図会社は無いため、今回のような問題が発生してしまうのだ。

というあたりなんですけど、単純に「地図は旧日本測地系だけど、サーバサイドでの座標変換で座標指定は世界測地系」というわけにはいかないんでしょうか？

確かにマジで変換テーブル使って正確な測地系変換しようと思うと大変なんでしょうし、計算だけの簡易変換だと多少のズレは生じるのでしょうが、とは言ったってその程度のズレなんて、沖縄が日本に入ってなかったり、中国で日本測地系になったりというような失態を演じるよりは、簡易変換で多少ズレ、の方がまだマシなんじゃないかと思います。
世界的なグローバルサービスを目指しているはずのGoogle Mapsなんですから、いずれは世界測地系にしなきゃいけないと思いますし、それならまだベータ版なんですから多少ズレていてもOKとして、その間に世界測地系地図を準備してもらうという形で、将来にツケを残さない方法をとった方がよかったと思うんですが...。
日本でだって混乱を引き起こしただけで双手を挙げての歓迎はされたわけではなかったし、沖縄なんかではGoogleのイメージダウンに繋がるだろうし、韓国はともかく中国なんかでは、私も「Google的日本測地系帝国」に属してしまっている大連に友人いますけど、せっかく同じようにGoogle Mapsにはまっている連中がいたとしても、みんなあきれて離れてしまうんじゃないかと心配します。

現に同じようにZENRINの地図を使っているはずの沖縄では世界測地系で配信しているという事なのですから、同じように日本中で世界測地系で配信する、という事はできなかったのでしょうか。
元記事さんの別のエントリでは

いずれにしても、ゼンリンの地図、タウンページデータベースという国内で購入できる最も高価で信頼性の高いコンテンツを最初から惜しげもなく投入したということは、生半可な発想では取り組んでいないということを如実に物語っている。

と書かれていますが、でもそれにしてはこの対応は、天才集団Googleらしからぬ拙劣さを感じます。
なんか別の思惑があるんでしょうか...。

といってもGoogleが正式対応したとかじゃなくてHACKした方登場というわけですが。

暇人的ブログ
＞＞GoogleMapでgoSVGのg-xml:poiをレイヤリング

私はというとせっかくgoSVGのデモサイトがあるのでそれらを使ってオーバーレイするサンプルを作ってみました。
goSVGのg-xml:poiを読み取り<image>タグでリンクしているサイトをさらに走査していきます。
　　......
goSVGはハイパーレイヤリングというインターネットに分散しているPOIを重ね合わせて表示できるので、SVGのコンテナで各サイトへのリンクを貼ってあたかも動的に収集しているような効果が得られる。
また、G-XMLのPOIも埋め込むことができるのでgコンテンツの流通形式としてはもってこいだろう。
これをRSSでやるとしたら大変？

＞＞GoogleMapでgoSVGのg-xml:poiをレイヤリング（その2）

1.goSVG(HyperLayering含む)のg-xml:poi要素を解析してGoogleMapにオーバーレイしています。
2.インターネットに分散しているg-contentsをgoSVGをコンテナして集約する いわゆるアグリゲーションサーバとして機能します。
3.Mapの移動に連動してDynamicにPOIを抽出しオーバレイしています。(但し検索領域は1000mに限定)

すごいですねー。

私もgoSVGとGoogle Maps融合しちゃえ！とか叫んでた手前、そーいやGoogle Maps APIでgoSVG表示できるようにすればいいんだよな、とはこないだ気付いたのですが、
偉そうにgoSVGgoSVG叫んではいるものの、gコンテンツの展示会とか行って概念は理解しているつもり（超思い込み）だけど、詳細仕様はこれからお勉強なのでうーん先は長いなーと思ってたら、
もうやってる人がいたわけなので、安心してお任せして、私は相変わらずの口から出任せに徹せられるわけですな。
というか、偉そうですな。＜俺。
すみません、いろいろ勉強させてください　＞　暇人的な人

韓国から無事戻ってまいりまつた。
レポートとかは余力があればおいおいやるとして。
そのレポートに位置情報はっつける際に関わる問題として、Google Mapsの測地系は韓国では日本測地系らしい。
世界測地系で場所調べても、わざわざ変換かまさんとはっつけられへんやんけ。
おまけに沖縄は世界測地系との事。

具体的な日本測地系/世界測地系切替の領域はこんな感じらしい。

Google Map Japan and 2 Datums

沖縄、朝鮮半島、旧満州、千島、南サハリン...単純に経緯度で切っただけなんだろうけど、見事なまでに政治的にすんげー微妙な、あちこちの逆鱗に触れかねんあたりをばっさりと。
もうちょっとうまくやってくれー。
サーバサイドでなんとかならんかったのか。ほんま。

####追記####
げ、しかもGoogle Mapsが使ってるの日本測地系じゃなくて、

Google Mapsが北緯30度から50度までと、東経115度から152度の間にある地点は世界測地系を単純に平行移動しただけの擬似的な日本測地系を使うように変更されています。

とか書かれてるで。
マジか。
衛星写真でこそ不正確な位置でもアレだったかもしれんけど、せっかくゼンリンのあれだけ正確な地図使ってるのに、そんなんやったら場所によっては10mくらいは軽くずれるんじゃないの？（未検証）

きょう、エントリにblogするつもりだった？

*このエントリは、BlogPet(ブログペット)の「ここ」が喫茶「ふるさと」を読んで書きました。

GPSは入れられませんが
帰ったらGoogle Mapsリンクでも加えようかと思います

しかしインターフェースもさる事ながらGoogle Mapsの衝撃って
こうして世界中どこでも共通にポインティングできる手段ができたというのも大きい気が

前回の韓国行き後
記事に韓国の地図のリンク張り付けようとしたら
いわゆるpermalinkの概念がないActiveXばりばりのサイトしかなくて
失望したのを思い出す

さすがに携帯でやるのは対応してないので無理ですが
友人の会社のココカメシステムの原理のように（同様のアイデアはMapping Hackにも載ってましたが）
常時GPS専用機器を持ってトラッキングして
後でデジカメの撮影時間で串刺しにして撮影場所を特定、という事をすれば
すでに世界を舞台にモブログする環境が整った事になりますね

逝って参りまつ
【GPS情報】
http://walk.eznavi.jp/map/?datum=0&unit=0&lat=+35.46.18.48&lon=+140.23.13.27&fm=1

古臭い電車だが
デザイナブル（注：ねね家謹製創作英語）な最近の電車になれた最近のガキンチョには逆に新鮮らしい
かっこいいかっこいい
あれに乗って帰ると大騒ぎ

旅行前日に用意もせずに何時間も費やして、全くバグがとれない...。
バグというか、それ以前の問題として、クラスのコンストラクタ自体が全然動いてくれない。

焦る心。流れる冷や汗。溜まる疲労。

そして気付いた。

そういえば、Locationって、JavaScriptの組み込みオブジェクトにあるやないか！
Location.GeoTool.jsとかやったって、そりゃ動かんわな！
GeoTool.jsにしたら、サクッと通りました（いや、コンストラクタだけですけどね）。

JavaScript、普段使い慣れてないし、使っててもこんなPerlみたいな使い方で使った事ないから、サクッとLocationオブジェクトの存在なんて頭から飛んでました。
という感じで、JSAN面白そうなので触り始めました。
やってみるなら、ここ超便利。

昼休みも終わりつつあるのでリンクだけですが、ULSE開発元のjm@fooさんが、MovableTypeで位置情報を抽出するプラグインを作成されています。

Movable Type用 位置プラグイン - jm@foo

Google Maps APIなどの位置情報ツールとMovable Typeをつなぐプラグインを作成。
エントリーに含まれる緯度経度を返します。

対応する位置情報：
・エントリー本文にimgタグとして記述され、同じサーバに置かれている画像のExif GPSタグ
・エントリー本文に含まれる地図サービスのURL ( walk.eznavi.jp / www.gpspowered.jp / mapfan.com / www.mapion.co.jp )

というわけで、GW通す、とかに比べてかなり本質的なソリューションです。

記事中では取り上げられていませんが、Geoボキャブラリ埋め込みRSSとかも楽勝ですな。
私も週末明けくらいにでも導入してみたいと思います。

最近大学時代の同期でKDDI研究所に行った奴がMixiに入っているのを知って、マイミク登録したんだけど、

そいつのポータルで公開されてた研究テーマ履歴に

Webページ適応変換プロキシ試作

とあったので、もしやあの、世のEZwebサイト開発者の開発工数を大幅に削減し、睡眠時間、家族との安らぎの時間、飲んだくれる時間を提供してくれる事となったHDML<->XHTML変換ゲートウェイは、彼奴の作りしものなのかっ？と思って聞いてみると、そう、との事。
正確には、本人いわく、試作しただけで実際に入ったのはベンダーに作らせたもの、と言うことだけど、原理は彼が作ったわけで、その意味で彼が生みの親と言う事は間違いないだろう。

いやあ、俺もむちゃくちゃ世話になったクチだけど、すげえ身近な奴が作ってたんやなあと感動。
彼に足を向けて眠れません（未検証）。
こっちは俺はほとんど世話になってないけど、

動画像適応変換プロキシ試作
動画像適応変換方式の検証

というのもいろんな人にありがたがられてそう。

漏れもこういう世の人の生活に何気に役立つもんを作ってみたいでつ。

というか、ここまでこっち方面のアレがやってみたくなるなら、素直に就職時にKDDIとかDoCoMo選んどけばよかったなあ。
何を血迷ってクボタなんかにしたんだか。
まあ基本的に発想がユニバーサルサービスなので、キャリアに入ってたら入ってたで苦悩もあったとは思うけど。

京都で（なんで？家は五反田のはず...）大学院生をやっている家内ですが、今度の連休最終日の月曜から数日にかけて、韓国ソウルで学会があるという事で、
「行きたいンやけど、息子昼間見る人がいなくなるから、会社休んで一緒に付いてきてくれへん？」

「アホかーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーい」

んでなんだかんだで百歩譲って、行ってる間は、息子の幼稚園の延長保育フルに利用して、送迎を俺が引き受けて、家での子供の面倒や最低限の家事もその期間は俺が見る、という事で話が一旦ついた。
んだけど...。

家内が電話で現地ホテル従業員と交渉したりしてるのを傍で聞いていると、むらむらと行きたいという気の迷いが...。
そこでつい、一時の感情で「連休の間だけ付いて行ってええか？」。
という事で連休は韓国に行く事に。

しかし後で激しく後悔。
これだけGoogle Maps周りとか激しく面白く動きそうな時に、しかも自分の生活が週末以外ほとんど何の取り組みもできないような状況で、せっかくの連休をこんな何の計画もない韓国旅行でなんで潰さなきゃならんのかと。
おまけに家内の選んだ宿、自分だけで泊まるための安宿で取ってたみたいだから、ネット環境なんか望むべくもなさそう。
うー、なんで行きたいなんて言っちゃったのか。

でもまあ今更言っても仕方ないので、まあ行くなら楽しんできますが...。
3日間の間に世の中がどう動くのか、（涙ながらに）楽しみにしてまふ。

WebService::GoogleMaps

こんなCPANモジュール見つけました。
Google Mapsを切り取って、1枚の希望サイズの絵にしてくれるようです。
これで、Google Mapsをケータイサイトでも使う事ができますね。

center_viewport_on_coordinatesなんてメソッドで、複数の点の中央を求められてさらにズームレベルまで調整してくれたり、insert_latlon_marker_gdでマーカーを作れたりと、何かと便利。
欲を言えば、ピクセル単位でパンした後の中央の経緯度が求められればなおよかったんですが...気が向けば改造してみます。
測地系は、別に意識もされてないようなので、日本では日本測地系なんだろな。

問題は、Google APIを通していない、こうした地図画像を加工しての利用は、こちらの場合と限りなく近いので、Googleに閉鎖を言い渡される可能性もあり、という事。
ケータイでは特にGoogle Mapsを使うアドバンテージもない（こうしたCPANモジュールが出たのがアドバンテージかもしれませんが）ので、MapFanなんかがケータイ地図ページを開放（画像じゃなく飽くまでページですが）したりもしてる昨今ですし、素直にそっち使った方がいい気も。

あ、そのケータイMapFanですが、日本縦断アンテナDASHでの使われ方を見る限り、URLのクエリストリングにに戻りリンク先や現在の中心経緯度が埋め込まれているようなので、戻りURLにセッション情報埋め込んでやったり、戻ってきた時のREFFERを解析したりとかで、地図を移動して戻ってきた結果をサイトで反映したりとか、面白い利用法もできそうな予感。
試せてないですけど、どなたかレポートもらえませんか？

Google Maps APIでつながる世界 - YappoLogs

Google Maps APIを使ったphotos@Yappo mapsに色々機能を付け足してみました。

大きなMapと小さなMapのシンクロが面白いです。
あとシンクロした事ないけど、他の人の見たところをLiveで共有できるとか、すごく面白い。

現在放映中の番組限定??全国ロケ地図 - Digital Life Innovator

現在放映中の番組限定の全国ロケ地図を作成しました。
こちらは、１日１回自動的に全国ロケ地ガイドからシーン情報を取得して情報を更新します。
全国ロケ地図 http://saya.s145.xrea.com/x/map2.html
自動更新の仕組みは、全国ロケ地ガイドのTOPページからリンクされている各番組のページを読み込み、解析し、CSV形式にして、住所からCSVアドレスマッチングサービスで位置情報に変換してデータファイルに保存、という感じです。

うちの子もマジレンジャー、響鬼とか大好きだけど、これで面白かった回の場面巡りとかにも連れて行ってやれますね...。
CSVアドレスマッチングサービスって、市町村合併とかにどの程度まで対応できてるのかな...。

みんな面白いこと考えるなー。それにみんな動きが早いです。
なんか最近JSANが面白そうなので、Location::GeoToolでも移植するかー、何週間くらいかかんのかなー、みたいな感じでのんびり構えていた私には追随できない速度です。

＃あれ、Location：：GeoToolってまだ1.98しか公開してなかったっけ。
＃1.99はSubVersionにしかないのか。早く挙げないと。

動きが早すぎてついていけない。

うちのコメントでも、

深読みで根拠はありませんが Googleが日本測地系をサポートしたのはアルプスマップさんとかMapfanさんあたりの日本測地系の地図を載せる前のテストだったりしませんかね？

とかいただいてて、ネット上の反響もおおむねそんな感じなので「みんな考えることは同じですねー」とかなんとかのほほんとレスしようと思ってたら、もう対応してしまった。

日本の地図がGoogle Mapsに登場 - ふと思う--ちょっと考える （いたずら編）

Google Mapsの測地系が変わってしまったんだよなと思いながら「Google MapsがTokyo測地系に変わったらしい(fumiakiyの日記)」を読んでいたら、maps.11.jsにZenrinなる文字列があるというコメントを見つけました。
早速、物はためしとGoogle Mapsを開いていつもは無視の｢マップ｣ボタンをクリック。
そこに現れたのは間違いなく日本のどこかの地図。建物の形が細かく入っていて、まさにゼンリンの地図です。

そういえば、俺も日本測地系の確認してた時にZenrinってみたような気がする。
意識の外に飛ばしてたけど...。

でもゼンリンか...。
前の仕事つながりで名刺は何枚かあるけど、一番縁遠いとこだな...。

invGeocoder のRESTを作ってみました。 - Nakamura-KU ADDICT

Nakamura-KU ADDICTのnishiokaさんが、経緯度→住所のinvGeocoderをREST化されたようです。
経緯度だけでなくSRIDを指定しての任意のXY座標を指定できたり、出力としてG-XMLを選べたりするあたりが、さすがGISerですね。

試しに示されているサンプル例を、G-XMLにするとどうなるかやってみました。
http://nishioka.sakura.ne.jp/google/ws.php?lon=137.243183&lat=35.091722&format=gxml

<?xml version='1.0' encoding='UTF-8' ?>
<gxml:G-XMLdata xmlns="http://www.dpc.or.jp/gxml"
 xmlns:gxml="http://www.dpc.or.jp/gxml"
 xmlns:gml="http://www.opengis.net/gml"
 xmlns:xsi="http://www.w3.org/2001/XML-Schema-instance"
 xmlns:xlink="http://www.w3.org/1999/xlink"
 xsi:schemaLocation="http://www.dpc.or.jp/gxml gxm3.1/G0XMLdata.xsd">
   <gxml:spatialLocator>
      <gxml:AddressString>
         <gxml:unstructuredAddressString>愛知県豊田市矢並町香沢253</gxml:unstructuredAddressString>
         <gxml:AddressItem level="1">愛知県</gxml:AddressItem>
         <gxml:AddressItem level="2">豊田市</gxml:AddressItem>
         <gxml:AddressItem level="3">矢並町香沢</gxml:AddressItem>
         <gxml:AddressItem level="4">253</gxml:AddressItem>
      </gxml:AddressString>
   </gxml:spatialLocator>
</gxml:G-XMLdata >

うひょー。

かっちょえー。

Mapping Hacks (HACKS) が出て1週間経ってませんが、
5月末に発売予定のままその後どうなったかよく判らなかったWeb Mapping Illustratedが、注文状況を確認すると昨日発送されたっぽいです。
Google Mapsの盛り上がりの真っ最中という事で、偶然とはいえほんとにここに来て急に何か動き出したという感がありますね。

Web Mapping Illustrated

posted with amazlet at 05.07.13

Tyler Mitchell
Oreilly & Associates Inc (2005/06/30)
売り上げランキング: 86,549

Amazon.co.jp で詳細を見る

Google Maps APIでの経緯度指定が、日本では日本測地系になったらしい。
詳しい仕様はよく判らんけど、ちょっと調べた＆触った限り、「日本測地系が選べるようになった」ではなく「日本測地系になった」っぽい。

その辺をやり取りしてるDiscussion

なんか意味判らん。
中の人も「よい方法とは思わない」見たいな感じで書いてるみたいだけど、日本でだって画像EXIFに入るGPSデータはWGS84なんだし、一律TOKYOにしたって何の解決にもならんだろうに。
むしろ最初と異なる仕様に変わった分混乱するだけ...。

それに、日本だと何を基準に判断してるんだろう？
ロケール？地図の表示範囲？
日本からでも日本語以外のロケールでアクセスする人もいるだろうし、ソウルやサハリンの経緯度を日本の地図サイトで取る人だっているだろうから、どんな方法にせよシステム側が一律に測地系を決め打っていいことは何もないと思うんだけど...。

案の定はてなマップも大混乱？
前に宮川さんのやつ改造した、私のGeoボキャブラリRSSマップも、とりあえずサーバサイドで測地系変換させて対応しました。

##### 追記 #####

とか何とか書いているうちに、上記ディスカッションページで

Just notices that version 11 is out on the main Google Maps webpage.
Looks as though there is a variable for DATUM hack. Looks as though they may be incorpating this.

なんか選択式になったっぽいです。
そりゃそうだよなあ。

Google Maps with geocoder - blog.bulknews.net

geocoder.usとGoogle MapsのHACKの話題。
アメリカさんは、住所の統廃合とかの問題とかはあまりないんだろうか？
一応、不完全だとかみたいなエクスキューズはあるみたいだけれども。

日本じゃ、いくら公開されていても、特に平成の大合併の後じゃ、街区レベル位置情報を使うのは苦労の割に...で躊躇しちゃう。
NAKAMURA-KU ADDICTさん逆GeoCoderで利用されてるのにそう言うのもアレだけど...。

著作権違反を躊躇しなければ（躊躇しろ＜でもHACKってそんなもんじゃん＜Google HACKだって）順GeoCoderはMapFanをHACKするのが現状では一番。
街区（何番何号）レベルまで解析して、経緯度を返してくれる。
逆に逆GeoCoderの場合は、MapFanだと市区町村までしか返してくれないので、一番詳しいのはMapionで町丁目まで返してくれる。
で、思うにベストなのは、町丁目より下位の何番何号のところって、合併とかあったってそうは変わらないんじゃないかと思えるので、
街区レベル位置情報で得た結果の町丁目より下位の部分と、Mapionで得た町丁目以上の住所を融合させるのはどうかと。

もっとも、街区レベル位置情報だけだと一番近い代表点を持つ街区を選ぶしかなく、どうしても誤判定が出てしまうので、マジでこの方法で正確に出そうと思うと、数値地図の行政界拾ってきてポリゴン判定するしかないけど。

ところで、上に書いた事は****明らかに著作権違反****なんだけど、
街区レベル情報とかで得たローカルのDBを、合併後の住所なんかに更新するのに、住所が現在の正しいものと違っているのかどうか「だけ」を判定するのに、地図サイトにロボットアクセスしてチェックするのは、著作権違反にあたるんだろうか。
自動で修正までしてしまえば、誤字なんかもそのまま移るし明らかに違反だろうけど、自分のDB内の住所と地図サイトの住所が違うものだけをチェックして蓄積しておいて（それもロボットで一気に取ってくる！とかじゃなくて、データ検索要請がある度にバックグラウンドでチェック、とか穏やかな方法で）、後で手動で行政のWeb発表とかをチェックして直す、というのはどうなんだろう？

法人・個人また、公式サイト・一般サイト問わず、日本全国いつでも・どこでもご自分のケータイサイトの住所・電話番号やランドマーク情報などから、弊社の「ケータイ地図MapFan」サービスの地図ページを利用して、表示したい特定の場所の地図へリンクすることが可能となりました。

昔、同社へ地図利用要請して、月1000PVで数万円と（それでもかなり安くしてはもらって、だけど）言われて泣く泣くあきらめたのを思い出します。
それからおよそ2年半、ようやく来ましたな。
これも「ケータイ」という牙城は崩されまいとする、Google Maps効果でしょうか。

まあまだ、画像でなくページを提供するだけなので、Google Mapsみたいに地図上に情報アイコン等を重ね合わせもできないし、地図表示後、地図上で移動した場所からのフィードバックも受けられないし（多分。できるのかな？）、何よりWILLCOMが無視されてるのがアレですが、それでも大きな進歩には違いない。

というわけで、ポジタルさん、携帯の地図に困られてましたが、3キャリアではこいつ使ってみたらどうでしょうか？
（WILLCOMでも単純に同じURLに飛ばしたら見られる...って事はないかな？）

auケータイは時刻自動補正がついてるから、目覚ましアラームも毎朝正確だ。

ここ2、3日、家内と同じ朝6時に（いつもは4時半）起床時刻を合わせているので、家内の端末内臓のテクノなアラームと、俺の着信音と同じ「かに道楽」の着うたが見事に同時に鳴ってシンクロする。
テクノかに道楽。

Livedoor MAP トラックバックのRSSが動いていなかったのを、ようやくチェックできました。
とりあえず内部のエラーは潰せたんですが、RSSは出るようになったもののリストが挙がってこない...。

と思って元ネタのLivedoor MAPのページ見たら、そこ自体がトラックバック結果出なくなってますね。
検索してもなくなったっぽい情報はないし、トラックバック欄自体は残っているので、廃止されたわけではないと思うのですが...。
一時的な不具合か、なにか設定変更中？

Google Mapsとか出てきているからなんか新しい機能突っ込もうとしている最中、に4000万ペリカ。

HTTP::MobileAgent、本体とサブクラスを分離して、別個開発できるよう にするのはいいんだけれども、かといってスタートアップ時に本体だけでなくサブクラスもいちいち全部落とさないと動かない、という状況にするのは嫌なので、やはり本体には最低限のサブクラスは添付して配布 したい。
でも、分割開発してるのにそういう事をすると、本体に添付されているサブクラスが、個別配布されているサブクラスより低いバージョン、という事もありうる。
なので、本体配布のサブクラスは、既にインストール済みのサブクラスよりバージョンが低ければ、そのサブクラスはインストールしない、という機構を作ろうと目論んだ。

その実現方法が判ったので、書いてみる。

まず、本体に配布したサブクラスを一緒にインストールする方法だが、一番単純なのは本体のMakefile.PLがあるソースディレクトリの直下 に、サブクラスのソースディレクトリ（Makefile.PLがあるところ）を配置しておいてやると、perl Makefile.PLをすると一緒にMakefileに落としてくれるという事がわかった。
でも、これじゃインストールするかしないか制御できないので、ExtUtils::MakeMakerをもうちょっと調べてみると、WriteMakefile関数に渡してやる属性にDIR というのがあって、これに一緒にインストールするモジュールのサブディレクトリを配列リファレンスで与えておいてやると、そのディレクトリだけ同時インストール処理してくれるというもの。
こいつでインストールするサブディレクトリは制御できる。

後はインストール済みのサブクラスモジュールとインストール予定のサブクラスモジュールのバージョンを比較して、インストール予定の方がバージョンが大きければインストールするだけ...だったが、思いのほか戸惑った。
どうせならどちらもバージョンは$クラス名::VERSIONから取りたいけど、どっちも同じクラス名だけに、パスを変えてやっても1スクリプト内で同じ名前のクラス2つも呼び出せないからだめ。
noプラグマとかで明示的にアンロードできないかとかもやってみたけどだめ。
結局、ロードされたクラスのリストは%INCに入ってるはずだから、%INCをローカル宣言して、なんとか希望の動作をさせられた。

結局こんな感じ。

きのうここが、位置ー！

*このエントリは、BlogPet(ブログペット)の「ここ」が書きました。

日本オラクルでは「Google Mapsの開始もあり、地図サービス市場はいま非常に注目されている」と市場の広がりに期待している。

おー。
天下のオラクルですら、Google Mapsの影響力をもろ感じてる感じなのか。
有償高価のOracleソリューションですらそうなのだから、オープンソースGISも順風満帆になるのかもね。
楽しみです。

その一方で、ちょっと個人的にはこれまでの経過に嫌な感じも受けないでもない。
某GIS社の中の人にも教えてもらいましたが、今のGoogle Mapsに代表されるようなAJAX系の地図ナビゲーションソリューション、別に最初に開発したのはGoogle Mapsじゃなくて、先にOracleがそういった事ができる製品作り出してて、そのOracleの提案・技術支援で、日本でもMapionがMapionラボのようなサイトをGoogle Mapsよりかなり先に公開してたりしてたんだよね。
でも話題にならなかったし、誰もHACKしようとはしなかった。
Googleがそういうのを公開した途端、大反響になって、そこからやっとAJAXだのGoogle Maps HACKだのが話題になりだした。
確かにAPIを公開して、また自由にHACKするのを認めた功績はすごい、と思うんだけど、HACKする側の活動はAPIの発表前から始まってましたよね。

そう考えると、「Googleが出したから面白そうだからHACKする、Oracleが、Mapionが出したものだから面白くなさそうだからHACKしない」っていう価値観ができちゃってるんじゃないかという印象も受ける。
つまり、もうネット上技術の方向性の大勢を決められる会社は、Googleとか米Yahooとか、SixApartとか、日本ローカルだとはてなとか（いや実際にはもっとあるとは思うけどとりあえず4社ほど）、その辺の会社が取り組むか取り組まないかが固定指標化してしまっていて、それ以外のところがやった事については論評に値しないというような思考停止状態に、全体が陥っているような気がしないでもない。

こちらであさんのコメントから教えてもらったんですが、私がこのアタリからずっと持論にしているQRコードに位置情報を載せる案（実際には旧社にいた時代から内部では言っていたのでもっと前からですが）、ついに実適用例が出てきたみたいです。

携帯で即観光情報　神戸市が来月から実験

従来のバーコードよりも大容量の情報を持つ「ＱＲコード」を案内板に掲示。
読み取り機能がついた携帯電話で撮影すると、インターネットの案内サイトにつながる仕組み。
三宮、元町周辺の地図付き案内板（縦二メートル、横〇・六メートル）九十二基が対象で、空きスペースに一・五センチ四方の同コードを新たに掲載する。

もっとも、記事からは詳細はあまり読み取れないので、各案内板についたQRコードのどれにアクセスしても同じ情報サイトに飛ばされるならば、全然位置情報じゃないですが、
各掲示板毎にその掲示板の場所に合わせた異なる情報ページに飛ばされるならば、たとえ経緯度が入ってなくてもそれはもう立派な位置情報ではないかと。

ぜひ、東京電力の電柱広告でも、QRコードの提供を進めてくださいよー。　＞　東電広告のシステムさん

-- 追記 --

コメント欄でまさきさんに教えていただきましたが、５月くらいにも東京で似たような取り組みがあったみたいですね。
こっちは確実にQRコード位置情報っぽい。街路樹なんかにも貼られてて本格的だし、GPSにも対応。

「東京丸の内ユビキタスミュージアム」

1. 街中に広く情報アイコンを設置しました。

(1) 仲通りの街路樹94本に「情報アイコン（QRコード）」を設置。“ケイタイ”からQRコードを読み込むことによりその付近の情報を簡単に得られます。
(2) 各ビルに設置されたパンフレットラック等にも「情報アイコン（QRコード）」を設置。（80箇所）
(3) また情報アイコンの位置がわかるマップ・パンフレットを街中に設置。紙と携帯の融合により一層便利に。（63箇所）

3. GPS（※2）機能に対応してます。

GPS機能付き“ケイタイ”ならば、自分のいる場所の情報が自動的に取り出せます。

私が「街中にもQRコードを!」という理由は、今から整備しておけば、それをベースに蓄積された位置情報レポジトリが、将来GPSでもWPS（無線LANによる位置特定）でもいいんですが位置特定デバイスが当たり前になった時代に、すぐさまゲートウェイを追加するだけで利用できるようになるからです。
こういう時代は確実に来ます...だって、法律（日本版E911）で決まろうとしてるんだもん。
（現在の目標、2007年には発売される全ての新機種にGPS（或いはそれに準ずる位置特定機能）追加、2010年にはほぼ普及。）
その意味で、既にQRコードとGPSの位置取得がハイブリッドされてる丸の内のこの利用例は、面白い！と思いました。

付き合いの深い位置情報サイト仲間のGoogle Maps API HACKが進んでる話を書きましたが、さすがにGoogle Mapsが世間に与えた衝撃は大きかったようで、今度は逆に非位置情報サイトの位置情報化（単にGoogle MapsをHACKするだけでなく、位置情報そのものの本質的利用について考察を始めた）が始まっているようです。
なんか面白くなってきそうですね。

まずは身内びいきというか、友達のまかまか産地が、Google Maps APIを使って2点間の距離を求めるアプリを作られたようなのをご紹介。
いいぞまかまかたん、このまま位置情報にのめり込むのだ！
でもって横浜アタリで、位置情報な人何人か集めて飲み会でもしよう！（謎）

お次は宮川さんのこの記事。
これまでのWeb上での位置情報付加仕様をまとめたページを見つけられた模様。
すごいですね...こんなにあるとは思わなかった。
OGCの仕様とかまでしっかり載ってます。
こういう有益情報をサクッと仕入れてくる情報収集能力に脱帽です。

続いてこちらのサイトの方。
宮川さんのgeourl RSSのGoogle Maps APIマッピングに触発されて、RSSやAtomへの位置情報埋め込みを考察始められたようです。

• GoogleMapsとRSS
• RSSとGEO

最後に個人じゃなくて法人ですが、はてながGoogle Maps APIではてなマップをオープンされた模様です。

http://map.hatena.ne.jp/
はてなマップは、Google Maps APIを利用した地図サービスで、世界中に広がる衛星写真を眺めながら、地図上にマッピングされたキーワードや写真を眺めることができます。
はてなダイアリーキーワードやフォトライフからは、新しく地図情報を登録したり、地図情報が埋め込まれた写真を登録することが可能です。

海外とかよく知らないのですが、法人としてGoogle Maps API（或いはGoogle Maps直接、アライアンス等で）使った例ってあるんですかね？
個人のHACKとかで使うならまだしも、法人が絡んできたら、巻き込む範囲が少ないうちに早くKDDI特許の問題ナシつけないとややこしくなる気もするのですが...。
といってもGoogle側が気付いてなければ、或いは気付いていても、動くはずはないので、KDDI側がアクション取らないといけませんよね...。

はっきり言って同じ障害を持つ人以外にはどうでもよい話でしょうが、もうちょっと書きます。

先のエントリにasakura-tさんより、

asakura-t> えーと、タッチパッドじゃ駄目な理由を是非。

ねね>   うをっ！ 散々書きましたが確かにこれはタッチパッドでは！

と書きましたが、よくよく考えるとやはりタッチパッドとペンタブレット（の発展系としてのフリーハンドデバイス）は大分違います。

第一には、タッチパッドって結局は接触式だから、パッド表面を圧しながら摩擦をかけて動かす、という事で、やはり負荷が大きいんじゃないかと思います。
一方、ペンタブレットというのは、少なくともWACOMのペンタブレットは、使ってない人にはあまり知られてない事ですが、あれ、非接触デバイスなんです。
ペンタブレットって、私のような使い方の方が特殊なわけでして、普通はペンや鉛筆・絵筆と同様に扱える描画用のデバイスとして、デザイナーの人が使うものですよね。
つまり、「タブレット表面に接触してペンを動かす」という事は、それはすなわち「線を描いている」という事になり、マウスで言うところの「ドラッグ＝左クリックしながらマウスを動かしている」状態になるわけです。
（それゆえ、ペン先を一瞬タブレット表面に接触させる「タップ」行為が「クリック」と同義になる）

それなら、ドラッグしない普通のポインタ移動はどうしてるかというと、実はタブレット表面から5mmから1cmくらいの空間を空けて、空中でペン先を振り回せば、ポインタが画面上で追随してくるのです。
原理はよく知りません...おそらく微少電磁波による電磁誘導とか使ってるのかと思いますが...。
つまり同じ行為をペンデバイスなしで指先でやったとすると、タップによるクリック、接触引きずりによるドラッグ、等を行わない限り、全くのフリーハンドで、空中で手をぶらぶらさせているのと同じとなり、手に負荷はかかりません。
これは大きな差だと思います。

第二には、ペンタブレットはタッチパッドやマウスのような相対位置指定デバイスではなく、絶対位置指定デバイスだという事です。
つまり、タブレット表面の大きさがディスプレイ上の画面全体の大きさに対応しているので、タブレットの左下は画面でも左下であるし、右上は右上なわけです。
私がasakura-tさんよりのコメントを受けて

タブレットと同じA6くらいのでっかいタッチパッドが存在するかどうかご存知ですか？

と反射的に聞き返してしまったのを見て、「どうしてタッチパッドがそんなにでかい必要があるの？」と思われた方もいるかもしれませんが、これはそういう、絶対位置指定の出来る（＝ある程度大きさのある）ポインティングデバイスが、私の中で当たり前になってしまってたからでした。

絶対位置指定は便利だし楽です。
一度使ってしまうと、中々相対位置指定デバイスには戻れません。
画面の左下から右上へポインタを移すのに、マウスやタッチパッドといった相対指定デバイスだと何度も中継ぎでデバイスを持ち上げてサッ、サッ、サッと手首を返さねばなりませんが、ペンタブレットだとサッ、と一度タブレット面の左下から右上へ手首を返すだけで、ポインタが追随してくれます。
これは直感的で判り易くて楽だし、何より運動量が少ない分手への負担も楽です。

今までそれしかなかったからみんなマウスのような相対位置指定デバイス使って、それに慣れてますが、正直言って、元々絶対位置指定のデバイスの方が人間にとって本能的に使い易いはずだと思ってます。
PC初心者のオヤジが、ポインタを動かすのにマウスを持ち上げる、という発想ができず、机の裏までマウスを転がした...なんて笑い話も、遠因はこの辺にあるんじゃないかなと。
PCディスプレイ上のポインタのような、全体を直交する視点から俯瞰→目からのフィードバックがし易い用途では、とはいってもみんないずれは慣れてくるでしょうが、これが3次元でのポインティングだとどうでしょう？
マウスに相当する相対位置指定デバイスは、おそらくUFOキャッチャーや工場の天井クレーンのような、 そんな感じのUIになるでしょうが、ペンタブレットに相当する絶対位置指定デバイスは、すなわちマスタースレイブ動作を行うマニピュレータのようなものになるでしょう。
これは、実際の技術の成熟度合いなどによっても差はでるでしょうが、最終的な完成形としてどっちが使い易いかは明らかです。
というわけで、適応がたとえ2次元であっても、私は絶対位置指定デバイス（＝ペンタブレット）の方を推したい。

というわけで、やっぱり私は、タッチパッドではなく、ペンタブレット技術をフリーハンド化したUIの方がいいなと思う。
asakura-tさんの投げかけられた質問への、答えです。

地図帳.org等の位置情報系サイト繋がりで時々お付き合いさせてもらってた増井さんが、実はユーザーインターフェース屋さんでもあったと知りまして、手の痺れに悩む者として「なんか手に負担の少ないUIないですかねー」とかお聞きした事が最近ありました。
その時教えてもらった「相当障害の重い人向きのUI」というのがあったんですが、これすらマウスは使える事が前提なんですね...。

私の場合、キーボードだけでなく、マウスも結構辛いんですね。
代用で使っているペンタブレットも、マウスよりは若干ましですが楽だとは言い難い。
それで、いかんともし難いなー、なんかいいUIのアイデアないかなーと思いつつ、指をタブレットの上でくるくる回してたらひらめいたんですけど、
ペンタブレットの技術を使って、指先にペンタブレットのペン先相当の電子デバイスを装着し、タブレットの上で指を動かせば、手指にやさしいUIになるんじゃないかと思いました。

具体的なイメージを示す前に、まずなぜマウスが手指にきついのか、というあたりを考察したいのですが、

マウスの場合こんな感じでしょう。
飽くまで主観的な分析ですけど（とはいえこの状況と10年以上付き合って経験が積みあがってきた上での感覚なので、それほど間違ってるとも思いません）、
手首を上方向に持ち上げた体勢でモノを長期保持しつつ、その中でパルス的にかつ頻繁に、手首の緊張方向とは力の流れとして逆の方向の力を指にかける必要があって、これがすごく手・指にとって負担になるんですね。
この緊張状況が首の変型による首-肩ラインの緊張と神経圧迫がある ために、小さな手先部分の緊張→神経圧迫で苦痛が増幅されるために痛み・痺れと感知→耐えるためにさらにあらゆる箇所が緊張、とネガティブフィードバック を起こしている、というのが主観的な症状の流れです。

息子の幼稚園に週1回から2週に1回くらい、英語の先生が来るのだが、その先生に教えてもらったと言って「ロンドン橋落ちた」の節で何か歌っているのだが...。
「へろへろ爆笑ね、爆笑ね、爆笑ねー」

爆笑ねって何やねん！
見当がつかんので直しようもない。

ところが2、3日経って初めて最後までの節を聞いた。
「爆笑ねー、まい、ねー、（息子の名）」

「Hello, Hello, What's your name? ... My name is (息子の名)」かい！

ところが今度は「What's your nameなの？」と聞いても「違う！爆笑ね！」としか歌わない。

• 本当に「爆笑ね」と聞こえているのか？
• 何のこっちゃ判らんかった時におもろいのであまりに「爆笑ねって何やねん！」と刷り込んだので、刷り込まれてしまったかはたまたずっとふざけているのか
• 或いは「What's your name」じゃない、別の言葉なのか？

はてさて真実やいかに。

表題のような事、ここにネタリストとして書きつつ、まだ記事にできてなかったんですが、Mapping Hacksの中で全く同様に、QRコードに位置情報を埋め込んで世の中に貼りまくろうぜ地理情報グラフィティギャング共!というクレージーな記事を書いている人を見つけました。
フィンランドで、ノキアで働いている人らしいんですが、なんか日本の事にも詳しいようで、日本ではQRコード対応の携帯電話が溢れているから云々、みたいな話を書かれていました。

私のアプローチと違うのは、私はとりあえず位置情報のポータルのようなサイトを作って、そこへの経緯度情報付のアクセスURLをQRコード化して世の中に貼りまくろうぜ!とか煽るつもりだったんですが、彼の場合はGeoボキャブラリを埋め込んだRDF記述をQRコード化して、それで街を埋め尽くそうぜ!とか言ってるあたり。
それで、そのRDFを解析するアプリ（携帯ならJAVAとかBREWとかで）を作って、活用しまくろうぜ、と主張しているんですが、逆にそれができる現場(＝日本)にいる身からだと、そんなJavaやBREWでQRコードを扱うようなアプリは、ほとんどのキャリアで公式サイトを持ってる法人しか作れない事が判っているわけで、そうなると（そうできた方が汎用性が高いと判っていても）そういうアプローチは取れない、
というよりはそういうアプローチを待っていては（このアイデアに乗ってくれる法人をみつけるまでは）何時までたっても動けない、と思うので、次善として位置情報ポータルを作って、そこに位置情報を取り合うRESTインターフェースを持ったサイトがUDDIのような形で取り合いのインタフェース形式をそのポータルに登録して、そこをハブにしてユーザがQRコードから位置情報を得ていろんなサイトで利用できる、といった構成を考えていたのですが、
でもせっかくみんなを煽って日本中にそんなインフラを作ろうとするなら、どうせなら将来にわたって使える汎用的なインフラ（＝標準化されたデータ）の方がいいわけで、そう考えると理想と現実の間で中々悩ましいもんがありますね...。

とりあえず、コンタクトしてみようかな。

APIの公開で使い易くなった事もうけて、あちこちの位置情報系サイトでGoogle MapsのHACKが進んでいるようです。

まずはポジタルさん。
位置情報を含む投稿等があれば、Google Maps APIを使った画面に飛ぶようになっています。
SNSなもんでちょっとご紹介するページが用意できませんでしたが...。
ナニゲにGeourl/Geoボキャブラリ入りのRSS対応なんかもされていて、すごい。

ちなみにお聞きしたところによると、ポジタルの作者さん、SNSとか入った事ないのに評判等を聞いての想像だけでここまでまとまったもん作られたそうです。
なんかすごい構成力ですねえ。
Mixiにお誘いしたので、そこから色々刺激受ければさらに進化していくかも。

でもってLAND HERE BLOGさん。
自前で運用されているPingサービスのGPostへの投稿を、Google Maps APIでマップしたようです。
（今のところ、IEのみで動作）
すごいのは、Ajaxを使って、いち早くスクロール後の切り出し範囲の動的更新に対応しているところ。
ぐりぐり動かしていけば、新しいネタがどんどん現れてきます。

最後に古株の、ULSE作者であるjm@fooさん。
ULSE上のデータを、Google Maps APIでマップしたようです。
オリジナルのULSEよろしく、バルーン中に記事中の画像等もちゃんと上がってきて、素敵です。

こうして見るに、リンク先で挙げられている参考サイトを追っていくだけでも、かなり勉強になりますな。
この後も面白いのみつければ取り上げて行きたいので、とりあえずその１という事で。

いろいろ話題になった地図本発売ラッシュですが、やっと一冊目のMapping Hacksが届きました。
日本のHACKS系本の軽快なイメージでいたら、意外とずっしりと重い本です。

Mapping Hacks (HACKS)

posted with amazlet at 05.07.07

Schuyler Erle Rich Gibson Jo Walsh
Oreilly & Associates Inc (2005/06/01)
売り上げランキング: 60,191

Amazon.co.jp で詳細を見る

まだ流し読みしかしてないですが、自分のFOAF関係をRDFMapperで地図表示してみませうとか、事前の評判通り、Map-Toolの詳しい解説本というよりはHACK本由緒正しく「こんな面白い使い方」本な感じですね。
アメリカにはジオコーディングのXML-RPCサービスがあるというのは驚きました、激しく便利そう（以前も聞いた事あるような気もするけど）。
＃日本でもMapFanをHACKすればジオコーディングできるというのは秘密にしておいてください

昨日の宮川さんGoogle Maps API HACK、とりあえずGeoボキャブラリ対応にしてみました。
といっても私は何もやってません...XML::RSSのRDFモジュール名を変更しただけ...。
私が1から作るとなると、XML系モジュールなんかで文字参照がいやーんになっちゃうよーとか、使い方判らんーとすったもんだした挙句、誰も拡張できない（というか見せられない）ものになってしまうのは請合いなのですが、やっぱちゃんと判っている人が作ってると拡張性も比べもんにならないですね。
今回は書き換えただけですが、上位のラッパと自動判別機構とか追加してやればgeourl、Geoボキャブラリ...なんでも対応できそうです。

とりあえずこちら。サンプルはこちら。神崎先生のとこの位置情報付きRSSを読み込みさせてもらってます。

ちょこっとしか変えてないので、オリジナル版と同様当然ソースが見れます。本当に少ししか変えてないので見る意味もないですが。

Google Maps API hacks - blog.bulknews.net

geourl モジュールをつかって緯度経度がプロットしてある RSS を食わせると、そのアイテムを Google Maps にマップします。

SixApart宮川さんのGoogle Maps HACKきたーーー。
しかも位置情報つきRSSのHACKなのでナニゲに嬉しい。

GeoURLもRSSへの経緯度追加拡張を出してたんですね。
考えたら位置情報サイトでRSS出してたんだし当然だったのかもしれないけど、ノーマークですた。
特に2.0以降。

ソースも公開されているようなので、遊ばせてもらおう...というか、前書いたの、読み込みデータ範囲をGEOボキャブラリやG-XML、ISO6709に拡張するだけでできてしまうのでは。

#ところでWhere 2.0って何？

今日会社と、会社と、会社を会議すればよかった？
今日はネットで会社を会議すればよかった？
大きい会社など言ったよ
と、ねねは考えてるはず。

*このエントリは、BlogPet(ブログペット)の「ここ」が書きました。

他に書くべきネタもあるし
首や手の体調も最悪だし
週末に持ち帰ってる仕事もあるし
（というか月曜朝に必要な資料の元ネタを金曜夕方に出すなよ金曜は子供迎えに行くから早く帰ると行ってるのに、と言いたいアレもあるが資料の要求者と元ネタ提供者は別人だし提供者側はむしろ協力してもらってる側だから文句は言えない）
こんな事してる場合じゃないんだがそこはそれ逃避行動という奴で

半年ほど前にパーツほとんど総入れ替えしたPCのスペックが、結構気に入っているのでいっぺんまとめてみた。
まあ飽くまでうちで出せる程度のレベルでのスペックだけれども。
そのついでに最近楽天アフィリエイト始めたので全部にアフィリエイトリンク付けてみた。
アマゾンじゃPCはリンク作れても、CPUの1つ1つの機種とかまで細かいもんは売ってないからねえ。

というわけでうちのPCのスペック公開??。

Google Mapsで自分ちを探そう！とかみんなやってるみたいだが、俺ン家はまだ衛星写真が古すぎて写ってない（建物の形の基礎だけあったけど）ので、大阪時代の家でも探してみるか...と見てみると...

ない！
大阪には詳細地図がない！
全くない！

なおっきさん報告のとおりズレまくりとはいえ、名古屋には一応あるのに...。
まさか日本第2の都市を差し置いて、第3の都市を優先させたとは思いにくい。
というわけで、おそらくGoogle Mapsは、世界的なサイト、という事で、万国博覧会優先シフトを敷いたのではないかと。

どっちにしろ、ズレまくっている事に変わりはないのでorzですが...。

最近はおもろいもんあんねんなー。
というか、こういう純粋なアイデアもんは大好き。

らくがきこどもせっけんだって。
石鹸の成分で、色つきのクレヨンみたいになってるの。

こんな感じで、お風呂の壁に落書きができて、後で洗い流せるの。
お風呂が楽しくなりそう。
＃ちなみにモデルは我が息子ですが、激しく謎トーマスは拙作です。

ただし、石鹸なので、気をつけて。
遊んだ後そのままお風呂場に置きっぱなしにしておくと、次回はスライムとして遊ぶ事になるかも。

先の心の叫びのエントリにhogemanさんがコメントをくださいましたが、

ところで以前一部で話題になってたKDDIの特許はどうなてんでしょうかね。
http://www.kddi.com/corporate/news_release/2004/0219/

た、確かに...Google Mapsを使った情報の重ね合わせって、もろ引っかかりますね。
しかも、これって日本だけでなくアメリカでも特許成立（2000年8月に米国における特許 (特許番号6107961) が既に成立）してたのか...。

でも、考えたら、以前、goSVGとGoogle Mapsが協力し合えばすげえパラダイスになるかも、的なエントリを書いてる関係上、個人的には嬉しい兆候かも。
そのgoSVGの総本山ともいえるKDDIがこの技術に関して特許持ってて、かつgoSVGでの利用においてはロイヤリティを問わない、といった宣言をしている関係上、これはGoogleがgoSVGに興味を持つよいきっかけにならないか。

Googleの方にしたって、単にロイヤリティ回避といったマイナスの効用だけではなくて、
今のところネット上では、GeoボキャブラリのようなGIS的に扱えない単なる点の記述方法以外に、事実上標準が存在しないため、Google Mapsでいろんな位置に関する情報を発信する、といってもそれは個々のHACKERの独自データ形式での単独HACKレベルでしか不可能という現状があるところを、
goSVG（G-XML）のようなGIS的に考えられた位置情報記述を標準として採用する事で、いろんな市井ユーザが自由に位置ベースの情報を発信できて、それを巨人Googleが収集して提供できる、という経路ができるきっかけにならないか。

もちろん、goSVGはSVG上の規格なので、今のGoogle Mapsにはそのままでは載らないけれども、Google Mapsに位置情報を重ね合わせる時のデータ規格を、goSVG及びその元規格であるG-XMLのボキャブラリから採用するとGoogleが決定すれば、KDDIの方もロイヤリティに関する主張は取り下げる、といった契約が両者の間に交わされれば、位置情報を使った情報発信が簡単に行える時代が遂にやってくるかもしれない。

超楽観的将来像だけど、本当にそうなればいいなあ。

Google Maps API

なんてのも出てたんですね。
早速取るだけ取ってみましたが...。

旧社の製品で親友が手塩にかけたソリューション、SpaceTag Serverが世に問われて、2005年2月1日が公開日だったはずだから、今日でちょうど5ヶ月になる。
そろそろ、製品のライフサイクルから見て、マイナーバージョンアップ等次の動きがある頃だと思う。
それにあわせ、私もこれまでこのソリューションを普及させるべく、マンセーの宣伝ばかり行ってきたわけだけれども、今回はちょっと今後の成長に期待すべく、自分が体験した実話も踏まえ、現バージョンの問題点を指摘したいと思う。
もちろん、どんなよいソリューションでも端から成功するものなんてまずありえない、Windowsだって3.1から普及したんだし、Movable Typeも（多分日本では）2.6からやっと広まりだしたのであるから、私のこの指摘も、貶める意味合いではなく、これを乗り越えてバージョンを上げていく事により、よりよい製品になって欲しいと願って書くものだ。
その辺は開発者の親友は百も承知であるし、経営陣も過去に一度、多大な資本を投入したソフトウェアをその後何年もメンテナンスもバージョンアップしなかったがために単なるゴミにしてしまった苦い経験を持っているだけに、身に染みて判っているはずであるから、SpaceTag Serverに関してはすばやいバージョンアップ体勢を敷いてくれているものと期待したい。

現状のSpaceTag Serverの最大の問題点とは、ずばり書いてしまうと「顧客として誰をターゲットにしているのか全く判らない」事だ。
というか、偉そうに書いてもそんな話は現場では私が居た頃から出ていた話ではあるけれども、とりあえず開発リソースも限られている中、第1弾は完成して動くものを世に問う事で精一杯で現在のような形になっているわけなんだけれども、既に世に出て5ヶ月、そろそろターゲットを絞ってこの問題をなんとかしないとちょっと将来が心配な感じだ。