忘れてた！
ショックデカス！

追加！追加！追加！
みんなでコール！

わんだ：＞ えーと、「はてなが標準化を目指す野望を持っている」ということと、「はてなの現状のシステムがこうである」ということは、異なると思うのですが。

これに関しては誤解されてると思います...元々近藤さんが、標準化を目指してきたSixApartなんかと、これまでは標準化せず内部システムとして作り上げてきた自社との比較をして、反省？みたいな論調だったので、それを受けただけです...。
これまではこれまでとして全然OK、でもそろそろ地力もついてきたから、標準についても考えてみようか、みたいな論調だったなら、すんなり頭に入るのですが、これまで標準を目指してこなかったのが間違っていた、みたいな論調に受け取れたので、違和感を感じての先のエントリなのです。

わんだ：＞http://www.sixapart.jp/docs/tech/mobile_link_discovery_ja.html
わんだ：＞ここにもある通り、はてなは既に、ある種の標準化を本気で目指しています。

なるほど、それも確かに立派な標準です。
というのは、私も2002年頃似たような事考えていたのですが、単にケータイサイトのアドレスを指し示すだけでなく、対応キャリアの判定、内部に含む位置情報のインデックス等、いろいろ対応したいと考えてぐちゃぐちゃした挙句、訳わからなくなってほっぽり出したのに比べ、「ケータイサイトのアドレスを指し示す」と本質の機能だけに特化し、他をそぎ落とし、仕様としてまとめたのだから素晴らしいとは思います。

ただ、先のエントリで私がイメージしていたのは、近藤さん自身が例に挙げているトラックバックや、或いはOpenID、AtomPP、とかのような、もっとダイナミックな、動的なプロトコル標準をイメージしていました。
いわゆるAutoDiscovery系の静的な標準は、難しくないとはいいませんが、ある意味作ったもん勝ち、あと作りっぱでも何とかなる、という点で、セキュリティや相互接続性、パフォーマンス、等等、議論を繰り返して煮詰めていかなければいけないプロトコル系の動的な標準とは、やはり一線を画すと思っています。
そういう静的な標準の策定１つをもって「はてなが本気で標準化を目指している」例としてしまうと、逆にはてなの実力がその程度、という意味にもなりかねない気がして、贔屓の引き倒しになってしまう気がするのですが...。

例えば、私なんかが思う例では、はてなが標準化を目指すのであれば、前に出たはてな投げ銭の仕様、あれなんかも自社サービスのはてなブックマークに登録後、その補助機能として投げ銭を行う、というような独自仕様にせず、標準化すればよかったのにな、と思うのです。
受け取り者のアカウント取得、決済サービスへの送付者のログイン認証、送付金額・単位の交換等、プロトコルを標準化して定義してくれていれば、ブックマークだけでなくいただいたコメントやトラックバックにだって投げ銭できたりするし、また世の中にははてなポイントでなくとも小口決済の手段はいくらでもあるはずなので、 そういったところも同じ手順に沿って投げ銭の送付・受け取りができるようになるわけです。
そうすると、投げ銭の自動化ツールなんかも出てきたりと、みんなで面白い動きが色々できるようになる。
そういうあたりで一苦労することが、標準化を目指すということなんじゃないかなと思うのです。

しげ：＞<degrees>は単に4326だからかと。expandの引数はgeometryと同じ単位にするはずなので。
しげ：＞expandはふるいにかけるのに使うのだと思います。

あー、なるほど。
座標系上でのバウンディングボックス（ある形状に接して周辺を囲む四辺形のこと）を求める関数なのね。
これで求めたバウンディングボックスとの内包関係を、空間インデックスを利用してふるいにかけ、引っ掛かったものに対しdistance関数で正確に距離を求めてさらにふるう、ということか。
というか、つまり Spatial な distance 関数との連携でつかうもんであって、Geospatial な distance_sphere や distance_spheroid 関数と一緒には使えないというわけだな。
駄目じゃん。

でも、これで問題がクリアになってきた。
distance 関数に対する expand 関数のように、distance_sphere や distance_spheroid 関数に対応する、expand_sphere や expand_spheroid 関数を定義してやればよいのではないのか。
「PostGISとPostgreSQL幾何データ型の比較」へのはてブ：

yappo：＞用途によってはインデックスが効かない事が致命的ダメージですだ。

オープンソースなのだから、インデックスが効かないなら効くようにしてやればいいのだ。
と偉そうに言ってもこれがCのプログラムだと、今の私では何ともかんともだが、幸いこれはPostgreSQLのプロジェクトなので、plpgsql なら何とかなりそうな気がする。

Geospatial な環境で、中心から一定距離内の円を内包する経緯度のバウンディングボックスがどのように表現できるかを考えてみよう。
ある経緯度の点O (x,y)を中心とした、半径ｒ kmの円Rを考え、Rと経線との交点の北側（Oから北へr km行った地点）の緯度をny、南側（Oから南へr km行った地点）の緯度をsy、Rと接する経線のうちOより東側のものの経度をex、西側の経度をwxとおいてみる。
また、Oから北へr km行くと北極を越えてしまう場合を、ny ＞ 90 、南へr km行くと南極を越えてしまう場合を、sy ＜ -90 と表現してみる。

ここで、ny ＞ 90 の場合を考えてみる。
イメージ図はこんな感じ。赤線がR、マゼンタの線がバウンディングボックスだ。

この場合、Rは内部に北極を含んでしまうため、全ての経線と交わってしまうので ex 、wx を定義できない。
よって、経度のバウンディングボックスの範囲としては、最小値から最大値まで、-180 ～ 180 の範囲となる。
一方、バウンディングボックスの北の端は考えるまでもなく 90 。
南の端が、sy となる。
よって求めるバウンディングボックスを、東北 - 西南の対角線で表すと、(180,0) - (-180,sy) となる。

同様に考えて、sy ＜ -90 の場合のバウンディングボックスは、(180,ny) - (-180,-90) だ。

次に、-90 ≦ sy, ny ≦ 90 の場合を考えてみる。

バウンディングボックスは単純に、(ex,ny) - (wx,sy) だ。

要するに、このような場合分けに従って、応じたバウンディングボックスを返してやる関数 expand_sphere や expand_spheroid を定義してやればいいということだ。
そしたら、そいつとの内包関係で空間インデックスを使ったふるいがかけられ、それを通過したものにだけ distance_sphere や distance_spheroid での詳細計算をしてやればいい話になる。
ね、簡単そうでしょ？

問題は、意外と難しいのが最後の場合分けの場合の、ex や wx を導出する計算。
その辺が判るように上の図は描いたつもりだが、ex や wx は、緯度 y の緯線と R が交わる点では全くない。
これを求める公式がないかどうか、隣の席のGIS詳しい同僚に聞いたところ、彼もこんな事は考えたことがないらしくちょっと頭をひねっていたが、R の中心 O 、北極 N 、そして R と経線の接する点 P を考え、三角形 OPN が∠OPN が直角となる球面上の直角三角形と考えれば、球面三角法というのを使って何とかなるらしい。
球面だと expand_sphere しか計算できないが、回転楕円体でも少し応用すればできるのではないかということを言っていた。

その辺の地理的な計算の方法が載っている良書として、「計算幾何学と地理情報処理」という本を紹介してもらった。
あいにく絶版なのだが、幸い1冊だけユーズドで販売してたので、4500円と高かったが早速買ってみた。

この本など調べつつ、 ex や wx を導出する計算を明らかにして、次は関数の実装に挑みたいと思う。
いつになるか判らないけれど、乞うご期待？？？

ねは、ネットで大きいこうさぎと、広いこうさぎと、広いこうさぎとかこうさぎとかこうさぎと広いこうさぎや、こうさぎなどをPostgreSQLしなかったの？
こうさぎなど飛べない日々-.

WEB+DB PRESS Vol.33の弾さんとはてな近藤さんのインタビューを読んでの違和感。
というか、以前から近藤さんが、はてな内のダイアリー同士を繋ぐ機能と、SixApartのトラックバックの標準化への活動等を比較して、はてなは標準化への努力が足りなかった、とかの論調で話される事があって、それへの違和感なんだけど。
適当なネット上の出典へリンクを張ろうとしたけど、見つからなかったので、WEB+DB PRESS記事をトリガにさせていただく。

