極点と磁極点はズレているのだから、極点近くで方位磁石なんかに従ってナビゲートしたら、間違いなく遭難しますから。

と書いて思いついたのだけど、極点近くを探検する冒険家とか向けに、地磁気極を中心とした座標系で描かれた地図とかあったりしないのだろうか。
この地図使えば、極点近くでも方位磁石の指す方向でナビゲートできますよー、みたいな。
そんなのあったら見てみたいな。

ちなみに、磁極点をベースにした座標系というのも、実は宇宙観測の分野ではあったりする。
太陽風の磁力線と地球の磁力線のインタラクションなんかを観測する科学衛星なんかでは、地磁気極が地球の自転軸を中心に1日1回コマの頭振りのようにぐるぐる回っているにも関わらず地球から見て固定の座標系で観測していると、地磁気のどの部分がインタラクションを起こしたのか等がはっきりせず、観測に不都合が出る。
だから、地磁気極の首振りにあわせて、座標系も首振りする地磁気座標系が観測に採用されたりする場合もある。

たとえばこれ、「GSM座標系で表した衛星の軌道」なんて書いてあるけど、およそ衛星の軌道とは思えないふにゃふにゃの軌道になってたりする。
これはこんなふにゃふにゃと軌道の速度方向変えながら飛んでるわけじゃなくて（そんなにΔVしまくったら一瞬で推進剤なくなる）、プロットしてる座標系の方が1日1回地磁気極の首振りに合わせて動くものを使ってプロットしているから。
ちなみに、地磁気の影響を考慮しない、地球に固定的な座標系でプロットした軌道は、同じページの少し下、「GSE座標系で表した軌道」というのがあるけど、そんな感じになる。

本記事、大嘘です。
正確には、ある地点で東を確認後盲目にまっすぐ進んだら対蹠点に着くのは確かですが、常に方位磁石で確認しつつ東に進んだら、確かに緯度に沿っての移動になります。
恥ずかしい話ですが、各地点で対蹠点方向へのベクトルを持つにもかかわらず（実際には持たないのでしたがそう思い込んでいた）、同じ緯度に留まり続けると言うのがどうしてもイメージできず、騒がせてしまいました。
すみません。

日曜日に平成教育学院見ていたら、ビルゲイツの面接試験と称して、南に1km、東に1km、北に1km行って元の場所に戻る地点は地球上にいくつあるか、という問題が出ていた。
答えは、

1. 北極点
2. 南極点から1kmほど離れた地点で、1km南に行った点で緯線に沿って南極点をn周したら1kmになる点、無数

ということで、無数にあるというのが答えらしい。

酷い問題だなーと思ってたら、どうも都市伝説じゃなくてマジでマイクロソフトで出た設問みたい。
ひでえ話だ。これでマイクロソフトは、そのまま雇っていたらWindows Live Localの開発に力になってたかもしれない、地理に強そうな人たくさん落としたのかもな...。

いつから「東に行く」ということが、「緯線に沿って歩く」というようなマイクロソフト独自の定義になったのか。
「東に行く」とは、ある地点を通る南北の線に垂直に、北を向いた時の右手の方向に向かって進むことだ。
この正しい定義さえ知っていれば、「東に行く」と「緯線に沿って歩く」が別概念だという事は、ちょっと図を書いたらすぐ判ることだ。

上のような図さえ描けば、A地点から東へ行くということが、2の方向に行く事ではなく1の方向に行く事だってのはすぐ判るはず。
俺たちはメルカトル図法の平面世界に住んでいるんじゃなくて、まあるい地球上に住んでるんだから。
この正しい定義に従う限り、南に1km、東に1km、北に1km行って元の場所に戻る地点など、この地球上のどこにもない。

さらに救い難いのは、この事実が準常識ではあるものの完全に常識とは言い難く、かつ冷静に論理的に考えればすぐに事実が導き出せるところ。
つまり普段はこんなこと考えた事もなかったので知らなかったけど、マイクロソフトの面接と言う真剣に考えなきゃいけない場面で、マジメに考えた挙句この事実に気付く奴だっているはずだ。
そんな、短い試験時間の間でそこまで考えが回る奴は優秀と言って差し支えないと思うけど、そういう優秀な人材まで、間違った面接試験で落とした可能性があるということ。
マイクロソフト、がっかりだよ。

後、平成教育学院でこの問題の考え方を説明している時に、極近くで方位磁石を持って...とか何とか言っていた気がするのだけど、極点と磁極点はズレているのだから、極点近くで方位磁石なんかに従ってナビゲートしたら、間違いなく遭難しますから。

息子の七五三のお祝いに、近くの氷川神社でお祓いしてきた。

帰り道、家内が千歳飴とは金太郎飴のことであると思い込んでいることが発覚した。
なんたることであるにっか。

お祓いの最中神妙にかしこくしていたので、帰りによったローソンでチョコエッグを買ってやる。
今のおまけは戦闘機シリーズ。

開いてみると、中身は九三式中間練習機 赤とんぼ。
名機であることには異論はないが子供向けお菓子のおまけとしては選択がマニアックすぎるような。
ちょっと乱暴に遊んだら壊れそう。
親の興味としては、ビゲンか百式司偵が欲しかったなー。

ここでも「わー、ゼロ戦だねー」と、家内の適当ぶり炸裂。

金曜日、PLACE+行ってまいりました。
すごく熱かった。
レベルの高さは学会並み、ディスカッションや雰囲気の熱さはYAPCとかのカンファレンス並み、というすごいイベントでした。
レベル高すぎて発言なんて一言もできなかったのはおろか、ポジションペーパーが要求されてるのに当日朝気が付いてまあ適当でいいだろうとへろへろーっと書いたんだけど、他の人のポジションペーパーのレベルの高さを見て恥ずかしくて出せなかったと言うようなこともあったりと、イマイチ参加しきれてなかった私だったりしますが。

次回どうしようか、第2回PLACE+にしようか、それともGADGET+とかMEMORY+とかその他の分野にしようか、みたいな話がありましたが、他の分野も広がって欲しいですが是非PLACEも継続してやって欲しいと思います。
「ケータイ」位置情報マニアとしては、GADGET+も面白そうかなと思います。
そういえば帰ってきて、PlaceEngineやLocky.jpの位置集めに自分も参加したくて、今冬のボーナスでW-ZERO3買ってもいい？とおねだりしたら、貯金ほとんどすっからかんになってる今の家計の危機的状況判ってるのかーと怒られてしまいました...。

で、PlaceEngineの熱さに触発されて、家に帰ってさっそくPlaceEngineクライアントが走っている自PC上から、Perlで自位置を取得するWWW::PlaceEngineモジュールを作成しました。
中の人にも確認したところ、当然無保証だけど公開する分には問題ないという事なので、公開しちゃいます。
PlaceEngineの仕組み上、外部から取ること（サーバ上で走らせて、自PCの位置をトラッキングするとか）はできません。
そのような事がしたい場合、飽くまで自PC上でPerlを動かして、取得後サーバに通知する、という仕組みが必要になります。

