![[ここｷﾞｺ!]](http://kokogiko.net/logo.png){kind=logo}
2005年07月30日
隅田川花火大会from秋葉原
秋葉原から隅田川への距離とかあまり判ってなかったが、この距離ではかなりしょぼかった。
...とモブログでは書いたが、後のほうで打ち上げ箇所が複数になって、連射とかが入ってくると、一望できる分結構すごかった。
2005年07月30日
南米音楽のストリートパフォーマンス
Mailogは動画もOKだったっけのテスト → 駄目やったね。家のネットが復旧しだい後で挙げよう。
昔はこんなの見る度に足を停めていたもんだが
余裕のない人間になったもんだ
今日は待ち合わせだから聞いてるけど
【GPS情報】
http://walk.eznavi.jp/map/?datum=0&unit=0&lat=+35.41.55.53&lon=+139.46.21.21&fm=0
2005年07月28日
So-net光 心の底から逝ってよし！
家内に聞いてみると、前から申し込んでいたSo-net光マンションタイプの、共用部分の工事が完了したとの案内が届いたとの事。
色々ケーブル引き込みに当たっての予期せぬマンション構造の問題等、不都合があったらしく、予定より一月半近く遅れた工事がようやく完了したらしいのだが...。
（以下、意訳です）
お待たせいたしておりました、光ケーブルの引き込み工事が本日完了いたしました！
工事完了後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ほんまにうっといね。
＃誰も「貴婦人との交際を楽しんでいただくために」貴重なパケット代払う気なんてさらさらないんだけどなあ...。
＃やっぱサーバで対処しないとアレかなあ。
2005年07月27日
衛星写真や、地図にも更新情報をつければどうか
MSNも地図サービスをはじめたと言うのは知ってますが、触ってみて琴線に引っかからなかったのでスルー。
順/逆ジオコーディングAPIが提供されたとか、そんなGoogle Mapsの諸機能並みにエポックメーキングな情報でも入ってこない限り、ちょっとパス。
でもこんな話題があったのでちょっと取り上げてみる。
Microsoftの新しい「Virtual Earth」サイトでApple本社を鳥瞰すると、11棟の近代的な建物が美しい中庭を囲んだAppleの広大なキャンパスではなく、特徴のない倉庫1棟とさびれた駐車場に見える粗い航空写真しか見えない。
Microsoftは、これは写真が古いためだとしている。
.........
衛星専門家の1人は、インターネットユーザーがこれらの画像を理解できるよう、各社はそれぞれの写真の日付など、もっと詳しい情報を提供するべきだと指摘している。
わざとか、わざとでないかは、多くの人にとって欲しいのは真実ではなくネタ？なので別にいいんだけど、最後のとこの「それぞれの写真の日付など、もっと詳しい情報を提供するべきだ」ってとこ、
一つの案として、せっかくインタラクティブなUI採用するために衛星写真も細切れになっているんだから、それぞれの画像毎にHTTPヘッダのLast-Modified属性や、或いは新属性として、撮影日時の情報を提供するというのはどうかな、とオモタ。
他にも欲しい情報としては、どこの衛星の撮影画像か、とか辺りかな。
要するに付加情報はHTTPヘッダで送っては、というアレなんですけど、どうですかね。
複数の画像がマージされた画像はどうするかとか、鬱陶しいアレもありますけど。
あ、後タイトルに書いときながら言及忘れてましたが、地図も何時までの情報が更新されているか、とか属性情報としてあったら嬉しいですな。
2005年07月26日
携帯版Googleローカルをベースに、街角QRコードを作っちゃうのはアリではないか
私やMapping Hacksの中の人が提唱している街角QRコードですけども、リンク先のエントリの中でも書いたとおり、アンビバレントな問題点があって、
- 単なる汎用的な位置情報を埋め込んだQRコードだと、Java/BREWアプリなりを開発しないと活用できない（そんなもの、誰が作ってくれるのか？）
- 特定のサイトへの位置情報リンクを埋め込んだ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題
位置情報関係のHACK4題です。
まずはMapServer関係のHACKから、Nakamura-KU ADDICTさんとこで、自分のサイトを訪れた人の所在地（国）をGeoIPで解析して、訪問者数を色の変化で表してくれるHACKが公表されてます。
GeoIP + Shapelib + MapServerで国別の主題図
GeoIP(Python) + Shapelib(Python) + MapServerでApache logの国別の主題図を作ってみました.
Blogを飾るマスコットとしてなかなかかっちょいいです。
うちで導入してから紹介しようと思ってたのですが、pythonなので慣れてなくてなかなかうちでは環境が作れないので、お先に紹介しました。
一応うちで掴んでる限り、
アタリをインストールしないといけないみたいです。
これだけでよいかは、まだ環境作成に成功していないので不明ですが。
あ、もちろん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。
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転。
もうちょっと事前に計画してから物事進めるようにしましょう ＞ 俺。
2005年07月25日
Google Mapsの疑似日本測地系とかいうアレに関する勘違い
Google Mapsの日本近辺測地系は、世界測地系を平行移動しただけの疑似日本測地系だという話があったけど、
俺も最近まで勘違いしてたけど、それは飽くまで世界測地系で作られているサテライトモードの画像の話であって、
元々日本測地系で作られているZENRIN地図上にプロットするにあたっては、疑似どころか正真正銘の日本測地系なわけですな。
よってHACKするにあたっては、よくあるGPSデータなんかを日本地図上にプロットするような場合は、正しい世界測地系のデータを正しい日本測地系へ変換するのだから、平行移動ではなくある程度まともな測地系変換が求められるはず。
サテライトモードを主用途と考えているか、或いはマップモードが主用途でも、判ってて誤差が出るのは覚悟の上で計算負荷を抑えるために平行移動を採用するのはいいけど、マップモードを主用途にまともにやりたいと考えているなら、まともな測地系変換すべきだろう。
そうなるともっと厄介なのは沖縄。 大間違いでございました。
沖縄地図が世界測地系で表示されるのは、沖縄だけまともに日本測地系→世界測地系変換された地図データを持っているとは考えにくいから、恐らくはサテライトモードでの日本本土が「疑似」日本測地系になっているという逆パターンで、日本測地系地図を単純に平行移動しただけの「疑似」世界測地系地図として提供しているのではと思われる。
（飽くまで推測だが確度は高そう）
もしそれが正しければ、正確な世界測地系で得られたデータを沖縄マップに正確にプロットしようと思えば、一旦まともなやり方で日本測地系へ変換→平行移動で疑似世界測地系へ変換、と二段階を経なければいけない事になる。
最初に書いたとおり測地系に関する問題をマップモードとサテライトモードで混同していたので、自分で確認せずに沖縄のマップモードも世界測地系、と思い込んでました。
そうですか、沖縄はマップとサテライトで400mもずれてるんですか...これは酷いですね...。
まとめると、
日本サテライトモード：疑似日本測地系
日本マップモード： 日本測地系
沖縄サテライトモード：世界測地系
沖縄マップモード： 疑似世界測地系日本測地系
になっているのでは、という事。
ああややこしい。
さらに邪推を進めれば、デュアルモードの投入で日本が出遅れてる事について、ベクタデータを今手配しているのかなあ、とか書いたけど、
もしかするとこの、サテライトモードとマップモードの測地系の違いのせいで、デュアルモードがうまく重なり合わないのが遅れてる原因なのかもしれない。
Nowralさんの変換式ページを見ると、行列計算を交えたある程度マシな変換を用いてさえ、場所によっては5m近い誤差が出るとの事。
5mといえば、中程度の道ならば道幅一つ分くらいは軽くずれるという事です。
これが単なる平行移動だと、どれだけド派手にずれてくれる事か…。
日本のデュアルモードで、小縮尺では出てくる県境データ等さえ、大縮尺になると消えてしまうのは、案外この辺が理由かもしれません。
もしこの推理が正しければ、さすがにGoogleも、日本版のデュアル提供前に、測地系問題に関する最終解決を投入してくるんじゃないかと思いますけどね。
煙草。(BlogPet)
きょうは、煙草を約束したいです。
*このエントリは、BlogPet(ブログペット)の「ここ」がHS' Blogを読んで書きました。
2005年07月23日
改めましてWeb Mapping、Mapping Hackお勧めです。
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のデュアルモード、USA・UK地図は街区まで
Google Mapsの地図/衛星画像の投影法一致、したのはいいんだけど、地図のメルカトル図法の方に揃えたのね。
衛星画像の 正距円筒図法（？）に合わせて欲しかったな。
巨大な南極大陸にとてつもない違和感が。
まあメルカトルだと局所局所の経緯度の縮尺比が一緒になるはずだから、グローバルに提供するローカルサービスとしてはいいのかもしれませんが。
それはそれとして、日本だと県界・主要都市の位置レベルで、大縮尺にすると衛星画像と一緒になってしまうGoogle Mapsデュアルモードですが、USA・UKで表示してみると、なんと街区レベルまでオーバーレイされていました！
すごい...ラスタ画像にベクタ地物の重ね合わせ...もうこれは完全にGISの世界ですね。
Google Maps APIでも、そのうちベクタ情報の重ね合わせに対応してくるかもしれません。
（今でもGPolylineクラスとかはありますけど）
そうなってくると、ますますGeoボキャブラリやGeoURLでの位置埋め込み等では力不足になってくるので、GML、G-XML、goSVGあたりと繋がってきそうな感じがします。
日本でも、今はベクタ地図を入手中、くらいのフェーズなんでしょうか。
いずれ投入される事は間違いないでしょう。
楽しみです。
Google Maps、地図と衛星画像の投影法を一致、デュアルモードも導入
この辺に触発されて（というか同じ事考えてたんだけど先越された感じですが）GPointクラスが日本測地系でも世界測地系でも扱えるよう改造中なのですが、
（で、やっぱり俺のやる事なので遅々として進まないのですが、）
その動作チェック中に突如、いつもの「マップ」「サテライト」ボタンに加えて、「デュアル」のボタンが出てきました。
なんじゃこりゃ？と大縮尺のモードで切り替えても、どう見ても単なるサテライトモードで、何も差がない...。
何だろうと色々切り替えているうちに、何かおかしい事に気付きました。
マップモードとサテライトモードで地図の投影法が違うために、今まで重ならなかったマップモードの地形とサテライトモードの地形が、完全に重なるようになっている！！
すげえ！何時の間に！日々進化してるぞGoogle！
でも、デュアルモードって？
その謎は、小縮尺にしてみて解けた。
答えは、地形として衛星画像を表示した上に、地名や行政界等をオーバーレイしたものでした。
すごく面白い。
ほんとについさっき、何度かリロードしてる時に突如変わりましたよ！
この開発速度、そして素早い実サービス展開...マジ気合入ってるんだなあ。
日々勉強してるんだろうなあ。ちょうどWeb Mapping Illustratedとか発売されたところだし。
2005年07月21日
位置情報SNS「ポジタル」がMixiへの現在地通知に対応
位置情報SNS「ポジタル」にMixiへの現在地投稿機能等、Mixi連携機能が追加されたようです。
mixiの日記をMyブログに取り込んだり（RSSリンク自動生成）、 mixiの自己紹介欄へ現在位置への地図リンクを自動で張ることができます。
早速試してみました。
確かに、プロフィールページの一番下に、現在地へのリンクが張られています。
これはMixi仲間に今いるところを通知する方式として、中々面白いかもしれません。
できればリンクだけでなく、住所も直接載った方が判りやすく面白いのでは？とも思いましたが、その辺はプライバシーの問題とかも絡めているのかもしれません。
リンク先はポジタルの地図表示ページのようなので、そちらならばポジタル内でも仲間同士のユーザでないとアクセス不可になるとか、そういうプライバシー配慮なのでしょうね...。
mixiの認証情報は、サーバには一切残しません。
利用者がお使いのブラウザのクッキーへ認証情報（IDパスワードではありません）を保存します。
クッキーを利用できない携帯電話には対応していません。
という事ですが、この辺はCookieの使えないキャリアは今でも決して少なくはないはずなので、ちょっと残念。
でも、画面メモの機能とかをうまく使えば、サーバサイドでデータを保存しなくてもやりようはあるはずなので、その辺また開発者さんにレポートしてみたいと思います。
2005年07月20日
韓国は日本測地系と世界測地系の混在だそう
先のエントリにトラックバックをいただいた。
Googleマップの測地系について - Watching from Yokohama
ここで話題の韓国は日本の占領下から引き継いでいた旧東京測地系とKTRF2000といういわゆる新測地系が混在している。
韓国の国土地理情報院も2種類の測地系での地図提供を行っている。
最終的には2006年12月31日までは後者に移行することになっている。
なるほど。
東京測地系は明治時代からという事ですし、韓国の測量も占領下でかなり進んだはずなのでその可能性も感じてはいたんですが、一方で米軍との連携もあるので世界測地系なのかなとも思っていましたが、混在しているんですね。
でも判らないのは、
日本では、世界測地系で地図資産を蓄積している信頼できる地図会社は無いため、今回のような問題が発生してしまうのだ。
というあたりなんですけど、単純に「地図は旧日本測地系だけど、サーバサイドでの座標変換で座標指定は世界測地系」というわけにはいかないんでしょうか？
確かにマジで変換テーブル使って正確な測地系変換しようと思うと大変なんでしょうし、計算だけの簡易変換だと多少のズレは生じるのでしょうが、とは言ったってその程度のズレなんて、沖縄が日本に入ってなかったり、中国で日本測地系になったりというような失態を演じるよりは、簡易変換で多少ズレ、の方がまだマシなんじゃないかと思います。
世界的なグローバルサービスを目指しているはずのGoogle Mapsなんですから、いずれは世界測地系にしなきゃいけないと思いますし、それならまだベータ版なんですから多少ズレていてもOKとして、その間に世界測地系地図を準備してもらうという形で、将来にツケを残さない方法をとった方がよかったと思うんですが...。
日本でだって混乱を引き起こしただけで双手を挙げての歓迎はされたわけではなかったし、沖縄なんかではGoogleのイメージダウンに繋がるだろうし、韓国はともかく中国なんかでは、私も「Google的日本測地系帝国」に属してしまっている大連に友人いますけど、せっかく同じようにGoogle Mapsにはまっている連中がいたとしても、みんなあきれて離れてしまうんじゃないかと心配します。
現に同じようにZENRINの地図を使っているはずの沖縄では世界測地系で配信しているという事なのですから、同じように日本中で世界測地系で配信する、という事はできなかったのでしょうか。
元記事さんの別のエントリでは
いずれにしても、ゼンリンの地図、タウンページデータベースという国内で購入できる最も高価で信頼性の高いコンテンツを最初から惜しげもなく投入したということは、生半可な発想では取り組んでいないということを如実に物語っている。
と書かれていますが、でもそれにしてはこの対応は、天才集団Googleらしからぬ拙劣さを感じます。
なんか別の思惑があるんでしょうか...。
Google Maps /w goSVGキターーーーーーーーーーーーーーーー
といっても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コンテンツの展示会とか行って概念は理解しているつもり（超思い込み）だけど、詳細仕様はこれからお勉強なのでうーん先は長いなーと思ってたら、
もうやってる人がいたわけなので、安心してお任せして、私は相変わらずの口から出任せに徹せられるわけですな。
というか、偉そうですな。＜俺。
すみません、いろいろ勉強させてください ＞ 暇人的な人
2005年07月19日
Google Mapsでは独島がどうとかのレベルやないです
韓国から無事戻ってまいりまつた。
レポートとかは余力があればおいおいやるとして。
そのレポートに位置情報はっつける際に関わる問題として、Google Mapsの測地系は韓国では日本測地系らしい。
世界測地系で場所調べても、わざわざ変換かまさんとはっつけられへんやんけ。
おまけに沖縄は世界測地系との事。
具体的な日本測地系/世界測地系切替の領域はこんな感じらしい。
沖縄、朝鮮半島、旧満州、千島、南サハリン...単純に経緯度で切っただけなんだろうけど、見事なまでに政治的にすんげー微妙な、あちこちの逆鱗に触れかねんあたりをばっさりと。
もうちょっとうまくやってくれー。
サーバサイドでなんとかならんかったのか。ほんま。
####追記####
げ、しかもGoogle Mapsが使ってるの日本測地系じゃなくて、
Google Mapsが北緯30度から50度までと、東経115度から152度の間にある地点は世界測地系を単純に平行移動しただけの擬似的な日本測地系を使うように変更されています。
とか書かれてるで。
マジか。
衛星写真でこそ不正確な位置でもアレだったかもしれんけど、せっかくゼンリンのあれだけ正確な地図使ってるのに、そんなんやったら場所によっては10mくらいは軽くずれるんじゃないの？（未検証）
2005年07月18日
うちのにゃんこ(BlogPet)
きょう、エントリにblogするつもりだった？
*このエントリは、BlogPet(ブログペット)の「ここ」が喫茶「ふるさと」を読んで書きました。
2005年07月16日
無事つきました
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面白そうなので触り始めました。
やってみるなら、ここ超便利。
2005年07月15日
MovableType向け位置情報プラグイン
昼休みも終わりつつあるのでリンクだけですが、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とかも楽勝ですな。
私も週末明けくらいにでも導入してみたいと思います。
HDML<->XHTMLゲートウェイ 身近だった開発者に感謝
最近大学時代の同期でKDDI研究所に行った奴がMixiに入っているのを知って、マイミク登録したんだけど、
そいつのポータルで公開されてた研究テーマ履歴に
Webページ適応変換プロキシ試作
とあったので、もしやあの、世のEZwebサイト開発者の開発工数を大幅に削減し、睡眠時間、家族との安らぎの時間、飲んだくれる時間を提供してくれる事となったHDML<->XHTML変換ゲートウェイは、彼奴の作りしものなのかっ？と思って聞いてみると、そう、との事。
正確には、本人いわく、試作しただけで実際に入ったのはベンダーに作らせたもの、と言うことだけど、原理は彼が作ったわけで、その意味で彼が生みの親と言う事は間違いないだろう。
いやあ、俺もむちゃくちゃ世話になったクチだけど、すげえ身近な奴が作ってたんやなあと感動。
彼に足を向けて眠れません（未検証）。
こっちは俺はほとんど世話になってないけど、
動画像適応変換プロキシ試作
動画像適応変換方式の検証
というのもいろんな人にありがたがられてそう。
漏れもこういう世の人の生活に何気に役立つもんを作ってみたいでつ。
というか、ここまでこっち方面のアレがやってみたくなるなら、素直に就職時にKDDIとかDoCoMo選んどけばよかったなあ。
何を血迷ってクボタなんかにしたんだか。
まあ基本的に発想がユニバーサルサービスなので、キャリアに入ってたら入ってたで苦悩もあったとは思うけど。
週末、韓国行き
京都で（なんで？家は五反田のはず...）大学院生をやっている家内ですが、今度の連休最終日の月曜から数日にかけて、韓国ソウルで学会があるという事で、
「行きたいンやけど、息子昼間見る人がいなくなるから、会社休んで一緒に付いてきてくれへん？」
「アホかーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーい」
んでなんだかんだで百歩譲って、行ってる間は、息子の幼稚園の延長保育フルに利用して、送迎を俺が引き受けて、家での子供の面倒や最低限の家事もその期間は俺が見る、という事で話が一旦ついた。
んだけど...。
家内が電話で現地ホテル従業員と交渉したりしてるのを傍で聞いていると、むらむらと行きたいという気の迷いが...。
そこでつい、一時の感情で「連休の間だけ付いて行ってええか？」。
という事で連休は韓国に行く事に。
しかし後で激しく後悔。
これだけGoogle Maps周りとか激しく面白く動きそうな時に、しかも自分の生活が週末以外ほとんど何の取り組みもできないような状況で、せっかくの連休をこんな何の計画もない韓国旅行でなんで潰さなきゃならんのかと。
おまけに家内の選んだ宿、自分だけで泊まるための安宿で取ってたみたいだから、ネット環境なんか望むべくもなさそう。
うー、なんで行きたいなんて言っちゃったのか。
でもまあ今更言っても仕方ないので、まあ行くなら楽しんできますが...。
3日間の間に世の中がどう動くのか、（涙ながらに）楽しみにしてまふ。
携帯電話でもGoogle Maps！（取り扱いには...）
こんな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を解析したりとかで、地図を移動して戻ってきた結果をサイトで反映したりとか、面白い利用法もできそうな予感。
試せてないですけど、どなたかレポートもらえませんか？
2005年07月14日
非位置情報サイトの位置情報化も進んでる(2) --というか某位置情報サイトが遅れてる編--
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 Maps 日本地図に対応
動きが早すぎてついていけない。
うちのコメントでも、
深読みで根拠はありませんが Googleが日本測地系をサポートしたのはアルプスマップさんとかMapfanさんあたりの日本測地系の地図を載せる前のテストだったりしませんかね？
とかいただいてて、ネット上の反響もおおむねそんな感じなので「みんな考えることは同じですねー」とかなんとかのほほんとレスしようと思ってたら、もう対応してしまった。
日本の地図がGoogle Mapsに登場 - ふと思う--ちょっと考える （いたずら編）
Google Mapsの測地系が変わってしまったんだよなと思いながら「Google MapsがTokyo測地系に変わったらしい(fumiakiyの日記)」を読んでいたら、maps.11.jsにZenrinなる文字列があるというコメントを見つけました。
早速、物はためしとGoogle Mapsを開いていつもは無視の｢マップ｣ボタンをクリック。
そこに現れたのは間違いなく日本のどこかの地図。建物の形が細かく入っていて、まさにゼンリンの地図です。
そういえば、俺も日本測地系の確認してた時にZenrinってみたような気がする。
意識の外に飛ばしてたけど...。
でもゼンリンか...。
前の仕事つながりで名刺は何枚かあるけど、一番縁遠いとこだな...。
2005年07月13日
逆Geocoder（経緯度→住所）のRESTサービス
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 >
うひょー。
かっちょえー。
Web Mapping Illustratedも発送されたっぽいです。
Mapping Hacks (HACKS) が出て1週間経ってませんが、
5月末に発売予定のままその後どうなったかよく判らなかったWeb Mapping Illustratedが、注文状況を確認すると昨日発送されたっぽいです。
Google Mapsの盛り上がりの真っ最中という事で、偶然とはいえほんとにここに来て急に何か動き出したという感がありますね。
Oreilly & Associates Inc (2005/06/30)
売り上げランキング: 86,549
Google Maps APIが日本測地系に対応...しすぎじゃコラ！
Google Maps APIでの経緯度指定が、日本では日本測地系になったらしい。
詳しい仕様はよく判らんけど、ちょっと調べた＆触った限り、「日本測地系が選べるようになった」ではなく「日本測地系になった」っぽい。
なんか意味判らん。
中の人も「よい方法とは思わない」見たいな感じで書いてるみたいだけど、日本でだって画像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.
なんか選択式になったっぽいです。
そりゃそうだよなあ。
2005年07月12日
日本での順逆GeoCode
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で得た町丁目以上の住所を融合させるのはどうかと。
もっとも、街区レベル位置情報だけだと一番近い代表点を持つ街区を選ぶしかなく、どうしても誤判定が出てしまうので、マジでこの方法で正確に出そうと思うと、数値地図の行政界拾ってきてポリゴン判定するしかないけど。
ところで、上に