トラックバックも、はてなの諸機能も、確かにブログ同士を繋ぐ機能ではある。
でも、その性質は、実現する機能が違う以前に、本質が全く異なるものだ。

他のはてなユーザの、IDを書けば、そのまま繋がる。リンクを書けば、そのまま繋がる。キーワードを書けば、そのまま繋がる。
私自身がはてなダイアリーを使ってないので全ては知らないのだが、他にも色々あるのだろう。
これらの機能は、みな魅力的だ。
こんな切り口で、ブログとブログが繋がれば楽しいだろうなというスタッフの思い付きが、都度試されて、新しい機能になっていく。
その変わっていく魅力的なコミュニティがはてなの人気の秘密であろうと思う。
閉じたクローズなサービス内でしかできないことだ。

一方のトラックバックは、実現できることはある意味一つだけ、「ブログとブログを繋ぐ」ことだけだ。
どのような視点で繋ぐと楽しいか、有用か、といった部分はそぎ落とされて、基準は繋ぐことを要求する側が接続先として選ぶかどうかだけだ。
標準を定めるというのはそういうもので、特に標準の「1.0」を定める際は、色々こうできたら面白い、こうしたい、というのをいかにそぎ落として核心部分だけを定義するか、という作業になると思われる。
そこに、「こうしたらユーザが喜びそうだから」とか、「ちょっとおもしろそうだから」とかいった、今のはてなの開発を魅力的にしているような視点は、中々入れられる余地はないだろう。
また、1.0を標準化してみて、いろんな要求に応えて次のバージョンを標準化する場合でも、その際はいろいろ拡張機能を突っ込んでみる余地もあるだろうが、「標準」である以上それを使ってきたプレーヤーに対し後方互換を保証するものでなければならず、アイデアを都度すばやく実装する、というようなダイナミズムは失われ、進化の歩みは遅いものになるだろう。

それに、標準であるがゆえに、トラックバック・スパムのような問題も発生することになる。
はてなの内部でのブログ接続機能、そのいずれをとっても、スパムとして利用された、というような事があるだろうか。

そういうふうに考えると、今のはてなの魅力は、「トラックバックの標準化」を目指すような企業じゃなかったから生まれた、とも思える。
はてなは無理して、標準化に手を出す必要はないのではないのかと思うのだ。

そして、それでもあえて標準化に携わりたいと思うのならば、別に自社発の標準である必要は全くないんじゃないかと思う。
例えばOpenIDやYadisは、SixApartから出たアイデアではあるが、いまやメインプレイヤーはNetMesh、JanRain、及びVeriSignだ。
もうSixApartの影の方が薄いくらいだ。
この、知る限り日本人からは私しか発言していないようなこの標準の討議の場に、はてなから一人でも参加してくれれば、とても嬉しい。
また、近藤さんがそこまでこだわっている？トラックバックにしたって、次世代のトラックバックの仕様は今もどこかで討議されているはず。
それに参加すればいいのに、と思う。
別に標準を新しく作り出すばかりが能じゃない（どこでもかんでも言い出せばいいと思って、位置情報の記述に関するXML標準が馬鹿みたいに乱立していた数年前を思い出す）。
既にある標準をいかに育てていくかも、大切なんじゃないかと思った。

これだけで終わらせるのもあれなので、実際にPostGISとPostgreSQL幾何データ型の周辺検索の比較を行ってみた。
結果は...あれだけアジった結果としてはちょっと恥ずかしい？1勝1敗に終わった。
（とはいえ、元記事そのままのやり方ではそもそも比較の対象にすらできず、前エントリで私がフォローしたやり方とPostGISとの比較なので、ちょっと勘弁いただきたいといいたいところでもある）
何をもって1勝1敗というかについては、以下記事参照。

とりあえず、組み込みの幾何データ型とPostGISジオメトリ型のカラムを持つテーブル作成。

    CREATE TABLE geodata (id serial, geo_pseudo point);
    SELECT AddGeometryColumn('geodata', 'geo_right', 4326, 'POINT', 2 );

こんな感じで、PostGISのカラムは後から追加するような形となる。
意味合い的には、'geodata'テーブルに、'POINT'ジオメトリ型の'2'次元データを格納する'geo_right'カラムを追加しなさい、と言う感じ。
'4326'については、あまり気にせず、よく位置情報で「日本測地系」「世界測地系」とか言うけれども、その「世界測地系」で格納してるよ、くらいの理解でよいと思う。

こいつに10万件の、xは-180から180、yは-90から90で、小数点以下3桁までのランダム座標データを、叩き込んだ。
当然、カラム'geo_pseudo'と'geo_right'には、型は違うが同じ座標が入ってる。

続いて、インデックス作成。
まずは組み込みの幾何データ型から。
そのままインデックスを貼っても意味がないので、前エントリで書いた通り、東経135度、北緯35度付近の経度1秒分の長さ25.36m、緯度1秒分の長さ30.82mで全体を近似してやる。
そのため、関数定義から行っている。

    CREATE FUNCTION metrize(point,double precision) RETURNS circle AS'
        DECLARE
            ret circle;
        BEGIN
            ret = circle(point(($1[0]-135.0)*60*60*25.36,($1[1]-35.0)*60*60*30.82),$2);
            RETURN ret;
        END;'
    LANGUAGE 'plpgsql';

    CREATE INDEX geo_p_index ON geodata USING gist(metrize(geo_pseudo,0));

続いて、PostGIS。

    CREATE INDEX geo_r_index ON geodata USING gist(geo_right GIST_GEOMETRY_OPS);

さて、これでいろいろな地点で半径100kmの地点を検索して、検索結果の正確さを競ってみる。
というか、正確かどうかはPostGISの関数に頼るしかないので、PostGISの検索結果に対し組み込みの幾何データ型でどれだけの誤差が出てくるか、という勝負になる。
（関数としては、distance_sphereを使う。distance_spheroidの方がより正確だが、楕円体の設定がめんどいので。というか、どうして測地系の設定から勝手に楕円体定義を取ってくれないのかなあ。）

まず、赤道付近から。東経140度、赤道上の点の周辺100km検索。(SELECT...FROMの中身は2つ目以降省略)

    SELECT id,geo_pseudo,asEWKT(geo_right) AS geo_right,distance_sphere(geo_right,
        GeomFromText('POINT(140 0)',4326)) AS real_distance FROM geodata WHERE
        distance_sphere(geo_right, GeomFromText('POINT(140 0)',4326)) < 100000;
      id   |   geo_pseudo    |           geo_right            |  real_distance
    -------+-----------------+--------------------------------+------------------
     10684 | (140.584,0.234) | SRID=4326;POINT(140.584 0.234) | 69956.4103677886
     13409 | (139.324,0.384) | SRID=4326;POINT(139.324 0.384) | 86448.0785647496
     31374 | (139.707,0.675) | SRID=4326;POINT(139.707 0.675) | 81822.2258725275
    (3 rows)

    SELECT ... FROM geodata WHERE metrize(geo_pseudo,0) @ metrize(point(140,0),100000);
      id   |   geo_pseudo    |           geo_right            |  real_distance
    -------+-----------------+--------------------------------+------------------
     10684 | (140.584,0.234) | SRID=4326;POINT(140.584 0.234) | 69956.4103677886
     13409 | (139.324,0.384) | SRID=4326;POINT(139.324 0.384) | 86448.0785647496
     27809 | (139.012,0.116) | SRID=4326;POINT(139.012 0.116) | 110614.899541332
     31374 | (139.707,0.675) | SRID=4326;POINT(139.707 0.675) | 81822.2258725275
    (4 rows)

幾何データ型の方で、110kmほど離れた点を余分に検索してしまっているのが判る。 