また、PlaceEngineサーバ経由で位置を取得すると言うPlaceEngineの仕組み上、自PCがネットに接続していない状況では位置を取れません。
と書くと、実は「それPla」な人がPlaggerのCustomFeedプラグインを作ってくれて、自PC上でPlagger走らせて自分の場所の定時トラッキングをRSSで吐いたりBlogに投稿したりするようなアプリができたりしたら面白いなあ、というのがあってこのモジュール書いたのだけど（Plaggerから先は他人任せ）、そういう用途には微妙に使えない気がしてきました...。
まあ、サーバ取得方式のPlaceEngineに対し、DB提供方式のLocky.jpもあって、そちらはオフラインでも位置取得は可能（ただしDBは定期アップデート要）であり、かつ近日Java版のAPI提供されるようなので、公開されたらちょっと覗いてみて、できそうならWWW::LockyJP（Locky.jpでWWWは変かな？）なんかも書いてみたいと思います。

昨日、知人に教えてもらったんだけれども、まさに今日、なのですが

フェリス・緑園都市 コミュニティーGIS DAY　2006

2006年11月23日（木）午前10時から午後5時まで
フェリス女学院大学　緑園キャンパス　2号館他

こういうイベントがあるらしい。
俺は今日は幼稚園行事なのでダメだけど、うーん、行ってみたかった...フェリス女学院...いい響き...（そういう理由かい！）

さらに明日は、

PLACE+ 新世代ロケーションアウェア技術・サービスに関するワークショップ

# 日付： 2006年11月24日(金) (13:00受け付け開始)
# 会場： 国立情報学研究所　12F 1210会議室

というのがある。
こっちは中の人に教えてもらってずっと前から知ってて、ブログ記事でも取り上げようと思っていたのだけど忙しくて手が回らず。
事前申し込みの定員制なので、今からだと参加不可かもしれず...記事で紹介されてたら行きたかったのにーという人、ゴメン。
私は参加申し込み済みなので、参加予定（足の痛みなど体調が悪くなければ）。

もう一つ、こっちは少し先だけどついでに紹介。

OSGeo財団日本支部設立記念カンファレンス

2006年12月7日（木）　9:45開場　10:15～19:30
東京コンファレンスセンター・品川

こっちは定員250名でまだ少し先なので、今からでも大丈夫でしょう。
ちなみに中の人に頼まれて、私も「ブロガーが見たオープンソースGIS（Where2.0セッション）」で1セッションしゃべる予定です。
が、Where2.0ワークショップと違い、とりあえず中身のある事をしゃべれとは言われておらずここギコの歴史みたいなどうでもいい事をお願いされてるので、別にわざわざ聞く価値はないかと（俺のセッションについてだけを話した場合ね）。
というかそんなどうでもいいお題でもなければ、Web2.0ワークショップとの連日発表はテラキビシス。

書きたいことは数あれど、先週は忙しかったのと、週末が地獄だったので何も書けてない。
何が地獄だったかというと、金曜の帰りあたりから左足が激痛地獄だったのだ。

もちろん原因は再発したヘルニア。
週末の間、数分でも座っている事もできず、ずっと寝たきり。
寝ていても、どんな体勢とっても痛みは治まらない。
流石に初回のヘルニア時の、背骨の激痛よりはマシだが、寝付くこともできず自然に涙がにじんでくるレベルの痛さ、辛さ。
週末を乗り切るのが永遠のような感じを受けた。

何より、いくつか抱えているカンファレンス発表の資料の用意とか何一つ進められなかったんだけど、頭は普通に働いているのに、体がいう事を聞かなくて何もできないという状況ほど辛いもんはないね。

んで今日は朝から病院へ。
ペインクリニックでMRIの予約を取った後、また硬膜外ブロック注射をやってもらう。
脊髄の外膜を伝って、患部に薬液が染み渡るのがよく判る。
そのまま、ブロックの効果が浸透するまで、2時間程度安静に。

ブロックを受けた結果、痛みがかなりマシになった。
少なくとも我慢できないレベルではなくなったので、朝の痛みから考えると全休のつもりだったんだけど、治療が長丁場になりそうなので有給休暇を温存すべく、午後から出勤。
我慢して仕事していると、何故か痛みの質がどんどん変わってきた。
左足の痛みから、背骨の違和感へ変わっていって、背骨は相変わらずなんかガタがきているような、ムズ痛い？ような変な感じがあるんだけど、足の痛みはほとんどなくなった。
ヘルニアの、足の痛みの特徴である、膝を伸ばしたまま足を前へ上げることが痛くてできない、というのも、朝は左足を5cmほど前へ上げただけで激痛が走っていたのが、腰の高さまで上げられるようになった。
ブロック注射が効いたのか？それにしたって地獄のような状況から急に効き過ぎ。
ヘルニアの足の痛みって、足が悪いんじゃなく、背骨から飛び出した軟骨（椎間板）が足へ繋がる神経を圧迫して痛みが出るものなので、飛び出した軟骨が偶然神経を圧迫しないところへズレただけ（また圧迫するところにくれば激痛になる？）かもしれないけど。

あまりに普通に歩けるようになったので、会社から帰る時に松葉杖忘れちゃった。
なんか嘘で松葉杖ついていたみたいでなりが悪い。
それに明日の朝、再発したら大変だ、会社行けない。
でもまあ、今日この時は、痛みのなくなった事に感謝。

今のところ、Web2.0ワークショップでの実演環境には、MySQL・Perl等はXAMPPでまとめて突っ込んで、PostgreSQLのみ独自に入れているのですが、困ったのがXAMPPのPerlにはDBD::PｇPPしか入っていなかったこと。
ppmでDBD::Pgを入れようとしても、デフォルトでは入らないみたいです。

とりあえずググってみても、配付されていると情報のあるところに行ってもなくなっていたり、あっても古いバージョンのDBD::Pgだったりして中々見つからなかったのですが、とりあえず

ppm install http://dbdpgppm.projects.postgresql.org/DBD-Pg-5.8.ppd

で、今のところppmで入れられる中でもっとも新しいバージョンが入れられるようです。

上記のメモしか残してなかったので、ソースがどこだったか忘れてしまいましたが（すみません）、探すのにむちゃくちゃ苦労したので情報共有のため晒しておきます。

Windows版PostGISは、PostgreSQLのインストーラでもオプションとして入れることができるのですが、最新版のPostGISではないので、PostgreSQLのインストーラのものは使わずに素でインストールして、PostGISのサイトから配られているPostGISだけのインストーラを使って入れるのが正しいとされています。

ただ、このやり方だと、何故か現在のところWindows XP SP2日本語版で入れる場合のみ、エラーが発生してインストールそのものができないようです。

Web2.0ワークショップでの実演環境なんかだとWindows XP SP2のノートブックしか持ってないので、仕方なくPostgreSQLのインストーラと一緒に入るPostGIS使ってます。
ですが、このPostgreSQLインストーラ版PostGISにも問題があるようでして...。

最新版の8.1.5を入れた場合、インストール時は普通に入りますし、空間カラム作成や空間インデックス作成も普通にできるのですが、なぜか&&演算子を使った途端、PostgreSQLサーバのプロセスが落ちます。
幸い、一つ古い8.1.4版だと、問題なく動くようなので、ワークショップ実演環境としては8.1.4を入れることで事なきを得ました。
残念ながら、私の元にはWindows XP SP2しか環境がないので、これがこのOS環境のみの現象なのか、それともあらゆるWindowsで再現するのかは試してませんが...。

PostGISが目的でWindows版PostgreSQLを使う方は、最新版8.1.5は使わない方がよさそうです。

Web2.0ワークショップで講演するのに、ただでさえ一人だけ素人でまともな講演できるか不安なのに、勉強せずに今の知識だけではいかんだろうということで、今までほったらかしてきたMySQL4.1以降の空間情報利用法を勉強。