続いて、極付近。東経140度、北緯89度の点の周辺100km検索。

    SELECT ... FROM geodata WHERE distance_sphere(geo_right, GeomFromText('POINT(140 89)',4326)) < 100000;
      id   |    geo_pseudo     |            geo_right             |  real_distance
    -------+-------------------+----------------------------------+------------------
       312 | (131.807,89.813)  | SRID=4326;POINT(131.807 89.813)  | 90661.9476873461
                           ...snip...
     99752 | (110.39,89.398)   | SRID=4326;POINT(110.39 89.398)   | 62469.9425267812
    (287 rows)

    SELECT ... FROM geodata WHERE metrize(geo_pseudo,0) @ metrize(point(140,89),100000);
      id   |    geo_pseudo    |            geo_right            |  real_distance
    -------+------------------+---------------------------------+------------------
     24283 | (140.17,88.405)  | SRID=4326;POINT(140.17 88.405)  | 66162.1569738936
     35214 | (140.608,89.421) | SRID=4326;POINT(140.608 89.421) | 46821.5765507388
     48430 | (139.839,88.984) | SRID=4326;POINT(139.839 88.984) | 1806.77352583032
     93449 | (139.529,88.54)  | SRID=4326;POINT(139.529 88.54)  | 51161.4823829262
    (4 rows)

極域では、緯度に沿った経度1度あたりの長さが限りなくゼロに近づくので、単純に点をxは-180から180、yは-90から90でランダムに割り振ったのでは、点が密集するのは当然。 組み込み幾何データ型では北緯35度付近と同じ近似で計算しているので、全然その密集度合いを取得できない。

最後に、日付変更線付近。東経180度、北緯35度の点の周辺100km検索。

    SELECT ... FROM geodata WHERE distance_sphere(geo_right, GeomFromText('POINT(180 35)',4326)) < 100000;
      id   |    geo_pseudo     |            geo_right             |  real_distance
    -------+-------------------+----------------------------------+------------------
     24810 | (-179.533,34.645) | SRID=4326;POINT(-179.533 34.645) | 58098.3158351517
     30566 | (179.335,34.459)  | SRID=4326;POINT(179.335 34.459)  | 85509.4027250568
     76586 | (-179.842,34.591) | SRID=4326;POINT(-179.842 34.591) | 47712.1839566193
    (3 rows)

    SELECT ... FROM geodata WHERE metrize(geo_pseudo,0) @ metrize(point(180,35),100000);
      id   |    geo_pseudo    |            geo_right            |  real_distance
    -------+------------------+---------------------------------+------------------
     30566 | (179.335,34.459) | SRID=4326;POINT(179.335 34.459) | 85509.4027250568
    (1 row)

組み込み幾何データ型では、西経側で近傍の点が取得できていない。

といった形で、 検索結果の正確さでは、PostGISの圧勝である。

ただし、大問題がある...実は、PostGIS側の検索、全くインデックスが効いていない。
これが1敗と書いた理由。
考えてみれば当然で、distance_sphereという関数の戻り値を比較対象として検索しているのだから、インデックスが効くはずはない。
また、distance_sphereは検索中心の値も取る2引数の関数なので、関数インデックスを張るわけにもいかない。
実は、PostGISも、この辺の関数は割と新しく追加されたもので、内部でのデータの持ち方は、PostGISでもGeo-Spatial（回転楕円体上での空間座標）ではなくSpatial（平面空間座標的）な扱いになっている。
よって、Geo-Spatial的な計算結果を返すdistance_sphereのような形で、インデックスを張る方法は、今のところない（...はず。最新版のマニュアル全部読み返したわけではないので判らないけど）。

インデックスを活かすには、いくつか方法が考えられる。
1つは、まずインデックスが効くようなバウンダリボックス等でざっくりと検索し、その後、結果に対してdistance_sphereでふるいをかける方法。
もう1つは、円をポリゴン図形で近似し、そのポリゴン図形との接触・内包関係を検索する形。
思いつくのはそのくらいなのだけど、普段実務で使っているわけではないので、他によい案を知っている人がいたら教えて欲しい。
これらの案についても、またレポートできたらやってみる。

WEB+DB PRESS Vol.33届いた。
今回はかなり読み応えアリ。思った以上に知ってる人が書いてるな。

そんな中、広告ページで、Asialっていう会社見つけた。
PostGIS＋MapServerの開発キット作ってるみたい。面白そう。
簡単にMAPFILEいじくれるようなUIを用意した商品ってことかな。
Windows版と、サーバの貸し出し？版の２通り＋地図データで売り出してるみたい。
携帯電話への地図出力にも対応ってのも嬉しいなあ。

何にせよこの分野に注目してマジで取り組んでくれるとこが増えるのは嬉しいことです。

地図日記２ってサービスもやってるみたいだけど、こいつが中々強烈。
サイト全面がGoogle Mapsってサイトは初めて見た。インパクトでかし。
地図にブログの情報集約するだけじゃなく、ブログの方に地図も貼り付けられる。...とはいえこれはよくあるサービスだけど、ここのが面白いのは、JavaScriptが有効な訪問者に対してはGoogleMapsの地図を提供し、JavaScript駄目な訪問者に対してはMapServerの静的地図を提供するところ。
これは中々面白いと思った。
ただサイトそのものも、JavaScript切ったらMapServerベースになるのかと思ったら、流石にそれはなかったようだ。
別に地図表示させる事自体は何も難しいことはなかろうが、UIがScriptなしでは難しかったのかな。 

ここの会社の人も、こいつに参加してライトニングトークしてくれないかな...。

そんじょそこらの当たり前の技術には高速道路が引かれてしまって大渋滞の昨今、皆様いかがお過ごしでしょうか。

これからは「ポータルサイト(Googleなど)」と「オープンソース」がGIS業界を動かす、と長年GISに携わってきた人が言い、また巨人マイクロソフトですらGoogle Maps等に対抗するため？Vexcel、GeoTangoと次々とGIS系の会社を買収していっているという状況です。
にも関わらず、世の人の大半は、GIS等というものがどういうものかを知らず、その分野の技術者が払底している状況です。
PostgreSQLで位置情報を扱うといっても、「高速道路の末端の」よく知られた技術範囲だがGIS的には難有りの記事には200件近いブクマが付くにも関わらず、それを補遺して、さらにGIS的に正しい方向を示唆した記事には20件ほどしかブクマが付かない。
（いや、別に妬んでんじゃないですよ、妬んでんじゃないですってば！！そこ！そんなエクスキューズする奴に限って心底では妬んでるとか言わない！今気付いたがプロレス口調とか言われてるが、ちょっと向こうに「PostGISってのもあるよ」とコメントしたところ削除されたので、それでムカついてたってのはあるかもしんない）
ようするに、高速道路の出口で渋滞する人々の、10人に1人くらいしか興味を持たない、或いは出会うチャンスのない技術ってことだ。
私らには驚きな「大巨人ESRIの凋落」とか言ったって、世間的には「ESRIって何？」ってほど知られてないだろうし。

GoogleやMicrosoftといったメインプレーヤーがこれほど注目しているにも関わらず、ここまで知識の伝播範囲が限られた技術分野も珍しいのではないかと思う。
もちろん、GISを覚えたからといってGoogleやMicrosoftに入れるわけでもないのだが、高速道路から一歩先に出る＋αの技術として、GISっていうのはいいんじゃないの？と思うのです。
本当、入門Webマッピングもいいんだが、ApacheやMySQLが単一取り上げ本として多数出版されてるのと同様、PostGISやOracle Spatial、MapServer等も、オライリーさんあたりから単独本が出てもいいんじゃないかと思う今日この頃。
でもって、実務でGISを身に付けてみたい！という人は、是非人手不足で悩んでおられるオークニーさんを、お薦めいたします。
いきなりはちょっと、と言う方は、まずこのイベントでオークニーさんってどんなところか、と覗いてみられればいかがでしょうか。

先のエントリ、（GoogleMapsと連動したいなら幾何データ型よりPostGIS）、PosｔGISの紹介に限らず週末にでも元記事と同様パフォーマンスのレポートとか幾何データ型との比較とか予定しているのだが（もちろん予定は予定であって確定ではない。）。

それ以前に、PostGISのインストールなんて簡単だ！とか大見得切っておきながら、PostGISの初期化スクリプト「lwpostgis.sql」が、ライブラリエラーで通らない。
泣く泣く友人に泣きつく。

「○○えもーん(泣)。」
「しょーがないなあ、ねね太くんは。ほら、”/etc/ld.so.conf”ー。」
「わーい、動いたよ。○○えもんありがとうー。」

こんな奴が何か技術情報提供しようなどとおこがましいにもほどがあると思わないでもない今日この頃です。

横浜スローライフさんを中心として、「入門 Webマッピング」の発売記念飲み会が開かれます。
内輪だけでなく、一般参加者も集う形で、プレイベントとしてオークニーさんオフィスで最新のオープンソースGISの動向を知るデモ等も行われます。
GIS等に興味のある方は、ご自由にご参加ください。
申し込み要領は下記まで。

5月に発刊された待望の「入門Webマッピング」（Web Mapping Illustratedの日本語版）を訳者と共に祝い、梅雨空をオープンソースWebマッピング談義で吹き飛ばしませんか？

●対象者　オープンソースWebマッピングに興味のある方＋そのご家族

●開催日　2006年6月29日（木曜日）

●内容

・プレイベント「Meet at Orkney」（17時から18時45分）
　　会場:オークニー(http://www.orkney.co.jp/corporate/profile.html)
　　　　最近のオープンソース活用の最前線等について、情報交換

・本イベント「Eat at 赤レンガ倉庫」（19時から21時）
　　会場:横浜赤レンガ倉庫3FのBeer Next (http://www.yokohama-akarenga.jp/beernext/)
　　　　入門Webマッピング発刊を記念する会食＆トーク

●参加費（本イベントのみ有料4000円；基本的に飲み代含む）

●参加申し込み方法

　6月26日月曜日午後6時までに、http://utage.org/enkai/　（宴会くん）にアクセスし、宴会コード wmi を入力し、下記の事項を書き込んでください。

　お名前：
　メールアドレス：
　　★備考欄には、下記の内容を必ずお書き下さい
　　・参加するのは：　プレイベントのみ　　本イベントのみ　　両方とも
　その他連絡事項：
　　※キャンセルは28日朝10時までとなります。
　　※遠方より来訪で当日宿泊ご希望の方は、その旨お書き下さい。

XSLTでGMLから変換、とかいう適当な解はさておき、改めて考えてみると、そもそもAsSVG()とかAsGML()といったものをDBサーバで処理することが効率を考えてもあまりうれしくないのは気のせいでしょうか。
　　.........
なので、むしろ必要なのはWKT/WKB/SVG/GML/KMLなんかを相互に内部で変換できる標準的なライブラリかと考えます。

それってPlaggerで(ry

とまあネタはいいとして（Perlerにとってはネタじゃなくて1つの解ですが）、

OGRがKMLの書き出し(のみ、)をサポートするようなので

これにはビクーリ。
本出しておいてなんだけど、MapServerのOGR対応って、データファイルの読み込みのみでしたっけ？出力形式もOGRで扱える形式なら何でも出力可？
もしYesなら、PostGISをMapServerでラップしてやるだけで、既にGoogle Earthとの連携は普通に可ということか。
もちろんNoでも、GLUEとしてMapServerが使えないというだけで、自分でOGRをゴニョゴニョしてやれば、PostGIS⇒OGR⇒Google Mapsでお手軽MushUpなのね。
時代はそこまで進んでいたのれすか...。

あ、判らない人のために、WKT、WKBとは、Well-Known Text及びWell-Known Binaryの略で、よく知られたテキスト形式やバイナリ形式ですので、知らないと恥ずかしいです。
覚えておいてください。

というのは嘘です（略の元は間違ってないですが）。
なんで「Well-Known」なんて名称がついたのかは知りませんが、ごくごく一部の人しか知らない？地理情報を格納するためのデータフォーマットで、当然WKTがテキストベース、WKBがバイナリ形式のフォーマットです。
OGCで定義されてるんでしたっけ。

先のエントリ等書くために、久々にPostgreSQLやPostGISいじろうと、家のPCのcoLinux環境にPostgreSQLインストールしたら、領域いっぱい使い切っちゃってデータベースファイルも作れない状況に。

仕方なく、coLinuxの領域増やす方法探してたら、こんなの見つけた。

coLinux でディスク領域を追加する -ぺんぎん戦記-

まさにこの通りやれば、領域追加できました！ありがとう！

最初このようにやっても中々起動せず、起動しても認識しなかったりと色々あって、気付くとTypoがあったりしたので直して再起動してみても、やっぱり起動しない。
そこでちょっとはまって、なんでだろう...と色々試しては悩んでたら、しばらく放置してたら起動して、追加領域も正常にマウントされた状態に。
でかい領域のマウントって、時間かかるのね。勉強になりました。

1つやってみてのTips書いとくと、最初の「空ファイルを10GB作成」のところで、

最初にCygwinのddコマンドで空ファイルを10GB作成　

dd if=/dev/zero of=home.ext3 bs=1M count=10240

home.ext3はお好きな任意のファイル名でよいです。

XPか2003ならWindowsのコマンドでfsutilというのがあるのでそちらでもよいみたい。
その場合は　

fsutil file cretanew home.ext3 10737418240

バイト数で記述するみたい10G=1024x1024x1024x10 ってことで。
fsutilなら一瞬でできちゃう、らしい。

これ、本当にddだと数分経っても終わらないのが、fsutilだと数秒レベルの一瞬。
迷わずfsutilの利用をお薦めします。

あともう一つ。

データベース上の位置情報を効率的に検索する方法(PostgreSQL編) -Web屋のネタ帳-

DBにおけるインデックスの内部構造とC言語に自信のある人はpoint型用のgist演算子クラスの実装にチャレンジしてみてはいかがだろう。

PostGISがある以上はっきり言ってその辺頑張っても誰も評価してくれまい。

そんなとこで頑張るくらいなら、今、PostGISではSQLでの地理データの検索結果を、GMLやSVGといったXMLフォーマットで直接返すことができるけど、これがKMLに対応すれば、Google EarthやGoogle MapsとPostgreSQLが直接連携できるようにもなる。

インデックスがどうこう実装するよりははるかに簡単だし（俺にはできんが、GMLやSVGの実装参考にすりゃいいだろうから多分そこまで難しくないだろう）、はるかに　ネ　申　になり易い。

腕に自身がある人はチャレンジしてはどうだろうか。

なんか向こうのコメントに書き込んだのだが、よく判らんが削除されてしまったのでこっちのエントリで取り上げる。

データベース上の位置情報を効率的に検索する方法(PostgreSQL編) -Web屋のネタ帳-

たとえばおいしいケーキ屋さんの位置情報がデータベース上にあるとしよう。...GoogleMapsなどである範囲の地図を表示したとして、お店の位置を地図上にマーキングさせたい場合には、その地図の範囲の情報をキーにしてデータベース上の緯度経度を検索する必要がある。
　　.........
だが、ひとたび

• ある1点から半径rの円内に該当するデータを検索したい
• さらにその検索結果を、中心点からの距離でソートしたい

といったことになると、とたんに難しくなる。しかし、PostgreSQLにもう5年以上前から実装されている幾何データ型、幾何関数、幾何演算子を使えば、SELECT一発でできることだ。

幾何データ型という親しみのない型に関していろいろ情報公開してくれるのはいい事なんだけど（俺も知らないことあったし）、こと「GoogleMapsと連携」等と分野を絞って記事を書いた途端、すげえ的外れな記事になる。
それを3桁に及ぶ人が軒並み「GoogleMaps」、「GIS」、ありがたやありがたやとタグ付けてるの見ると、この業界もまだまだ知られてないんだなあ...とがっくりくる。

まだMySQL使ってるのなら判らないでもないが、なんでPostgreSQL使っているのに、位置情報扱うのに組み込みの幾何データ型使う必要がある？
なんでPostGIS使わない？

座標（当然GoogleMaps等との連携で考えてるのだから経緯度データを考えてるのだろう）で突っ込んだデータを、幾何データ型使うと半径ｒの円検索できる！と元記事では書いてたけど、経緯度ベースで円検索して何が嬉しいんだ？
この辺見たら判るとおり、経度に沿った緯度1度分の長さと、緯度に沿った経度1度の長さは全然違うぞ。緯度に沿った経度1度分の長さは、その地点の緯度によっても大きな誤差が出る。
それとも、Proj.4ライブラリ使って、mベースの座標系である19座標系に変換した上で格納するのか？Proj.4インストールして使いこなせるなら、素直にPostGIS使っとけ。

少なくとも、飽くまでPostGISは難しすぎる、組み込み幾何データ型でざっくりGoogle Maps連携できる！とか記事書くんなら、むちゃくちゃとんでもなく荒すぎる近似だけど、東経135度、北緯35度付近の経度1秒分の長さ25.36m、緯度1秒分の長さ30.82mで日本全体を近似して、

CREATE FUNCTION metrize(point) RETURNS point AS'
    DECLARE
        ret point;
    BEGIN
        ret = point(($1[0]-135.0)*60*60*25.36,($1[1]-35.0)*60*60*30.82);
        RETURN ret;
    END;'
LANGUAGE 'plpgsql';

みたいな各経緯度座標値を東経135度、北緯35度からのざっくりm座標系に修正する関数でも定義して、それをベースにインデックスは

    create index testindex on geodata using gist(circle(metrize(geo),0));

検索式は(東経140度、北緯40度を中心とした超雑雑ざっくりいい加減周辺400m検索)

    select * from geodata where circle(metrize(geo),0) @ circle(metrize(point(140,40)),400);

みたいにする、とでも書かなきゃ、幾何データ型でGoogle Maps云々は嘘だろう。
別にPostGISがあるんだから、こんな言い加減な事するの薦めないけど。

別にPostGISの導入は難しくない。
Windows版のインストーラなら、標準で最初に導入を選択できるオプションとして付いてくる。
ソースからのインストールだって、前提となるProj.4ライブラリ・GEOSライブラリも、以前は難しかった記憶があるが今は、昨日久々にインストールしてみたらconfigure実行するだけで普通にコンパイルできた。
PostGIS自体も、以前はPostgreSQLのソースツリーの中に突っ込まないとコンパイルできなかった記憶があるが、今は普通にpg_configの場所さえ指定してやれば後から追加できる。
簡単簡単。
たったこれだけで、ちゃんと地理座標系を考慮した、多次元のPOINT型はもちろんLINE型、POLYGON型といった地理図形オブジェクトが格納できるし、共通に空間インデックスを張る事もできる。
distance_sphereやdistance_spheroid系の関数を使えば、ちゃんと地球という回転楕円面上で測定した距離を元に、検索することもできる。
地理図形オブジェクト同士の衝突や接触、内包判定から、地理オブジェクトをマージして、新たな地理オブジェクトを作る、といったことも簡単に出来る。
他でもないPostgreSQLで、地理データを扱うと言うのに、PostGISを使わずに何を使うと言うのか。

また最近ではPostLBSなんてのも出てきてて、円検索どころか、道沿いに一定距離歩いて/運転して到達出来る範囲の検索や、巡回セールスマン問題とかだって、「PostgreSQLのSQLクエリーの上で」解けるようになっている。

最近横浜スローライフさんは、Where2.0の雑感記事で、

れからは「ポータルサイト（GoogleMapsとか）」と「オープンソース」がこの業界（GIS・位置情報）を動かすようになると思う。
それらは互いに対立することもあり得るが、同時に「ポータルサイトの公開API」に「オープンソース」を組み合わせる（Mush up）ことが”常識”にもなっていくだろう。

と書かれていたけど、世間ではその「オープンソース」とやらは、所詮LAMP（「L＝Linux（プラットフォーム）」「A＝Apache（プレゼンテーション層）」「M＝MySQL（データ層）」「P＝PHP（ロジック層）」）の言葉で代表される分野にしか視野は当たってなくて、それ以外の世界があるという事にも気付いていないのだなあと実感。
常に動きの中心にいるGoogleが、最初は測地系も投影法もろくに判っていないところからGoogle Maps始めて、いまや押しもきらないGIS分野の中心プレーヤーになりつつあるというのに、その信奉者連中にはまだ全然GISの情報等浸透していないのだなあ、と思うとがっくりくる。

手前味噌ながら、この本でも読んで勉強しなはれ。

最近、ねねたちが、ねねたちが、ねねたちが、ペテン師をオープしなかったよ
とか書いてみるの♪

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

Yadis/OpenIDでのメーリングリスト経由で、こんなエントリを見つけた。

Collaborate! -Beyond the Walled Garden-

FOAFをベースにしたユーザネットワーク交換APIで、複数のSNS・コミュニティを結びつかせる分散ソーシャルネットワークのアイデアを書いている。
SNSを繋ぐ...Netに対するInternetならぬ、SNSに対するInterSNSというところか。
同じFOAFベースでも、認証をOpenID等をベースに、FOAFでそれを結びつけようとしてる俺の案と違って、FOAF自体を拡張して認証APIを持たせようとしてる。
膨大なMySpaceが誇るユーザ数に対し、残りのSNS全体のユーザ層をロングテールと考えて、ここを制すればMySpace恐るるに足らず、と考えてるのは面白い。
また、やはりSNS上のメッセージングを重視していて、FOAF API認証上でのメッセージング実現まで考えてるようです。

全般的に考えが私と似ていて、面白いなと思いました。

---- 追記 -----

このブログ、このエントリしかないのか。
まさに、この発想をこれからここで育てていくために作られたブログなわけね。
ここでも、位置情報に未来を感じて「ここギコ！」作った俺に似てる＾＾；
名付けて「Beyond the Walled Garden」...「閉ざされた楽園を越えて」か。
閉ざされた楽園＝クローズドなSNSをぶっ壊して、その向こうにあるものを見たい、という心意気の表れだね。
その意気や良し！頑張れ、20世紀少年！

横浜スローライフさんのWhere2.0雑感で思ったこと。

これからは「ポータルサイト」と「オープンソース」がこの業界を動かすようになると思う。
それらは互いに対立することもあり得るが、同時に「ポータルサイトの公開API」に「オープンソース」を組み合わせる（Mush up）ことが”常識”にもなっていくだろう。

それは全く同感。
なんだけど、同じエントリの中で、

マッシュアップサービス系：PSP(Push-pin Service Provides；勝手に命名）

何社もの新興のPSP達が積極的に宣伝をしていた。彼らはGoogleの公開APIを使ったり、独自のものを開発したりしている、要するに”なんちゃってGoogle Maps”だ。
アメリカでは本当に気軽にビジネスを始めてしまうんだなぁ．．．ほとんどの会社がここ数ヶ月内に始めたばかりで、ビジネスモデルが見えないので私には彼らが成功するようには思えない。

と書かれてる。
それらの大半が成功するように思えないというのは判らないでもないのですが、その辺をフォローして育てていくのがオープンソース系の役割ではないのかなとか思ったり。

だって、個人レベルのマッシュアップがいくら積みあがってもオープンソース系にお金が落ちるとは思えないし、これまでどおりの独立システム開発で儲けるならマッシュアップとか考える必要もないわけなので。
お金になるマッシュアップの担い手となれば、まさにそのPSP達ではないのかなと思うのです。

これまで馬鹿高い地理系データと著作権、馬鹿高い地理データ処理ソフト、あまり知られていなかった知識、でアイデアを思いついても形に、ビジネスにできなかった状況だったわけですが、ポータルサイトとオープンソース双方の革命でそれらの障害が取り除かれ、簡単にPSPを立ち上げられる状況になった背景から考えるに、オープンソース系としては彼らをフォローし、育てるのが役割ではないかと思いました。

まあ、とは言え、ビジネスモデルの見えないPSPはオープンソースGISコンサルタントにすら払うコストも節約するため、オープンソースなだけに自分達で開発するかもしれないし、横浜スローライフさんとしてはビジネスのパートナーとしては視野に入れてないのかもしれないけど。
冒頭の見通しは、

• 個人・PSP問わずマッシュアップを通じてオープンソース系のプレゼンスは上がっていくだろう（それ自体がお金になるかは別として）
• それによって徐々にオープンソース系は、プロプライエタリ系のシェアを奪っていくだろう
• ただし、やはりオープンソース系が利益を出していくのは、従来どおりの独立システム開発で、シェアを奪った結果として、今後利益が上昇していくだろう

というふうに解釈すべきなのかな。

で、そのスローライフさん命名のPSPの中にも、面白い動きが。

GeoITなエアライン

で、私が座った席の後ろの席から、会話がちらちら聞こえてくる。
最初は特に気にもとめなかったが”GeoRSS”という言葉を聞いて！！耳がダンボ状態になった。
　　.........
飛行機を降りる際に、顔ぶれを見てみたら、何と講演をした人が座っていた。
ポートランドにある新興のPSPのPlatialだ。

2年以上も前からWebへの位置情報埋め込みを考えてきてて（いや、もっと前から考えている人もいるのでパイオニアを気取る気はないのだが、パイオニア「群」の1人と思ってます。）、RSSへのGeoボキャブラリ埋め込みについても取り組んできた身としては、ビジネスレイヤの方がそのような事を当たり前に口に出すような時代になったのが嬉しいような、そこに自分の立ち位置がないのが悲しいような。
しかしそのPlatial、日本の情報も結構あって、日本でも使われてるんですね。
私全然知らなかった。
昔はWeb上の位置情報関係の情報と言えば、うちに自然に集まってきて知らないサービスなんてない状況だったですが...今は乱立しまくって全然把握できていない状況。
本当、隔世の感があります。

ボーナスも出たので、長らく使ってきた当時の「全部入り」名機A5505SAから、当代の「全部入り」W41Hに機種変更しました。
3年に2回は韓国に行く個人的には、韓国でもそのまま使える「グローバルパスポート」機能をどうしても引き継ぎたかったのですが、A5505SA以降auはもうグローバルパスポート機を出さないっぽいので、もういいかと(よく調べると、A5514SAってのも出てますね。でもさすがにそろそろWINに行きたかったし仕方ない。)。
そもそもDoCoMoと違ってauって「売りの新フィーチャ全部入り機種」ってのが少ない気がするのですが、W41Hはグローバルパスポート除けば全部入ってるので、これしかないかなと。

ワンセグとかは中々いい感じ。
今まで個人テレビ持ってなかったから、クレードルに載せて部屋でテレビ見れるのは結構嬉しい。
今もテレビ見つつブログ書いてる。

バーコードリーダも、A5505SAのバージョンだとアプリ内でしか読取結果を利用できなかったのだが、読取結果をテキストファイルとしてデータフォルダに保存できるようになった。
直接特定URLの引数に与えるとか、いろいろできればもっと使い出があるのだが、しかしこれで他の機能でも利用できるようになっただけでも大きな進化。
こういう機能の進化は嬉しい。

でも、この機種、今触った限りでは、ユーザビリティが最悪...。
例えば、反転型液晶で反転機構をつけるためには仕方ないのかもしれないが、携帯を開くと液晶側の筐体が後方に盛り上がり、右手親指でキー操作するポジションで持つとそこが人差し指あたりで邪魔になり、非常に使いにくい。

それに同じポジションで、レンズが掌部分にやってくるので、すごく汚れ不安。
ワンセグTV用に反転液晶、そのついでにデジカメライクなカメラの使い方を実現するにはこの配置しかなかったのかもしれないけど、それならそれでレンズシャッタをつけるとかできなかったのか。
おまけにこの配置でQRコードを使おうとすると、レンズを隠さないように持たざるを得ず、その結果レンズより下----開いた携帯全体から見れば上から5分の3以下の位置----だけでケータイ全体を支えないといけない。
使いにくすぎ。

最悪なのは反転液晶時の操作。
名機A5505SAは、表裏液晶があり、ケータイを閉じた状態でも種々の操作ができたのだけど、ちゃんと大きな内側液晶と小さな外側液晶用のインターフェース画面が用意されていて、外側液晶で出来ない操作はちゃんとメニューに出てこないようになってた。
でも、W41Hの場合、液晶を反転させた時に出てくる画面は、単に内側に向けた際の画面を反転させただけ。
一応側面にあるいくつかのボタンで、決定やカーソル移動を代替し操作は出来るんだけど、操作ボタンの位置は当然内側とは違うので画面上の表示は頼りにならず、どの操作がどのボタンにあたるかはユーザが覚えないといけない。
おまけに内側操作時の同じ画面が外側でも出てるだけだから、全ての操作ができるわけではなく、できない処理の部分のところにくれば、液晶を内側に向け直すしかない。
そして極めつけは、反転時の側面キーと内側キーの対照は、決まったものではなく、アプリ？単位で対応/非対応があるっぽいこと。
基本メニューを外側で操作して、側面キーでカーソル移動や決定を操作してきたのに、アプリを起動した途端、そのアプリ上では側面キーが通用しないことがあった。
何なんだよ、と言う感じ。

というわけで、「全部入り」の個々の機能はいいんだけど、使い勝手が最悪と言う、W41Hはそんな端末でした。

金曜は客先での設計審査報告会。
職場は6月に入ってクールビズ（ちなみに俺は冬もノーネクタイだったが）化、客先もクールビズ制度、ということで、会議の時とかはクールビズでよいという話だったので、ノーネクタイで行った。
そしたら、さすがに審査会、ということもあってか、みんなネクタイ着用。
着けてないのは俺と一人の課長だけ。その課長も出先事務所待機の社員から借りて着けてたので、実際に会場で、メーカ側で着けてないのは俺だけ。
「チャレンジャーやなあ」とみんなに言われた。

俺は結局ノーネクタイで通して、おまけに柄Tシャツが雨に濡れて透けてたので、他人を不快にさせる格好はするなよ、と打ち上げで部長に軽く叱られた。
同じくノーネクタイの課長も、「なんや、着けてないだけでちゃんと持ってきてたのかと思ったら、他人から借りていたのか」と部長に言われていたが、「いやあ、出来る男は何時でもネクタイは用意してるんですよ」「他人の鞄の中にな」等と掛け合ってるのが中々笑えた。

しかし同じ報告会でも1年前は何をしてよいか判らず居場所もなく、自分に無能感を覚えたもんだが、1分野を任されたサブリーダーとしてちゃんと役割があって、居場所がある目からみれば全然違うもんだなあと実感。
前回を上回る、事前・当日含め500件のクレームが来て、同じく当日中に全件、最低限解決の目処を確認するまで終わらないのは一緒だったのだが、今回はその処理に感嘆するよりは、効率の悪さに閉口するばかり。
紙ベース（これは客要請だから仕方がない）でのクレーム表、新規指摘や回答への判定が届くたび、老眼で読み取るのもしんどそうな総務系の初老社員が通番とステータスを読み上げ、別の総務社員がノートPCでエクセルを操作し、ステータスを更新していく。
新規も判定も次から次来るから、ステータス管理のファイルは総務連中の更新作業でずっと占拠されてて、誰も確認できない。
俺は弱小サブリーダーなので、クレームも管理できる範囲なので自分の処理すべき懸案リストを別途用意しておいたので、総務連中が読み上げる番号とステータス盗み聞いてだいたい管理できてたが、その辺してなかったサブリーダーは自分の案件がどの程度あって何件消化されてるのかも全く確認できない。
客先から懸案の処理状況の報告を要求されても、結果を出すのにお客さんを1時間近く待たせるし。
果ては、懸案の処理状況をPCで確認できないから、みんな完了したクレーム表を紙で綴じたファイルを見てステータスを確認してたんだけど、報告会前日に電子ファイルで客先から総務に届いた判定は、エクセル管理はされていたけど紙では綴じられてなかったため、まだ客先が未判定、回答をもらわないといけないと思ってた懸案が本当は既にクローズ済みで、報告会終了後職場に戻った客先の担当者をわざわざ会議室に呼び出してもらって回答を確認したら、「それは昨日回答したでしょ」みたいな不手際もあったりと、何やってんだか、と思ってしまう。

そんな効率の悪い事しなくても、簡単なトラッキングシステム立ち上げて、数台のPCをNWで繋いで共通管理ですれば、ステータス管理も総務がやらなくても各担当者が直接並行して入力できるし、ステータス管理も各人並行して同時に自由にできる。
そうするだけで、少なくとも総務2人のその日の作業は不要になってたし、プロジェクトメンバーのストレスも格段に減らすことが出来る。
去年の報告会の直後も、そういう提案したし、このエントリに書いたような事も、先期の人事評価時に部署への提案事項として挙げて、課長も部長も目を通しているはずなのに、何故変わらんのかね。
それどころか、打ち上げの時の話題として、「関連会社に人材を派遣させる時は、2～3日徹夜しても倒れないような、丈夫な奴送ってくれよと要求してるんだ」とか寝惚けたこと言ってて。
ほんま、プロジェクト内のほぼ全ての処理が、ヒューマン「が」インターフェース、ヒューマン「が」ビジネスロジック、ヒューマン「が」データストレージ。
今までのプロジェクト規模では、効率度外視のそんな体育会ノリでできたのかもしれんが、今回の規模になるとそれじゃ通用しないと、何時になったら気付くのかね。

実はもう1ヶ月以上、MLの内容も追えていないYadisだが、今日久しぶりに見てみるとJanRain社がPerlのYadis、OpenID対応ライブラリの新バージョンを発表していた。
JanRainといってもどこじゃそら、という感じだと思うが、OpenIDの本家サイト以上にOpenIDの話題を扱っている大御所サイト、OpenID Enabledを運営している会社だ。
OpenIDの新仕様、プロファイルの交換プロトコルなんかもここから出てきてて、今のOpenID・Yadisの中心的役割を担ってるところの1つ。

これまでOpenIDのPerlライブラリと言うと、OpenIDではNet::OpenID::ServerやNet::OpenID::Consumer、Yadisでは拙作のNet::Yadis::Discoveryなんかがあったわけです。

だけど、これまでのOpenIDライブラリはどうも最近更新されてないっぽいのに対し、JanRainのはまさに今進化の真っ最中だし、先のプロファイル交換プロトコルや、セッションを盗まれる脆弱性の問題なんかにも対応している。
これからはJanRainのOpenIDを使っていくべし、と個人的には思う。
昔はあまりCPANを重要視してなかったっぽいのだが、最近はCPANにもちゃんと登録されてるし。
まだ私も一度も使ってないけど。

一方のYadisは、俺の能力というよりはYadisの場合APIのProposalがあった事もあり、ざっと見たところはインターフェースはそこまで大きく俺のと変わってる感じはない。
あっちのライブラリがまだ0.7だった頃に一度比較したことがあるんだけど、あっちではエラーでまくりのテストケースが俺のではちゃんとパースできたりと（俺の手柄じゃなくXML::Simpleのお陰だが）、1.0になってからは知らないが昔はうちのがよかったという自負はある。
ただ...正直、今の生活が続く限り俺はこれ以上Yadisの細かいところは追えない。
更新もかなり無理。
社を挙げて...かどうか知らないが、少なくとも何人もがYadisにコミットしている、おまけに英語母語連中のJanRainに勝てるとも思えない。
よって、もしこれからYadisに取り組むなら、やはりJanRainのライブラリを使う事をお薦めする。
こいつももうCPANに挙がってるし。

試してないけど、同じところが作ってるから、YadisとOpenID間の連携もうまくいくのだろう。

というわけで、基礎的なAPIの開発はJanRainにお任せして俺はその辺から引退して、俺はこれからは、それを使って何ができるか、Yadisがなんの役に立つのか、そういう応用を考えて、できれば作っていきたいなと思う。
或いは、やはり基礎的なところを開発するなら、Geo::Proj4関連に比重を移すか。

Where2.0でTyler Mitchellに本を贈呈 -横浜スローライフ-

Google's Geo Developer Dayお気楽レポート -ドナドナ日記-

ペタウラヤマシス。
Google Maps APIジオコーディング対応とかの発表もあったんだよなあ。スゲエなあ。
ちなみに隣の席のGIS会社から来た係長にこの記事見せたら、「ISO的にはジオコーディングとは画像を北に合わせる事で、住所から位置を引くことはISOではジオアイデンティファイと言うんだよ」と教えてもらった。
ほんまかどうかはよく知らんが。

しかしスローライフな人にも「Where2.0行こうよ」と誘われたけれども、金がない以上に、忙しくてとても行ける状況ではなく。
今週末客先での設計書説明報告会、今月末設計書納品。
事前送付した設計書初版に対する指摘事項が客先からバンバン飛んできて、全部こなしたと思えば次のが受け入れフォルダに入っていたりと終わりのない状態。
相変わらず、懸案管理はヒューマン「が」インターフェース、しかも「回答は個別に返さず、同じ人からの質問はまとめて回答しましょう」なんて意味の判らん規則のせいで、並行処理も不可能でシーケンシャルにしか処理できない。
ちょっとでも効率化しようと、はてなで　こんな質問する始末。
おまけに並行して見積もりはやらなきゃならんわ、設計の残件も調査決定しなきゃだわ、報告会パワーポイントは作らなきゃならんわ、設計書修正の指揮もとらなきゃならんわで、月曜水曜と終電帰宅状態。
出口はどこだ2.0。

火曜は？というと、家内不在の曜日なので、息子を幼稚園に迎えに行く当番の日だったのに、20:30までの預かり期限なのに仕事に追われて忘れてしまい、気付いたのが既に20:30。
慌てて連絡して先生に待っててもらって、通勤片道1時間半のところ品川からタクシーに乗り換えて何とか21:30引取りの鬼親状態。
平身低頭。平謝り。

そんな中、家内は韓国での言語学会の発表者として選ばれたらしく、週末ソウルで発表との事で、明日朝からソウル行き。
ええなあ。うらやましい。
俺は金曜客先報告会で、飛び出た案件同日内に処理するまでは絶対終わらないので、幼稚園に迎えに行けるはずもなく、仕方ないので息子は関西の家内方祖父母の家に預かってもらう事に。
これまで家内と2人で泊まったことはあるが、両親とも不在で泊まった事はないので、不安で息子は爆泣き状態。
ちょっと可哀想。
日曜、家内がソウルからの帰りに拾って帰ると言っているけど、土曜に俺が迎えに行ってやろうかなあ。

ちょっとサイドバーなぞいじって、最近のコメントとトラックバックを一覧できるようにしてみたのですが、トラックバックの一覧が自分の過去記事へのTBばっかになってしまいテラウザス。

自分の過去記事にTB打つの、弾さんとこがやってて、自分の過去記事から最近の記事に至るルートを作るのにヨサゲと思って真似を始めたんだが、うちみたいにあまり他人に絡んでもらえないサイトだと寂しさ大強調な感じでちょっとアレ。

自サイトからのTBは一覧タグの対象から外すような拡張とかあればいいのに。
Compareプラグイン入れてるからブログ名比較して外す事はできるのだが、それだとlastnの設定で決まった数のTBを表示することができない。
Collectプラグイン使えばうまく出来そうな気もするのだが、ロジックややこしそうなのでまだ考えてない。

ああ、何かいい方法ないかなあ。

あ、ついでにお礼を言っておくと、サイドバーの項目のオープン/クローズをするスクリプトは、Drk7.jpさんのところのスクリプトを再利用させてもらいました。
再利用要請への快諾、ありがとうございました。

さっきのは、答えとしては一応あってたみたいだけど他の人の模範解答と比べると、書き方がエレガントとは言えなかったみたい。
まあえれがんとなにんげんぢゃあないことはせんこくしょうちなので、正解であっただけでもよしとしよう。

後の記事にリアルタイムで出題中の記事があったので、こっちにも挑戦...と思ったら、これも締め切り済みだったか！
30分くらい考えた末に解けてから気付いたので、こっちも悔しいので遅れたけどやっぱり回答。
最初、エントリのタイトルは「間に合いながら参戦」のはずだったんだけどなあ。

ミネラルウォーターの謎、謎解き編 -Life is beautiful-

ある直線上に線分AとBがあります。線分Aの両端の座標はそれぞれA0とA1(ただしA0<A1)、線分Bの端の座標はそれぞれB0とB1(ただし B0<B1)とします。そのとき、線分Aと線分Bが一部でも重なる（一点だけで接している場合も重なっているとみなす）ための条件を出来るだけ簡単な式で書いてください。

逆に重ならない条件を求めてみる。

1. AがBの右にある場合、A0-B1 > 0で重ならない。
2. BがAの右にある場合、B0-A1 > 0で重ならない。

ここで、1.の場合にA1-B0 > 0、2.の場合にB1-A0 > 0が普通に成立することを考えると、重ならない条件は、(A0-B1)(A1-B0) > 0。
よって、重なる条件は、! ((A0-B1)(A1-B0) > 0)。

正解かどうか見てないけど、上記求めた後、

みたいに指に線分端の記号書いて、内包ケースとかかするケースとかいろいろチェックしたんで、多分間違いないだろ。
我ながらアホなことやってると思うが。

最初、

1)　Aが外包するケース　A0<B0　A1>B1
2)　Bが外包するケース　A0>B0　A1<B1
3)　Aが右にあるケース　A0<B1　A1>B1
4)　Bが右にあるケース　A1>B0　A1<B1
A0<B0<B1より、1)と3)はまとめられる。
　　A0<B1　A1>B1　⇒　A0<B1<A1
......