といっても、こちらに4.1の日本語マニュアルあるので全然苦労なしだが。
ただ動作確認は5.1でやっているので、英語版5.1マニュアルとの照らし合わせはやってますけど。一応。

PostGISとの比較で書くと、PostGISの場合、PostgreSQL本体とは別のプラグインであるせいか、位置情報カラムのついたテーブルはいっぺんにはできない。
例えば、geodbデータベースに、idと位置情報カラムgeom（ここではPOINTだけを含むカラムとする）を含み、かつ位置情報カラムに空間インデックスを張ったテーブルgeotableを作る場合の、PostGISでのSQLはこんな感じ。

CREATE TABLE geotable
( id SERIAL NOT NULL PRIMARY KEY);
SELECT AddGeometryColumn
('geodb', 'geotable', 'geom', 4326, 'POINT', 2);
CREATE INDEX geom_idx ON geotable
USING GIST ( geom GIST_GEOMETRY_OPS );

これに対し、DB本体に空間拡張が組み込まれているMySQLでは、この空間カラム入りテーブル作成、ついでにインデックス張りが一気にできる。

CREATE TABLE `geotable` (
`id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`geom` POINT NOT NULL,
SPATIAL INDEX(geom)
) ENGINE = MYISAM ;

注意すべきは、PostGISでは4326（世界測地系WGS84での経緯度座標系を表すEPSGコード＝SRID）のように空間参照座標系を指定できるのに対し、MySQLではこの情報をカラムに対しては持っていないこと。
MySQLでも、データの挿入時にSRIDをオプションでつけたデータを入れることはできるのだが、将来のバージョンでは不明だが今のところはSRIDは単なる参考情報扱いで、空間情報カラム内ではSRID情報は全く参照されず、空間参照系情報を持たないベタな単一の2次元直交座標系として扱われる（つまり、SRID=4301だろうがSRID=4326だろうが、POINT(135.0 35.0)はカラム中では同じ点を表す）。
よって、PostGISならばSQLひとつでできるような、測地系変換や投影変換のような芸当は、MySQLにはできない。
また、今のところ空間カラムを含むテーブルの作成はMyISAMでしか作れない点にも留意が必要。
すみません、誤情報でした。5.0.16からInnoDBなどでも使えるようになったようです。

今度は、データの挿入。
世界測地系東経135度、北緯135度のデータを挿入するなら、PostGISだとこんな感じになる。

INSERT INTO geotable (geom)
VALUES (GeomFromText('POINT(135.0 35.0)',4326));

MySQLだと、こんな感じ。

INSERT INTO geotable (geom)
VALUES (GeomFromText('POINT(135.0 35.0)'));

SRIDの設定がない以外は（先にも書いた通り、オプションで入れられるが）、PostGISとそっくり同じである。
これは別に真似をしたからではなくて、この辺の空間データベースでどのように空間データを扱うかという事はOGCというところで標準的なインタフェースが定められているので、それに従った結果だ。

続いて、南西角東経130度・北緯30度から、北東角東経140度・北緯40度の範囲の矩形内に含まれるデータを検索する場合、PostGISならこんな感じ。

SELECT id,AsText(geom) FROM geotable
WHERE geom && GeomFromText
('LINESTRING(130.0 30.0, 140.0 40.0)',4326);

空間カラムと東経130度・北緯30度-東経140度・北緯40度を結ぶ直線の間を&&演算子で演算した結果をSELECTしているが、&&演算子は自動的に引数となる2項の空間情報それぞれのMBR（Minimized Boundary Rectangle、最小外接矩形）を求め、その間の重なり関係を空間インデックスを用いて演算してくれるので、これでやっていることとしてはいい事になります。
AsText関数は、空間カラムをそのまま表示すると訳の判らんバイナリ表示になるので、WKT(Well Known Text)形式と言う、例としてはPOINT(135.0 35.0)のような人間にも判り易いOGC標準の記述形式に直してくれる関数です。
MySQLだとこんな感じ。

SELECT id,AsText(geom) FROM geotable
WHERE MBRContains(GeomFromText
('LineString(130.0 30.0,140.0 40.0)'),geom);

単に、PostGISの2項演算子&&が、2引数の関数MBRContainsに変わっただけという感じですね。

というふうな感じで、PostGISと比べるとまだ今のところできるのはMBR間の関係を用いた検索のみで、PostGISでできる測地系変換や投影変換、距離を元にした検索、空間データの結合や差分演算なんかはできないみたいですが、それでも例えば、Google Mapsの表示範囲の矩形を取得して、その範囲にある空間データを検索して表示される、くらいのことはMySQLの空間拡張でも十分できるようになっています。

これまで情報がなかったのであまり使われていないかもしれませんが、こいつもPostGIS同様使ってやってください。

PostGISは地球を球体(sphere)または回転楕円体(spheroid)とみなした上での、地表面距離を計算して距離を計算するための関数（distance_sphere、distance_spheroid）を持っています。
なので、

SELECT * FROM geo_table WHERE distance_sphere(geo_column, GeomFromText('POINT(140 89)',4326)) < 10000;

みたいなSQLで、経緯度で位置情報データが登録されたテーブルから周辺10kmのデータだけを検索する事ができます。
ですがこの検索、空間インデックスが利用されない（総当り検索になる）のが悩みの種で。

もっとも、そもそも地表面距離を計算する関数でなくとも、格納している座標系上での距離を計算する関数distance（主に、経緯度座標系ではなく、メートル単位での座標系となる横メルカトル図法とか、そういった地図投影済みの地理データを格納している場合に使います）でも、空間インデックスは利用されません。
基本的に、空間インデックスというのは、2次元または3次元座標系での、矩形どうしの重なり合いまでしか対象にできず、それ以上詳細な条件に対する絞込みは、まず矩形を使った空間インデックスでの絞り込みの後に、詳細条件でさらに絞り込む、という手順になります。
よって、例えばメートル単位の横メルカトル図法での座標系で座標(100,100)の周辺10kmのデータを検索する場合、こんな感じになると思います。

SELECT * FROM tm_table WHERE expand(GeomFromText('POINT(100 100)',2447),10000) && tm_column AND distance(tm_column, GeomFromText('POINT(100 100)',2447) ) < 10000;

※　expand関数は指定した座標系単位での周辺第2引数分の矩形を自動的に作ってくれる関数、2447は日本の平面直角座標系第５系のEPSGコード。また&&演算子は矩形が重なり合いを持つかの条件判断を空間インデックスを利用して行ってくれる演算子。

説明を加えると、まずexpand関数を用いて発生させた周辺10kmの矩形と座標カラムの重なりを空間インデックスを使って抽出後、抽出されたレコードに対して、総当りで距離を測定し10km以内の条件をチェックしている、という手順になっています。

よって、distanceに対して絞込みのためにexpand関数があるように、distance_sphereやdistance_spheroidに対しても、expand_sphereやexpand_spheroidのような関数を準備してやれば、空間インデックスを活用できるのではないか？というのが、本エントリのその１の主旨。
でも球面や回転楕円体面で一定距離離れた円の接する経緯度の導出が思いの外ムズカシスなので、とりあえずインデックスの効果だけ確かめたのが本エントリその２の内容でした。

んでその後、全くその方面追求してなかったんだけど、Web2.0ワークショップで講演することになったので、流石にインデックスも使えない周辺検索の方法を涼しい顔して紹介するわけにもいかんだろうと。
かといって厳密な球面や回転楕円体面で一定距離離れた円の接する経緯度の導出もそう簡単にはできんので、どうしようかと悩んだ挙句、日本近辺での利用だけでお茶を濁そうと、そのような結論にいたりました。

理科年表(第76冊：2003年版，p.562)によると、経度方向及び緯度方向に1秒移動する弧の長さは、緯度によって異なるがそれぞれだいたい20m以上、30m以上であると。
ということは、日本国内に限れば、中心点から一定距離：x m離れた円は、経緯度で経度方向に±x/20秒、緯度方向に±x/30秒離れた経緯度座標系上での矩形の中に含まれていると考えてよいのではないかと。
（正確には、緯度方向はともかく経度方向の弧は、中心点で正射投影した場合の線が直線ではなく弧になるので、本当にこの矩形の中に絶対望む円が含まれるかは判らないけど...その辺はマージンとってるし、まあ誤差ありありの手法という事で、いいのではないかと。）
というわけで、そういう考え方で作成した関数・expand_sphere_pseudoのplpgsqlソースをさらします。

CREATE FUNCTION expand_sphere_pseudo(geometry,double precision)
RETURNS geometry
AS '
    DECLARE
        fx double precision;
        fy double precision;
        dx double precision;
        dy double precision;
        se varchar(11);
        sw varchar(11);
        ss varchar(11);
        sn varchar(11);
        sid integer;
        wkt text;
        geo geometry;
    BEGIN
        fx = x($1);
        fy = y($1);
        sid = SRID($1);
        dx = $2/20.0/3600.0;
        dy = $2/30.0/3600.0;
        se = to_char(fx-dx,''S999D999999'');
        sw = to_char(fx+dx,''S999D999999'');
        ss = to_char(fy-dy,''S999D999999'');
        sn = to_char(fy+dy,''S999D999999'');
        wkt = ''LINESTRING('' || se || '' '' || ss || '',
              '' || sw || '' '' || sn || '')'';
        geo = GeomFromText(wkt,sid);
        RETURN geo;
    END
' IMMUTABLE LANGUAGE plpgsql;

ここでIMMUTABLEを忘れると、関数の実行結果がキャッシュされず総当りで評価されるので、かえって遅くなってしまうので注意（ちょっとハマった）。

上記関数を用いて、その２記事でも使った10万件の位置情報データに対し、東経135度、北緯35度からの半径100kmの円内検索を実行したところ、

SELECT * FROM geo_table WHERE distance_sphere(geo_column, GeomFromText('POINT(135.0 35.0)',4326)) < 100000;

では525msの検索時間がかかったのに対し、

SELECT * FROM geo_table WHERE expand_sphere_pseudo(GeomFromText('POINT(135.0 35.0)',4326),100000) && geo_column AND distance_sphere(geo_column, GeomFromText('POINT(135.0 35.0)',4326)) < 100000;

では35msと、10倍以上の高速化が実現できました。

タイトルにも書いたとおり、所詮日本近傍でしか使えないデタラメテクニックですが、一応結果を出せたので報告をば。

私としては、日本人の定義はもっとリベラルでいいと考えているし、今しばらくは人口漸増社会にしておいた方が、有権者も為政者もそれに慣れているのだからそうしても構わないと思うのだが、私が首を傾げてしまうのは、にも関わらず経済成長を多くの人々が唱えていることなのだ。それほど経済成長が大事なら、なぜ一番手っ取り早く確実な「母数を確実に増やす」という政策を選ばないのだろうか。

経済成長は欲しい。しかしその果実は日本人から生まれた日本人の間だけで分配したいというのは、さすがにご都合主義が過ぎるのではないだろうか。

Carrying Capacityとか難しい議論は判らないけど、私も日本人の定義はもっとリベラルでいいと思う。

まあ左がかっているからこういう話題ではすぐ旧植民地人の末裔達の去就と照らしあわせてしまうのだけど、一度は帝国を夢見た国が、夢破れたからといってそのケツ拭きもせず「国民は血統主義」に拘っているのはアホ臭いし無責任すぎる。
最低限その意味だけでもリベラルになるべきだ。

またうちの子供が行く幼稚園なんかでは、都心ということもあって既に園児の1割は肌が黒かったり、髪の毛が赤かったり、姓名両方を発音しても息子の名前だけの発音より少ないような子が居て、俺の子供の頃からは想像もできないようないい刺激を息子は日々受けてきているようだ。
そういうのを見ていても、日本人の定義がリベラルになることによりそのような隣人が増える事は、もちろん個々の問題を取り上げれば色々衝突もあるだろうが、総論的にはよい方向に進む気がしている。

とは、思うのだ。
思うのだが。

「日本人の定義をリベラルにすべき」本来の目的であるところの、労働力の供給元としての外国人移民となると、現時点でこれを開放するのがいいのかどうか、私にはよく判らない。
というのも、以前も取り上げた就職氷河期被害者の就職の問題等、日本国内ですら職がなくて困っている人がゴマンといるのに、単純に外国人移民に職を開放してしまっていいのだろうか。
判らない。マジ判らない。

自動車部品工場の単純？労働なんかもあるけれど、今主に挙がっている外国人労働移民の対象としては、看護師とかIT技術者とか、特殊な技能を持った分野での人不足が中心になっていると思う。
その意味では、そういう技能を持たない就職氷河期被害者が門前払いになるのは仕方がないところもあるとは思うけど。
とはいえ、実際にある分野で人不足があり、その一方で就職できない人達がいて、かつ政策として再チャレンジを掲げるのならば、そういう分野の人材として就職氷河期被害者が再チャレンジする機会を作ってもいいんじゃないか？と思う。
海外労働移民を受け入れるのもいいけれど、その一方でその連中と競争できる機会を国内氷河期被害者に与えなければ、被害者達はますます社会から見捨てられた感を増すのではないだろうか。

弾さんとかは、この問題にどういうふうに処方するのだろう？

と言っても急に事故ったとかではないのだけれど。

2年半前にやったヘルニアが再発。
2週間ほど前から左足股関節が痛かったのだが、5日ほど前から歩くのも辛くなり。
そんな中、子供との約束もあったのでふれあい鉄道フェスティバルにも行ってバラストだらけの会場内歩いたりしたものだからどうにもこうにも。

結局今日は、腕の件でいつも通っているペインクリニックで硬膜外ブロック注射を打ってもらったのだが、そのついでに松葉杖を借りてきた。
別にそこまで歩くのがきついわけではなく、家の中では普通に何もなしで歩いているのだが、いかんせん通勤がきつ過ぎる。
片道1時間半かかる上に、そのうち30分くらいが歩きなので、特に1日働いた後の帰りの通勤時にむちゃくちゃ歩くのが辛く、さらにその負担でさらに悪化してるのが自分でよく判る。

てなわけで、長距離通勤の負担軽減用として、松葉杖を借りてきた。
失敗して足をついてしまっても死ぬほど痛いというわけではないので、スイスイと歩くのだが、時々方向転換の時等に杖を引きずってしまって、頭が意識するスピードで体が回らず腰を捻ってしまい痛たたたた...ということが何度か。
でも、思ったより手も疲れないものだ...今日は病院からの帰りだけだったので、明日以降どうか判らないけど。

何に募金するかは募金する人が決めればよいでしょう。件の病気の子にしてもよし、途上国の子供にしてもよし。

全くその通りで、さらに言えば別にどこにも募金しなかったからといっても全く責められる必要もないのです。
いわんや募金した場合においてをや。

なんか人として正しいあり方について考え続けることが仕事の哲学者とか、或いは実際に募金をどのように再分配するかを考える募金活動家とかであるのならともかく、一市井人が、「この募金にお金を出すより、こちらに出すべきである」等とメタな視点での最適化を考える必要も義務もない。
所詮自分の人生すら最適化できないような輩が、そんなメタな次元で考えて自分が答えを出せると思う方が傲慢だ（というか、むしろその次元で考えなければどうしても気がすまない、という人は、募金とかよりも実際に何らかの手を動かしての活動をすることをお勧めする。俺も今でこそ何もしてないが、なんやかやと訳判らんことを考える余裕があった学生時代は、やれ識字教育ボランティアや慰安婦問題や震災支援ボランティアや、いろんな活動に首突っ込んだ。）。
フツーに生きて、フツーに出会った1活動に、心を動かされなかったら、或いは動かされても先立つものがなければ何も出さなくてもよいし、たとえそれが同情であれ憐憫であれ共感であれノリであれオモロゲであれ萌えであれ、心動かされれば出す、それだけで十分だ。

とは言っても、

アルゼンチンのプロゴルファー -2chテラワロス-

「彼女は詐欺師なんだ。病気の赤ん坊なんていないんだ。
結婚すらしていないんだよ。君はだまされたんだ」
「すると、死に掛けている赤ん坊なんていないのか？」
「そのとおりだ」

すると、ビンセンツォは笑いながらこう言った。
「そうか。そいつは今週で一番の良い知らせだ」

これはいい話だしビンセンツォカッコヨシと思うが、やっぱりこんな目にあわないようなリテラシーは持ち合わせたいと思う。
しかし、そのリテラシーというものの基準も人それぞれだ。
「死ぬ死ぬ詐欺」祭りの中で、リテラシー厨が以下のような主旨の発言をしていた（引用じゃないので一字一句同じに非ず）。

これだけネットで騒がれているのに、いまだに募金している奴らがいる。やっぱり日本の民衆のリテラシーは相当低いのではないか。

冗談。
お前らがしている議論なんざ、全部知った上で、その上で募金している奴だっているのだ。
リテラシー厨連中の眼には、1億円近い豪邸を持っているにも関わらず、それを売りもせずに募金活動するというのが詐欺的行為に映るらしいのだが、俺の経験から見ればそんなのは全然問題に映らない。
俺は、阪神大震災で被災した老人達が、既存の生活圏のコミュニティーも無視され機械的に郊外の仮設住宅に送られた結果、付き合う相手もなくたくさんの人が孤独死したことも知っているし、また現在子供を幼稚園に預けている中で、身体障害者の子供達がいかに健常者の子供達の間で助けられ、また学びあいながらコミュニティーに支えられて育っているかを知っている。
災害や障害や難病等に見舞われた人にとって、自分を知っている、理解してくれているコミュニティーというのが、金では何十億出しても手に入らない、pricelessな財産であるということを知っている。
だから、別に募金をかけている側が俺よりはるかに高収入で、俺が一生かけても買えないような家に住んでいても、別にそこを出て行ってコミュニティを壊さなきゃ募金する資格がない、なんてことは全く思わない。
それでもまだ、1億円の家をキャッシュで無借金でポン、と買っていたのなら、それを担保にしてまず借金しろよとは思うが（だからといって詐欺だとは思わないが）、ローンで買っている以上、そんなことも別に思わない。
俺にとってのリテラシーの基準とは、募金された金額が本当にさくらちゃんの治療に使われるか、余剰金がさくらちゃんの予後、或いは他の難病の子の支援に使われるか、といった専ら使途に関することであって、募金を募る側の生活レベルが俺と比べてどうかなんてどうでもいいのだ。
このように人によってリテラシーの基準は様々であるにもかかわらず、自分らの基準だけが至高の基準と信じて暴走する「死ぬ死ぬ詐欺」のリテラシー厨連中の馬鹿さ加減には驚くばかりだ。

ビンセンツォだって、ある意味彼なりのリテラシー基準でポンと金を出したのかもしれない。
だって、事実を聞いても騙されたと騒いだりもせず、何もダメージを受けていないもの。

結論。
募金なんて、誰もが自由な基準で、やりたいと感じたものに対して行えば、それでいいのだ。

古いネタ記事にマジレスカコワルイ？かもしれませんが、

ジョジョ立ちのビルディング -居眠り講義-

Google様がこんなミスを犯す訳はないので、きっと本当にこんなビルディングたちがシカゴにはあるのだと思った。

本当にこんなビルがあるわけではなく、これはGoogleがオルソという処理が為されていない航空写真を使っており、かつ撮影方向が異なる写真が偶然その場所で集まっちゃったものだから、そんなふうにあっちゃ向きこっちゃ向きのビルに見えてしまっているということですね。
正確には、地表面での位置のみひずみをとって正確化し、ビル等の傾きは修正していない簡易オルソという処理をしたものを使っているみたいです。

ところで、本日某地図社の中の人に教えてもらったこちらのMSNのサービスですが、航空写真モードにしてみると、Googleのようにビルが傾きまくりの写真ではなく、どのビルもほとんど気にならない程度に正射で見下ろしているような写真になっています。
東京タワーも、Google版だとこう、MSN版だとこう。
これは、MSNではちゃんとオルソ化した航空写真を使っているということでしょうか？
それはGoogleにない付加価値をつけるため？

最近徐々にLocapointも広まってきたみたいで嬉しい限りです。
先日のオープンソースWebマッピング最先端セミナーでも、セッションの中で取り上げてくださった発表者の方もいるようで。
（伝聞体なのは、私が仕事のため飲み会にしか参加しなかったせいです）

上田さんが見つけられたこちらの記事なんかでも、中々好意的な印象のよう。

既にLocaPoint用のPerlライブラリも作られているようなので、使ってみると面白いかも？

というのは、拙作のこいつの事ですね。

んで、他にもLocapoint取り上げている記事ないかな？と思って探していたところ、なんとRubyのライブラリを作られている方を見つけてしまいました。

Ruby 用の LocaPoint 変換ライブラリを作りました -dara日記-

やたー。
これでCatalystだけでなく、RailsでもLocapointが使えますねー。

さらにググってたら、Java版コードもあったよー。Ni-Labさんだー。

Javaでロカポ(LocaPoint)と緯度経度を相互変換する -NI-Lab.'s ヅラッシュドット-

これでStrutsでも...Struts古いですかそうですか。
今の流行ってなんだっけ？

どんどん広がるLocapointの輪！
PHPやPython、Haskell版は誰が作ってくれるのでしょうか。さてさて。

Otsuneさんの今日のSBM見ていて「ビデオデッキのパーツでネコの餌やり機を製作」というのがあったので、それってオライリーの雑誌「Make:」のネタじゃん、と思って見に行ったらやっぱり「Make:」が元ネタだった。

で、考えたら日本語版「Make:」、オライリージャパンの中の人に教えてもらって発売前に紹介はしたのだけど、購入後は紹介してなかったなあと気付いたので紹介する。

Make: Technology on Your Time Volume 01 posted with amazlet on 06.11.06 オライリー・ジャパン オライリー・ジャパン Amazon.co.jp で詳細を見る

見てるだけで面白い大人のための電子工作雑誌。
固定したゴキブリにトラックボールの上を這わせてその動きをトレースして動くマシンとか、おふざけも多いけどいろいろ創造力をかき立てられる記事がてんこ盛り。
件のビデオデッキ猫餌やり機も、日本語版第1集の特集に入っている。
その他の特集は、古いマウスを改造して、障害物を回避して走り回るロボットを作るとか、鉄パイプとダンベルで作るビデオカメラのスタビライザーとか、どれも読むだけで面白い。
実際に作ってみる暇は、今のところ俺にはないけれど（いや、あっても作るかは微妙だけど...）。

日本語版の第2集移行が出るかは、第1集の売り上げ状況次第らしいので、この面白い雑誌の灯を消さないようぜひ買ってみてください。

ちなみに、「Make:」は発売済みの本なので意味ないけど、オライリージャパンの近日発売予定の本は、Amazonとかで買うよりオライリージャパン直販で買った方がいい。
この「Make:」をはじめ「Google Maps Hacks」とか、直販で発売前書籍何度か買ったけど、いつもオフィシャルな発売日前に商品が届きます。
人よりちょっとでも早くオライリー本を入手したい人は、直販で買うが吉のようです。 

必勝！クレーン奥義！

俺もそんなにうまい方ではないけどクレーンゲームで取った景品もいくつか家に転がってるので、大体コツは掴んでるつもりなんだけど、確かにこんな感じの方法論に行き着きますね。
まさかこんな技の名前が付いているとは思わなかったｗ。

ただこれでは基本の技になっている「トライアングル」とやらいうのは、実際にはほとんど役に立たない。
はてブでも話題になってるけど、実際のゲーセンでのアームのパワーはこんな強いわけはないので、こんな正攻法で賞品が持ち上がるなら誰も苦労はしない。
状況を変化させる技としても使えない。

でも、その他の技は、現実はあのビデオほどアームは強くないから工夫がいるなりに、攻略の糸口になるテクニックですよ。
けさ取り、横四方取り、すきまやタグなんかのフック、引き落とし、プッシュゲット、全部使ったことある（別に攻略本読んだわけじゃないので全部自己開拓で編み出したわけだけど）。
というか、クレーンゲームって、アームの力設定がどの程度かを最初のトライで把握することから始まって、状況を分析して、経験と物理的な動きの想像から攻略法を考えて、そしてこれは絶対無理だとどこで判断してあきらめるか含め自分の読みとの闘いであって、
このサイトはその分析をするための材料として、本来経験がないと体得できないノウハウを紹介してくれてるだけなので、それに対して「実際はアームあんなに強くねー」とか言っても、仕方ないんじゃないかという気はする。

俺が自分で編み出してこのサイトに載っていないテクニックだと、アームが下りる時の力を利用するという意味でプッシュゲットに似てるけど、出口じゃなくてフィールドで使う技がある。
特に箱型のものに有効だけど、賞品を出口の方向に少しずつ誘導したい時、誘導したい方向と反対側の端を下に落ちるアームでひっかけて、てこの原理で賞品を傾け、それの戻る勢いで少しずつ望む方向に動かしていくというもの。
地味な技だけど。

ところで奥義其の11の「ナイアガラ落とし」って技、なんかFLASHの読み込みが27%で止まっちゃって見られないのだけど、これってどんな技なんだろう？
見られた人、教えて。

とにかく地球規模の「ちまちました」話に飽きた人は、是非。

弾さんがこう書いているので、面白そうと思いAmazonに行ってみたら、マーケットプレイスの中古本なら1冊100円-150円前後で販売されてた。
おー、これなら全巻一気に揃えても2000円-3000円程度やんけと思い、カートに入れたんだけど、その時当然同じ出品者からの同時購入なら送料もまとめてもらえるのだろうと思い、同じ出品者から全巻買えるよう調整してカートに入れた。
ところが、苦労して同じ出品者からで集めたにも関わらず、送料は1冊ごとに取られるみたいで、清算してみると送料だけで3000円台後半に。
やってらんねー、近くのBOOK OFFで探した方がいいやと思って購入取りやめ。

Amazonマーケットプレイスは、こんなふうに同時に同一出品者から購入する場合、冊数に比例して送料が増えるわけないので、送料を割り引けるようにとかしてくれればいいのに。
出品者側もその辺は問題として判ってるみたいで、まとめ買いなら1冊あたり50円返金とか運用でカバーしてるみたいだけど、このくらいシステムでカバーして欲しい。

なのだそうな。
1ヶ月くらい前かな？AffelioのユーザMLでアナウンスされて、公式にも近々アナウンスするということだったのでそれを待って取り上げるつもりだったんだけど、Affelioのページ見てても公式アナウンスされる様子がないので取り上げてみる。
Yadis.jpの方で書いたように、私が未踏ソフトにOpenIDやFOAF等の技術を使った分散型SNSの提案をした際、PMからは分散型SNSがたくさん乱立しても普及するとは思えない、それより既にあるAffelioを支援すべきでは？と言われて落とされた、という経緯もあるので、方法論は全然違うんだけどなあ...と思いつつも、分散型SNSの受け口となるプロジェクトがなくなるのは非常に残念。

ビジネスのことははっきり言って全然判らない、どうやってればAffelioが成功できたのか、皆目。
そんなのは俺なんかが考えたところで、これだけの一流プロのアドバイザーがついてて無理だったんだから、俺の考えの及ぶところじゃない。
でも技術コンセプト的になら話せるので、Affelioのコンセプト的に俺が残念だった点が2つある。

1つは、飽くまでアプリケーションであったこと。
Affelioで行った友人関係の認証状態の利用は、飽くまでアプリケーションの範囲でしか使えなかった。
もちろん、プラグイン化してAffelioアプリの中に既存のアプリケーションをポートする機構もあっり、Affelioで使えるFreeStyleWikiとかもあったりしたけど、飽くまでAffelioというアプリケーションの枠組みの中に埋め込む、という形でしかなかった。
Affelioがアプリではなく、もっと広範に利用できるプラットフォーム、例えばApacheに組み込めるmod_affelioのような形で、その認証状態をプラットフォーム上で動く既存アプリや非Perlアプリ等でも利用できるような仕組みを提供できていれば、普及の度合いももっと変わったかもしれない。

もう1つは、友人サイト上での友人関係の認証を行うのに、まず自分のAffelioサイトでログインし、その後自サイトから友人サイトへのリンクを辿る事によってしか、認証状態を受け継げなかったこと。
（これは私が理解しているAffelio初期の仕様を元に書いているので、最後までその仕様だったかは未確認なのだけど...少なくとも要望リストに挙がってて解決しようとする動きがあったのは知ってる）
確かに普通のクローズドなSNSなら、ログインしたら自分のページで、そこから友人のページへ遷移する、というのは当たり前の挙動なのだけど、ことオープンなWeb世界でのユーザの挙動となると、それが当たり前ではなくなる。
Webにアクセスする際に、昔ながらのWebサーフィンよろしくまず自分のページにアクセスしそこからリンクを辿っていくような奴などいない。
友人のサイトをアクセスするのであっても、普通はLivedoor Readerで知ったRSSからの更新通知経由でアクセスするか、或いははてなブックマークで過去にクリップしたページにアクセスするか、いずれにせよ自分のサイト経由ではなく、友人のサイトに直接アクセスするのがユーザの普通の行動パターンだ。
よって、友人サイト上で友人認証するなら、自分のサイトで認証した後それを受け継ぐのではなく、その友人サイト上で認証作業（しかも分散型）ができなくてはならない。

Affelioがクリアできなかったこの辺の問題をクリアするには、私は過去に散々書いてきたけど（OpenIDとかFOAF、Open SNSのタグで過去ログ検索して欲しい）、やっぱりOpenIDとかを使った分散認証システムを使うしかないと思っている。
OpenIDがmod_openidみたいな形でWebプラットフォームレベルで認証ができるようになり、かつ途中でユーザの介在を必要としないREST等のWebAPIインタフェースによるOpenID認証手順が整えられ、ブラウザがそれに対応して、OpenIDログイン可能なサイトでは、あらかじめブラウザ内に設定されていたOpenIDアカウントとパスワードでユーザに意識させずに自動でログインを実行する、というような経路が実現されなければ、インターネットがそのままSNS化して、友人のサイトを訪問すればそのまま意識せずに自動的に認証されて、みたいなことを実現する方法はないんじゃないかと思ってます（というか私には思いつかない...）。

http://maps.google.com/maps?spn=0.028673,0.055361&z=14&vp=35.628559,139.739227&ev=zi

というようなリクエストもサーバに送っている。
クエリ引数は想像だが、spnは多分現在表示している地図の縦横の範囲（度表記かな？）、zは地図の表示スケール、vpは中心位置の経緯度、evは直前の操作（ｚｉはズームイン）というところだろう。
これに対するレスポンスは以下のような感じだ。

GAddCopyright("m","6",23.8833,123.7486,46.0723,143.7891,3,"ZENRIN",19);

つまり、地図の右下に表示するCopyright表示の情報を、そのCopyrightを表示すべき経緯度範囲（Extent）の情報と共にレスポンスしている。

これを教えてくれた人がいうには、

• Copyright表示は表示すべきExtentの情報も一緒に取ってきている、すなわち操作の度にリクエストしなくても範囲外に出れば消すこともできるのに、操作をする度にリクエストするのはおかしい
• 表示すべきCopyrightを判定するには、中心位置の経緯度やスケール、地図の表示範囲までが判ればよいはずで、直前の操作まで送る必要はないはず

といった点より、GoogleはCopyright取得用のリクエストと見せかけて、個人の地図上の興味の動線を記録している、警察のNシステムのようなことをWeb地図上でやろうとしている、という話をしておられました。
その時は、へー、そうだったのかー、と興味深く聞かせてもらったんですが、帰ってからよく考えてみると、ちょっと違うのではないかなと思う点も多々ありました。

まず、Copyrightの表示範囲を取得しているのに毎回リクエストするのはおかしいと言う話ですが、確かに今表示されているCopyright表示を不必要な範囲に遷移した際に消すのはリクエストなしで可能です。
でも、新たなCopyrightが必要なエリアに来た際にそれを表示するのは、リクエストなしでは不可能です。
例えばこの地図表示状態、この領域の中で詳細地図があるのは日本だけなので、Copyright表示はZENRINしか表示されません（※表示する人の画面サイズによっても異なりますが）。
しかし、ほんのちょっと地図を動かしてアラスカが地図の中に入ってくるようにしてやれば、途端にNAVTEQのCopyrightが表示されるようになります。
このようなことを実現するために（著作権上しなくてはならないために）、毎回リクエストしているだけじゃないかなと思います。

また、Copyrightの判定には直前の操作情報は必要ないのはその通りなのですが、それは個人の動線を把握してどうこういうより、ユーザ全体としてどの場所がよく拡大表示されて、どの場所でよく縮小表示されるかという傾向を掴みたいためだけじゃないでしょうか。
Google Mapsは世界対応のアプリケーションですから、（最終目標としては）世界の情報をあまさず提供しなければいけないわけですが、とは言え全ての場所を同じ精度で一度に整備できるわけじゃない。
当然どこを優先的に整備していくかという順序があるわけで、それを判断するにはどこがユーザの関心を高く集めているかと言う情報がどうしても必要なわけです。
そのための情報、つまりユーザにとってもGoogle Mapsがこれまで以上に便利に整備されるための情報なのではないでしょうか。

もちろん、原理的には各ユーザ個人単位でどこを見ていったかを追う事は可能です。
その意味でNシステム的なことは実現できる素地はあるわけですが、でも別にリアル世界でどこへ行った、というような事が追跡されるわけでもなく、所詮は地図を見た履歴ってだけでしょ？
別にそれが他人にばれたからといって、それによって犯罪に問われるわけでも、人格を疑われたりするわけでもなんでもない。
Googleに履歴が残って知られてしまうから云々言ってれば、そもそもGoogleのテキスト検索自体が使えないです。
地図なんかよりもっと危ない、「芸能人」「お宝」とか何とか怪しい言葉いれての検索なんてしょっちゅうやってるのに。
その程度の情報取られることくらい、大目に見ましょうよ。

私も以前採り上げたとおり、Google Mapsの地図が少し前から超美麗になっていますが、これ、ZENRINが気合入れて美麗地図を作ったわけではなく、ZENRINがベクトルデータのシェープファイルだけを提供したのを元に、Googleが描画したもののようです。
それが証拠に、ZENRINが運営しているits-mo Guideでは、これまでどおりのZENRIN地図が表示されます。

もしかしたら既知の事実なのかもしれませんが、私は全く知らなかったので他の知らないかもしれない人のために採り上げます。
私はてっきりZENRINが気合入れたもんだと思ってました。
この話題、少なくともGIS業界では、美麗さに衝撃が走ったせいか常識となっているみたいです。
これも、オープンソースWebマッピング最先端セミナーの飲み会席上で教えてもらいました。

さんざん地図技術に接してきた熟練GIS技術者の人も、線の美しさは比類ないと褒め称えてました。
もっとも、全面賞賛と言うよりは、俺がその辺やりたかったのにという悔しさ半分のようでしたが。
あとはアノテーション（住所等属性テキストの表示）がもっと洗練されれば完璧とも。
今は、Googleでもヨーロッパの技術者が日本地図の描画に携わっているようで、住所等の改行位置を辞書ベースで決定しているようなのですが、そのせいかこんなふうに変な場所で改行される住所表示もちらほらと。

しかしいずれにしろ、Googleはもう本格的な、いや一線のGIS企業になってきたといっても過言ではないようです。

ロカポイント提唱の上田さんが、またまた面白い仕様を提唱しようとされています（ご本人はまだ表に出されていませんので、本ブログの本記事が初出となります。上田さんの許可をいただいて初出の栄誉をいただきました）。
問題意識は、ロカポブログのこの記事でも上田さんが明らかにされているのですが、

緯度経度のフォーマットってバラバラすぎませんか？ -ロカポブログ-

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

そこで、一つの位置データから、地図サイトを自由に切替え、好きなサイトに飛ばすことができるアプリを開発してます。

というふうに、現在のWeb上での位置情報流通って、地図サイトへのリンク貼るしかなくって、普段Mapionの地図を便利だと思って使っている人でも、サイトの記事上でGoogle Mapsで情報が提供されていればそこではそれを使うしかないという不便さがあります。

そこで上田さんが提唱しようとされているのが、navitoハンドラ。
httpハンドラを使って、http://example.com/という記述が、OS上でIEに関連付けていればIE、Firefoxに関連付けていればFirefoxで開くように、navitoハンドラというのを定義して、それにユーザがGoogle Earthを登録しておけばGoogle Earthで、Google Mapsを定義しておけばGoogle Mapsで、MapFanを定義しておけばMapFanでそれを開いてくれるということができるようにしよう、という発想です。
もちろん、今のところは言うまでもなくGoogle EarthもGoogle Mapsもnavitoハンドラには対応していないので、navitoハンドラの定義づけを一手に引き受けて、ユーザの設定した位置情報アプリやサイトに中継するようなアプリ、というのが、上の引用で上田さんが作られようとしているアプリです。

具体的な記載方法としては、例えば以下のような感じになります。

navito:ロカポ　　　例：navito:NA0.NA0.AA0.AA0
navito:緯度,経度　　例：navito:35.000,135.000
navito:緯度;経度　　例：navito:35.000;135.000

で、なんで初出を上田さんに譲っていただいてまで、navitoハンドラをうちで紹介したかというと、最近、オープンソースWebマッピング最先端セミナーの飲み会の席上でなのですが、私が以前提唱したQRコードに位置情報を付記して街角に貼るアイデアが、GPSとかが使えない地下街や建物内での位置特定インフラとして有用だよね、みたいな話で盛り上がったのです。
が、位置情報埋め込みQRコードの問題は、どんな情報を埋め込むかというところにあって、単に経緯度の値がQRコードになっていても何の役にも立たない。
かといって、特定のサービスに紐付けた情報、例えばGoogleローカルのその場所の経緯度のページがQRコード化されていても、その他のサービスではその情報を利用できず、特定のサービスに依存しすぎていて社会の基礎インフラとはなり得にくく、面白くない。
そこに上田さんの提唱している、サービス独立のnavitoのような仕様があれば、「navito:位置情報」の情報をQRコード化してあちこちに貼っておくことで、そいつをQRリーダで読み込んで、ある人はモバイルMapionで、またある人はモバイルちず丸で、Googleローカルで、その情報を使えるようになる（もちろん、ケータイがnavitoプロトコルに対応したとしての話ですが）。
こういうサービス独立の汎用仕様なら、街角QRコードの整備も、半官のプロジェクトとしてでも進められるかもしれない。
こうなってくると面白いんじゃないか、という話題で盛り上がったので、こういう世界を実現するには1分1秒でも早くnavitoハンドラ標準化のための動きに入りたくて、記事に採り上げたわけです。

というわけで、navitoハンドラ標準化のための活動、始動です。
この仕様が起動に載ってくれば、その次は地図アプリ・サイトへのリンクだけではなく、今いろんな地図会社なんかがブログ貼り付け用の地図サービスを始めてますが（ALPSLAB clipとか、地図日記とか、ちず窓とか）、こういうのもサイト作成側が選んで読者に押し付けた地図画像ではなく、地図画像の切り出しの標準化記述なんかが出てきたりして、読者側が使い慣れている地図サービスが自動的に呼び出されるような、そういう仕様の標準化も進むかもしれないですね。

12月6日に、Internet Week 2006内の1イベントとして、Web2.0ワークショップが開催されます。
Shibuya.pm新ボスの竹迫さんがPlaggerの入門講演されるっちゅうので、見に行かねば！と思っていたところ、何をどう間違ったかうちにも講演の話が来てしまいました。
竹迫さんをはじめ各界の一線級の人が話す中で、なんで超日曜エンジニア（＆1年半サボり中）の私に話が来たのかよく判りませんが、悩んだ末、まあどうせ行くつもりでもあったのだし、ただで竹迫さん講演聞きに行くついでにアホなことでもしゃべってくるかーのテンションで引き受けました（と言いつつキンチョウしてますが）。

内容は位置情報デバイスとデータストアと題して、それしかしゃべれないネタであるところのケータイ位置情報と空間DBという何の脈絡もないペアをセットでお届けします。
位置情報でWeb2.0といえばもう普通はGoogle Mapsだろ！という感じのアレなのですが、Google Mapsについてしゃべれないので仕方がありません。
そのくせ口上では、

Google Mapsの登場で位置情報コンテンツ作成の敷居は大きく下がりましたが、どんな情報を提供しようか悩んでいたりしませんか？ また、普通のDBでは大量の位置情報をうまく扱えず、困っていたりしませんか？
本講演では、誰もが持ってる身近な携帯から位置情報をつけた情報を収集するためのノウハウと、位置情報をうまく扱う空間DBの使い方を紹介します。
これらをうまく活用して、どんな使える位置情報コンテンツを作るかはあなたのアイデア次第？

とか何とか言っておりますが、あまりにもWeb2.0に繋がらない上に脈絡のない2分野を強引に結びつけるための単なる逃げ口上です。
しかも「一歩進んだ位置情報！」とか言ってたりしますが、ケータイ位置情報も空間DBもあまり知られてないだけでGoogle Mapsより昔からある世界なわけで、はっきり言ってそれは「一歩遅れた位置情報」ではないのかと、自分でツッコんだりもしております。

そんな感じで看板に偽りありのダメ講演になりそうですが、よろしければ聞きに来て下さいまし。

しかしちょっと前まで定時退社も多く、これならできそうかなと思って引き受けた途端、忙しくなってしまった...。
今も会社から投稿、明日明後日も休日出勤。
本業じゃないだけに、資料作成だけでなく技術の検証なんかも余暇でやらんとならんのに、これでは中々ツラス。
早くも危ないモードに入ってますが本当に大丈夫なんですかねーーー。知ーらない。

昨今、メール経由で情報が漏洩する事がよくあるらしい。
その問題を解決するため、うちの会社が出した答えが「メール添付ファイル禁止」。
部課内の通達すら添付禁止で、ファイルサーバ上においてポインタで示せだと。

元々文書のバージョンや所在を管理するシステムもなくて共有フォルダ領域にファイルべた置き。
誰かがフォルダ構成変えたりファイルに手を加えたりしたらファイルが見つからなくなったり旧バージョンが入手できなくなったりする中で、ある意味メール添付ファイルだけが時間・イベントと紐付けてファイルを管理できる唯一の手段だったのに。
それを禁止するとはアホすぎる。
マジで滅びろ、図体でかいだけのこんなアホ会社。

メール絡みでアホと言えば、そもそもうちの会社メールシステムがPOPやIMAPアクセスの一般メールシステムじゃなくて、専用クライアントからしかアクセスできない独自仕様ミドルウェア（自社製品）のメールシステム使ってる。
メールはサーバに保存されてて、開いたメールだけ手元にダウンロードされて読む形なので、遠隔拠点に出張した時なんかは確かにちょっと前のメールにも遠隔からアクセスできて便利なんだけど、そんな便利さ吹っ飛ぶ致命的な問題が。

なんと、サーバにメールが1ヶ月しか保存されない。 
それで、先にも書いたように「開かないと」ローカルにダウンロードされないから、重要なメールでも、遠隔拠点出張時に読んでそのまま自分のPCに戻った時に読み忘れていると、無情にも削除されて二度と読む事ができない。
いや、まだ受信メールは、そんな遠隔地で読んだメールの危険性はあるけれど、大抵は1度は開けて読むからローカルに残るからいい。
最悪なのは送信メール。
なんとメールを作成して送ると、ローカルにはファイルを残さずにサーバにだけ記録が残る。
だから、自分のメールを開いてダウンロードして読み返す事（無意味！）をしなければ、重要なメールだろうが何だろうが1ヶ月経つと消える。
このせいで何度重要なやり取りを後で確認できなかったことか。

独自のやり方でやるならやるで、今時自社利益に関係のない不特定多数に使ってもらうGmailですら1GBも保存してくれるんだから、Googleと規模的には同じくらいの大会社なんだから自社の基幹システムのメールぐらい、永久保存に近くしろよ。
重要なやり取りのエビデンスが残せなければ、不利益を蒙るのは自分の会社だろ。
ほんまアホ会社で、むかつく。