みたいな考え方してたので、ちょっとハマった。（上は思考中に書いたメモなので、境界条件かなりぶっ飛ばしてます）

--- 追記 ---

答え見た。
しまった。
重ならないケースの、否定！否定！否定！で頭が止まってしまってて、! ((A0-B1)(A1-B0) > 0)　⇒　(A0-B1)(A1-B0) <= 0 になるのを変形し忘れてた。
アホやねえ。

例題１．時計の長針と短針は、１２時にちょうどピッタリと重なります。次にピッタリと重なるのは何時でしょう。

例題２．サイコロを２個、順番に投げることにします。１つ目のサイコロの目の方が二つ目のサイコロの目より大きい確率を求めてください。

気付くのが遅かったが遅ばれせがなら参戦。
他の人のは見てません。

例題１：

12時過ぎたら長針の方が速く回ってまた12のところに戻ってくるから、12時中にはもういっぺんは会わない（当たり前だが一応確認）。
短針が追いつかれて周回遅れになるのは1時と2時の間。よって13時台はガチで、問題はその時の長針の位置。
ここで、13時？？分にぴったり重なるとして、その次を同様に考えてみると、14時？？分にまた重なるのが判る。
続けて考えると、15時、16時......23時？？分、とぴったり重なる時があるのが判る。
しかし最後の23時？？分は、ここの証明を要求されると辛いけど、直感的に明らかに23時60分、つまり24時。
よって短針が一周する間に、長針と重なる回数は11回と判る。
だから、12時を過ぎて1回目に短針と重なる時の長針(まあ重なってるんだから短針もだが)の位置は、全体の11分の1の位置。

すなわち答えは、13時「11分の60」分、つまり13時5分27秒強。

例題２：

1投目と2投目の6×6のマトリクスを書くと、対角線の6ケースが同じ目が出るケース。
残りのうちの半分が、2投目で大きくなるケース。

よって、確率は36分の15＝12分の5。

どやろ？ドキドキ。

携帯電話GPSミックスさん経由で知ったネタだけど、

ITmedia +D モバイル：KDDIと米Google、Google Mapsをau携帯向けに提供？

提供予定の新サービスとして挙げられているのが、au端末に搭載しているGPS機能とGoogleが提供している地図サービス「Google Maps」を連携させるというもの。
　.........
ただ「auの携帯電話がGPSを搭載しており、それをウリにしているのは事実。地図検索サービスなどと連携することは技術的には可能だろう」と話し、可能性は否定しなかった。

いや、単に連携するだけなら、可能性も何も、とっくにいろんなとこで勝手サイトででもやられてるんですが。
うちのこの記事で紹介した、なおっきさんとこのとか（すみません、同じ記事で紹介しているここギコ版au向けGoogleローカルは、ちょっと前のHDD障害サーバあぼーん以降、復活させてません、すみません）。
大会社と大会社が提携して出てきた結果が、単に勝手サイトで出来てる事と同レベルじゃやばいよね。
というか、Googleさん、そのレベルでいいんなら、俺雇ってくれたらKDDIだけと言わず、DoCoMo・au・ソフトバンク・WILLCOMの主要4キャリアのGPS・簡易位置情報対応機種全部、明日中にGoogleローカル対応させますけども。
（いや待てよ、Googleは多分内部で使ってるのはPerlじゃないから...すんません、1日と言うのは撤回します、1週間くらいにまかりませんか。）

えーここまでの前段は要するに「その程度で終わるはずがあろうか？いや、ない」という壮大な反語表現ですので、もっと大きな＋αがあることを期待するわけですけども、そうなると出てくるのはやはり御大「goSVG」ではなかろうかとオイラなんかは期待しちゃうわけだ。
というか、PCサイトの代表的な地図・情報重ね合わせサイトを携帯の世界に招き入れるにあたって、いくら研究部門主導で主流派ではないとはいえ、携帯等向けに自社が提唱する、それに関して特許まで取っているような地図向けの情報重ね合わせ技術・規格、goSVGを絡ませてこないとなると、そらKDDIアホかいな、という事になりますわな。
KDDIはgoSVGやる気ナシ、と世間に公表するようなもんになっちゃう。

で、予想が当たってgoSVGが絡んでくるとなると、goSVG対応アプリケーションとしてますますMapServerにスポットがあたるようになって。
でもってMapServerを日本語及びgoSVG対応させた　　ネ　申　　として、私の盟友ならぬ盟社ともいうべきオークニー社さんがますます注目されるようになると。
ぬっしっしっしっし（こんな怪しいオサーンが慕ったばかりにビジネスに損害を与えてしまえばすみません）。

とまあ相変わらずの妄想大爆発させたところで、他にも書かれてる内容を読むと、

またGoogleのメール機能Gmailを取り込み、auの端末とPCとの間で簡単にメールのやりとりができるようにするサービスも検討しているという。

これは素直に嬉しいな。
Gmailをau端末からも使えるようにしてくれるって事だよね。
GmailにはPCメールを転送してるし、PCメールアドレスで発送できるようにもしてるから、事実上携帯とPCのメールを統一化できるって事だ。
WILLCOMあたりじゃとっくに普通に出来てる事だろうけど。

先週末にひいた風邪、まだ引きずってます。
症状は頭痛・喉痛・微熱から咳・鼻水・痰にうつってるのですが、今週半ばには一度悪化しまして年休も1日。
今も続く咳に悩まされていますが、今日医者にかかった感じでは、倦怠感・疲労感も取れてて咳・鼻水・痰だけなので、風邪そのものが続いていると言うより風邪で誘発されたアレルギー症状だろうと。
しかし咳しすぎて腹筋痛い。

んでさ、やれペインクリニックやらメンタルクリニックやら、内科といえばかかりつけ、かかりつけのしまっている日に悪くなったら別の医者、等とあちこちの医者に行ってると、診察券ばかり溜まって財布は太るわ、それを嫌ってしばらくそこにはかからないだろうと思って財布から出してたら、かかりつけの休診で急遽行く必要になったと思えばなくしてたり持って出忘れたりで、「すみませーん忘れましたー」「また作っときますか？」で気まずい思いしたり。

昔ね、保険証が世帯1つだった時代、毎回保険証持ち歩く代わりに、医院毎に個人単位でその代理をしてくれる診察券は、そりゃ便利なもんだったと思うのよね。
でも、今は個人が一つ保険証持つ時代でしょ。
医院毎に診察券作って個人の管理すべき対象増やさなくても、保険証でええやんけ、と思う。
百歩譲って、保険証番号の他に医院毎の管理コードを加えないと、医院での管理が煩雑になる、と言うようなことがあるのだとしても、そんなの保険証がICカード化されていて、各医院が必要な情報を割り当て領域に記録していけばいい話だろ、と思う。
というか、今の保険証って、QRコードとか付いてて変なレベルでハイテク化されてるかと思えば、単なるプラスチックカードに表層的な印刷されてるだけで、1年も財布に入れてるとあっという間に掠れて記載事項が読み取れなくなってき始めてたりして、なんか中途半端なんだよな。

昔医療機関でバイトしてたから判るが、診察券で管理してる項目なんて、所詮国保か社保か、本人か家族か、医療受給対象者か、後は医療機関毎の患者番号、程度の話だろ。
その程度だったら、磁気カード化された大病院の診察券とかはともかく、そこらの中小医院の診察券なんか、自分で厚紙に上記管理事項記載して、後は医療機関毎の患者番号書いた、オールマイティの診察券1枚自分で作ってやろうか、とも思ったりもするのだが。
そんなの出して、果たして受理してもらえるだろうか...（まあ、受理されなければ保険証出せばいいんだが）。