昨年のGW前くらいにうつ病になって、それ以来抗うつ薬を飲んでました。
うつは直ったと思ってもうかつに薬を止めるとすぐ再発すると聞いていたので、比較的元気になっても続けて飲んでいたのですが、秋くらいに血圧がえらいヤバイ数値になってそれが1ヶ月以上続いたので、調べてみるとトレドミンという薬に高血圧の副作用が。
試しに徐々に止めてみると、それにあわせて血圧が比較的落ち着いてきたし、精神面も別段落ち着いている感じだったので、3ヶ月くらい完全に抗うつ薬の服用を止めていました。

だけどマッシュアップアワード応募で無理したあたりから、体の疲れが溜まって取れなくなって、肩や手が石のようになったままの状況が続きました。
大体こういうのは精神の緊張とかからきてて、去年のうつ病の時も、精神症状だけじゃなくて上半身が鉛のようになる状況が続いて、半年カイロプラクテックに通っても全く直らなかったりりしてたのが、抗うつ薬を飲んだ途端精神症状だけでなく身体症状も飛躍的にマシになったりしてました。
で、今回はそれに比べれば全然マシだったんですが、それでもマッシュアップアワードが終わって半月経って、比較的ちゃんと睡眠取ってても全然疲れが抜けないので、予防措置として抗うつ薬を規定量の3分の1（要するに1日3回のものを1日1回）ほど飲み始めたら、ずいぶん楽になりました。

ところが、今日の朝、たまたま薬を飲み忘れたら、身体症状だけでなくうつな精神症状が。
とりあえず昼過ぎに薬を飲んでみると、今は収まって爽快な感じですが...。
結局うつ病って、正常な脳内信号の伝達を司る脳内物質の欠乏で発症して、抗うつ薬ってその脳内物質が脳内で排出されるのを抑制することで脳内物質濃度を高めることで状況を改善するわけなのですが。
ある程度まともに働いている状況で抗うつ薬を飲んだりすると、脳内物質が過剰になって生成が抑制され、薬を止めると欠乏してうつ様になる、というようなこともあるのでしょうか。

ETech07 - AmazonEC2を無料で試せる RightScale -たたみラボ-

相変わらずいい情報をありがとうございます。
早速試してみましたが、RightScaleすごくいいです。

何がいいって、やっぱりWebからサーバイメージを生成して、イメージの作成日時等まで含めてS3への登録まで、Webからボタンポチでできてしまうのがすごくいいです。
今まではいちいちSSHで接続して、ややこしいコマンドラインコマンドを打たなければ（シェル化はしてましたが、それも自分でやんなきゃだし）イメージの作成ができず、またイメージのS3登録まであわせると、EC2サーバ上での手順と手元のクライアント側での作業が混在するため、中々自動化はできなかったんですけど。
（あ、でもよく考えたら今ここギコサーバ上で動かしてるEC2制御用のCGIで使っているロジック、EC2サーバ自体の上で動かしてやったらさえ、自分のイメージをS3へ転送する事はできるから、EC2サーバ内で完結してイメージ作成→登録はできてたな...まあ、RightScaleを知ってしまったのでそっち使いますが）
でも、RightScaleを使うと、その面倒くさい手順がボタン一つで終わってしまうので（時間はかかるけど）すごく便利。
簡単に定期バックアップくらいの感覚で、イメージ作成ができる。
DBのバックアップ機能もついているので、EC2サーバを運営する際の環境バックアップツールとして本当に役立ちそう。

▲ イメージを選んで、Launchボタンで簡単インスタンス起動 ▲
DNS adressing typeという設定は何？いくら探しても説明が見つからない

▲ インスタンス起動後のコンソール画面 ▲
ボタン一つでイメージ作成可能、時間はむちゃかかるけど非同期でやってくれるのでほったらかしでおｋ

▲ 一番上がRightScaleから作ったイメージ ▲
イメージ作成日時とかも記録に残って判り易し

欲を言えば、EC2サーバを立ち上げてサービスを作ろうと思えば、あてがわれたIPアドレスに対しドメイン名を割り当ててやらないといけないわけだけど、DynamicDNSとかと連携させての自動DNS書き換えとかの機能もついてくれると嬉しかったかな。
今はEC2サーバの起動時スクリプトでDynamicDNSのI/F叩いて自動切換えさせているのだけど。

とまあ、UIとしても上記のように非常にいい感じなのですが、既にEC2アカウントを持っている私には関係ないですけどEC2アカウントを持ってない人でも、RightScale自身が持っているアカウントでEC2サーバを起動し利用できるみたいなので、これも中々いい機能（しかも初回10時間は無料！その分課金開始後はAmazon直接契約より上乗せされますが）。
ちょうど今はEC2がアカウント増で入会者を一時制限しているので（私も実はマッシュアップアワードをEC2でやろうとして、ロカポ用の別アカウントを申請していたのだけど、1ヶ月も待たされてアワード締め切り後のつい先日アカウント開通したような状況）、すぐEC2がどんなものか使ってみたい人にはよいサービスかも。

...でも、これって、アカウント増による負荷軽減のためにEC2の入会者絞ってるんだと思うんだけど、RightScale経由で大量流入したりしたら意味なくないか？

ゆうきまさみさんのブログ経由で知りました。

アイヌの遺産「金成マツノート」の翻訳打ち切りへ -asahi.com-

アイヌ民族の英雄叙事詩・ユーカラが大量に書き残され、貴重な遺産とされる「金成（かんなり）マツノート」の翻訳が打ち切りの危機にある。言語学者の故・金田一京助氏と５月に亡くなった萱野茂氏が約４０年間に３３話を訳した。さらに４９話が残っているが、事業を続けてきた北海道は「一定の成果が出た」として、文化庁などに０７年度で終了する意思を伝えている。
　　.........
これまでのペースでは、全訳するのに５０年程度かかりかねない。文化庁は、「一つの事業がこれだけ続いてきたことは異例」であり、特定の地域だけ特別扱いはできないという。これをうけ、北海道は３０年目を迎える０７年度で終了する方針を関係団体に伝えた。

この国はダメかもわからんね -ゆうきまさみのスケッチブック-

そこに特別なものがあるなら、特別扱いすればいいじゃないかと思うのだが、それにしても、こういう事業に年間1500万円しか予算でてないとはビックリだ。

金成マツノート問題 -塾講師のつぶやき-

まず「年に数百万」というのがそもそも小さすぎる規模だ。これでは翻訳事業が長くかかるのは仕方がない。そこで、だ。翻訳を済ませるだけであれば、ＣＯＥだ。どこかの大学が金成マツノートの翻訳を核にしたアイヌ文化研究の総合研究プロジェクトを立ち上げる。そしてＣＯＥを申請する。数百万どころか数千万円の規模で金がおりる。翻訳事業に専念する人員を十数人は当てることができる。

その後はその大学で金成マツ研究所か何かを設立し、アイヌ文化の総合研究を行う。これしかないだろう。

--- コメント欄 ---

年数百万円を28年間と書くと、とても大きな事業をしていたような印象を受けるのですが、たった一人分の人件費程度なんですよ。

テコ入れしなければ失われる民族的文化遺産に対して、年間1人の人件費程度ですか。
すごいですね...例えばアメリカや中国なんかで、日本文化を理解するための研究事業に1人しか割り当ててなかったとしたら、まさに文化庁の人達は（別に文句は言えないですが）屈辱に感じると思うんですが、同じことを自国民である民族に対して行うと。
なんかマジで「スクラップ＆スクラップ！」しかないのかなあという気もしてきてしまいますね。
こういう感覚がまかり通るので、保守がかった人達が言う「在日韓国人はダメ、韓国系日本人ならOK」みたいな論理は胡散臭さ爆発になっちゃうんですけどね。
まあそう書きつつ私も別次元から「在日は国籍取得すべき」派なんだけど...。

解決法として、Web2.0時代のネットの住人で、かつ「自称」技術者の立場から見てみると、

アイヌの遺産「金成マツノート」の翻訳打ち切りへ : casual fragments - 徒然的断片 -

そういうわけで、私ならば、金成マツノートを管理している方に許可を得て、その全文を、Web上で公開することを提案する。そうすれば、アイヌ語を今から習得してでも、何年何十年かかろうと翻訳してやるというものが現れるだろう。少なくともこのニュースをブログで扱う人は少なくないのだから、原文に自由にアクセスできさえするのなら、翻訳してみようとする者も出てくるだろう。金を出さないなら、テクストの囲い込みを止めろと。

「お前らがやらないなら俺がやる」――結局はここに行き着くのではないだろうか。

これに共感しました。
まさにCGM時代の解決策ですね。
Wikipedia的に、大勢の叡智と小さな余暇を集めつつ、進めるというのもいいかもしれません。
うちの家内も「多少」アイヌ語読めるので、協力できるかもしれないし（いや、彼女は100%やらんだろうが）。
（そもそもまだテキスト化されていないという可能性もあるけど。ローマ字化されているとはいえ、発音補助記号とかUnicodeで表記可能なのかも判らないし。）

もう一つ思ったのは、技術屋だからこう考えちゃうんですけど、この事業、Googleとかでできないでしょうか。
Googleの機械翻訳エンジンは、言語間の文法変換エンジンをひとつひとつ用意するのではなく、いろいろな言語間の翻訳事例を食べさせて、それで機械的に適切な訳の候補をリコメンドさせるロジックなのだそうだ。
ということは、原理的には日本語とアイヌ語の間でも可能なはず。
自動翻訳できるようにするのにどの程度のテキスト量が必要なのかは知らないし、またユーカラの1話の長さもよく判らないので、33話分で十分なのかは不明です。
が、別に金成マツノートだけが日本語/アイヌ語対照テキストではないだろうし、また別に最初から全部機械でできるとは思っていない、飽くまで人手で最後はやりつつもその補助として活用する、という位置付けなので、別にある程度の結果が出るだけのテキスト量があれば十分ではないかと思います。
それこそ、上で提案されているCGM・Wikipedia的な翻訳ムーブメントの手助けになる程度の性能があれば十分だと思います。
まともな結果が出るかどうかはやってみないと判らないけど、それを試すためにGoogleのDBへ対照テキストを流し込むことはGoogleの中の人にしかできないことなので、協力できないだろうかなあ。
Googleとしても、推進している純粋技術的アプローチが、Web2.0といった先端の分野だけでなく、アカデミックな文化事業にも貢献できる事をアピールできる機会かなと思ったり。
というか、元々Googleは、人類の「智」を再構築しようとしているはずなのだから、うってつけのテーマではないのだろうかと。

んで、Googleを話題に出したんで思ったんだけど、Google対抗とか言って国主導で高い金つぎ込んで誰が使うかも判らない国産検索エンジン作るくらいなら、ちゃんと自国の文化研究に投資しろよと。
Google独占は確かに問題だけど、でも別に他にプレーヤーはYahooもMSNも百度もいるわけなのだから、そんなところに金つける必要ないだろうと。
それくらいなら、今やらないと失われる自国文化にテコ入れしろよと。
それでも金出さないと言うのなら、せめてテキスト公開やGoogleからのオファーがあったりした時は、拒絶せず公開して欲しい。

国が巨額を投じてGoogle対抗！とかいって検索エンジン開発している裏で、国が見捨てた民族の文化事業にGoogleが手を差し伸べる、みたいな構図ができたりしたら面白いなあ。
どっちが政府としての資格があるよ？見たいな感じで、Googleの世界政府化構想に一歩近づくかも。

火曜日に、私の転職祝いと称して、しばらく会ってなかった昔からの位置情報仲間と飲んできました。
WebGIS会社の役員をされていたYさん（今は転職してGIS業界からは離れられた）と、そのWebGIS会社と協業してWeb位置情報サービスをされている会社のオーナーのKさんで、ちょうど私が東京に出てくるか来ないかくらいの時に、当時はまだギリギリ動いていた（ただしもう更新は止まっていた）「ここのサーチ」をネタに「あれに続くような、位置情報のGoogleみたいなことをやりたいよね」とか盛り上がったり、Kさんとは一緒に神戸の某研究機関に位置情報サービスの売り込みに行った事もあったり、といった付き合いをさせてもらっていた人達です。
いろいろ懐かしい話題でも盛り上がりました。

その時の話題で面白かったのが、ローカルネタ。
私は関西の姫路出身、Kさんは名古屋、Yさんは秋田出身の方なのですが、Yさんの「関西の方ではいかなごの釘煮という食べ物があるんですよね？」という話題から始まって、ローカルネタに花が咲きました。
いや私、「いかなごの釘煮」が関西、それも摂津・播州・淡路あたりローカルの食べ物と言うのは知っていましたが、「いかなご」という魚そのものが関西以外では知られていないというのは知りませんでした。
標準語？だと思ってた。
実家では、カレーを作るような寸胴鍋で、いかなごを煮て大量に作りますよ、と言ったら驚いていました。
というか、今Wikipediaを見たら、いかなごってちりめんじゃこの正体だったのか。それは知らなかった。

次いでKさんがういろうが好物だと言う話から、ういろうって何でできているの？という話題に。
あれって米粉でできているんですね...羊羹みたいだけど食感が違うから、何でできているんだろうとは不思議だったけど。
今は全くテレビCMやられてませんが、昔は東日本では「青柳ういろう」のCMがやられていて、かなりメジャーだったみたいですね。
Yさんも子供の頃からよく知っていた、と言われていました。
私もCMは見たことありませんが、「青柳ういろう」という商品があるのは高校生くらいから知っていました...確か、「究極超人あーる」の中でネタに使われてた気がするので。

秋田の話題は「えご」。
蒟蒻みたいなんだけどちょっと食感が違う、海草（えご草）から作られるものらしい。
Yさんが東京に来て、ないなーと思ってたら、福岡の方へ行った時に見つけた「おきゅうと」という食べ物が、「えご」と全く同じ食べ物だったことが判明したとのこと。
北前船ででも広まったんですかねえ、みたいな話をしていたんだけど、やっぱりそうらしい。
というか、遠隔地で同じ食文化や習慣があったり、全く産地とはかけはなれた所で食べる習慣があるとかは、大体「廻船」の影響ジャマイカ？と言っておけば間違いないんだよな。

他にも秋田あたりの山中では、いや秋田に限らず山中では同じかもしれないけど、山を隔てて食文化が断絶するので、山のこちらでは高価に取引される食材が、山の向こうでは犬も食わない、といったこともあるらしい。
特に「毒キノコ」があるため食べ始めるのに躊躇があるキノコ類が顕著で、Yさんもそのような一部地方でしか食べていないおいしいキノコを知っているそうなのだけど、そこでしか食べないから標準語で当てはまる言葉がなく、どういうキノコなのか説明できないとのこと。
うーん、こちらでは売れないものを高く売れるあちらへ持っていく、というのが商売の基本なわけですけど、そういうのがデータベース化されれば商売のネタになるだろうか？とか思った。
CGM？いやみんなで作り上げればみんなに広く知られてしまうわけなので、商売のネタとしては意味ないですね。

そんな感じで、中々面白い話題で盛り上がりました。

仕事の話も少ししたんですけど、今私が関わっているプロジェクトで、協力会社側で担当してもらっている人達が、Yさんともよく見知った人達だと判明してびっくりしたりもしました。
上司とその下の担当の方の二人組みなんですけど、上司は上司で業界での顔も広く、いろいろなプロジェクトを成功させてきた優秀な方で、担当の方は担当の方で計画能力の高い優秀な方なんですけど、でもとにかく上司の人が客前とか関係なく担当の人をよく叱る人で、それも別に理の通った事ならいいんですが「それはちょっと言いがかりっぽくムリクリすぎない？」と思うようなことでもいちいち口を挟む人で。
「あれじゃ担当の人潰れちゃいますよねえ」「いや、実際何人か潰れてます」みたいな話もしました。
偶然、次の日がその協力会社との打ち合わせだったので、Yさんをご存知ですか？と言ったら驚いた顔をされていました。
さすがに前日したような話はできませんでしたが。

といっても別に社会に実害はない？かもしれないのだけれども、あまりに酷すぎる。

ニッポン人が好きな偉人100人・英雄編という番組をやっていたので、晩飯食うついでに見ていたのだけど、ベスト6か7くらいにチンギスハーンが出てきた。

で曰く、モンゴル帝国が大きく長く栄えたのは、異民族の宗教を弾圧しなかった寛容性があったからだと。
それは全くその通りだろうと思うのだが、それを引き立たせるために「同じような帝国でもアレキサンダー大王やローマ帝国のアウグストゥスは、土着の宗教を弾圧し自分達の宗教を押し付けたが」みたいなことを抜かしていた。

おいおい、どこをどう見ればアレキサンダーやローマ帝国が宗教に非寛容というような話が出てくるんだ？
アレキサンダーは、ゾロアスター教は宿敵アケメネス朝の国教でもあったので徹底破壊したりもしたが、それはむしろレアケースで、一般的に征服地の宗教には寛容だったし、ローマが時の皇帝の資質次第でキリスト教迫害などはあったにせよ、共和政時代から他民族の習慣や宗教に寛容であったのはよく知られた話。

というか、他にもペルシア帝国にせよイスラム帝国にせよ、歴史上、長く統治される大帝国となるための必要条件は他民族や他宗教への寛容、と言っていいくらい、栄えた大帝国はみんな寛容さを兼ね備えている。
いかにモンゴル帝国を持ち上げるためとは言え、なんで嘘八百でアレキサンダーやローマ帝国を中傷するかなあ、と思った。

ロカポイントも変わらなきゃ？

で初出させてもらいましたロカポイントの新仕様案ですが、考えてみればエリアコードだけでなくローカルコードも空きが出てくるので、良番を売ると言うような収益モデルもありですね。
というか、ローカルサーチを語る会でロカポを紹介した際に、ついでに私の新仕様案も紹介したのですが、そっちに私の考えていることをまとめたので、そっちから画像引っ張ります。
（前半のロカポ先般の説明は、上田さんの著作物ですし散々説明されてきているので省略）

みたいな感じで、空きコード空間を売る収益モデルとかローカルサーチを語る会では「おーっ」等と歓声も上がった感じで受けてたんだけど、意外とロカポ提唱者の上田さんはお気に召さないよう。

• この案を受けての上田さんの意見
• 上田さんの意見を受けての、私のコメント

みたいな議論をしているんですが、コメントで書き足らなかったことを追加でここに書いておきます。

まず、私の案のうち、最上位を24文字で割るのは時差を意識させるのでいいかもと書かれているのですが、これが判らない。
私が24で割るのを提案したのは、時差計算等で15度単位で扱うのに社会が慣れているからで、直接時差とリンケージさせるつもりはありませんでした。
というか、時差を意識させると言うのならば、最上位桁を時間帯と一致させるべきであり、隣り合う最上位文字を持つエリアコードの、半分までは同じ時差だけど、半分より向こうは1時間ずれる、なんてのだと一般人は余計混乱する。
私も15度単位で分けることを思いついた時点で、エリアコード最上位を時間帯に一致させることは考えたのだけど、それを採用すると西経180度から東経180度までを均等に割る、というロカポの根幹の考え方が崩れるので、それはさすがに見送った。
全般的に扱いやすくするために、全桁割る基数を見直す、というのならば判るが、時間帯と完全一致させるならともかく時差を中途半端に意識をさせるためだけに最上位のみA-Zを崩すのならば、それは導入すべきではないと思う。

また、ZZ9の次がAA0にならないと判りにくいから、一般人にやさしくないからというアタリにやたらとこだわっておられるのだけれど、一般人へのやさしさを最優先しているコード体系であるのならそれも判るんだけど、そもそもがロカポは一般人へのやさしさを最優先に考えたコードではない以上、必要以上にそこにこだわることはむしろロカポの持ち味を壊すと思う。
コード体系の、一般人へのやさしさとは何かというと、やはりよく使われるユースケースでより簡単である、ということであり、その意味でもっとも一般人にやさしい位置情報コード体系は、デンソーのマップコードだろう。
ロカポよりはるかに少ない、数字だけの6桁-10桁で日本中を表す事ができるし、拡張コードを用いれば桁数は増えるが世界も表す事ができる。
海上は表せないからダイビングポイントの位置や海上遭難時の位置等は表せないじゃないか、と言われるかもしれないが、そもそもダイビングの位置や海上遭難の位置を伝える、等というのが、一般人にとってどれほどのレアケースなのかを考えればいいだろう。
そんな超々レアケースが表せる利益と引き換えに、生活圏内の位置表記を数字6-10桁から英数字12桁に換える不利益を、生活感を持った一般人が受け入れるはずがない。
コードのエンコード/デコードロジックが公開されていないというのも、一般人ユーザは自分でエンコード/デコードアプリを組むわけではなく、デバイスが変換してくれればさえそれで済む話なのだから、一般人の目から見たら何のデメリットでも何でもないのだ。
そもそも一般人へのやさしさだけを視野に入れていたら、マップコードに勝てるはずがないのだ。

となれば、ロカポの持ち味である、海上も含め全世界をくまなく一律に、 均等に扱うことができ、またエンコード/デコードロジックが公開されている、という点に魅力を感じ、普及の後押しをしてくれる可能性があるとすれば、それは一般人ではなく、海上も含めグローバルに位置のことを考えたシステムを構築する必要がある位置情報屋や地図屋、或いは行政・自治体等、ということなのだから、そういった方面への訴求力をこそ一番に考える必要があると思う。
だからこそ、ZZ9の次がAA0という外観の美しさはあっても、データ内容としては割り切れない数値で既存データとの互換性が低く、表している中身が美しくないコード体系より、XY9の次がAA0と見た目は若干汚くなっても、割り切れる値で既存データとの互換性が高いという美しさを持つ体系の方が、受け入れられ易いと思うのです。

それに、新仕様案は、[A-Z][A-Z][0-9]と比べれば確かに美しくはないのだけど、だからといって例えば[A-V][A-G][0-9]というような無茶苦茶なコード体系でもないのです。
[A-X][A-Y][0-9]と言う形で、「X（英字の終わりから3番目）Y（英字の終わりから2番目）9（数字の一番終わり）」というそれなりに美しい形で終わっているのです。
この程度のコード体系乱れならば、それによって得られる利点が大きければ、受け入れてもいいんじゃないかと思うんですけども。

以上、上田さんに限らず皆さんからの意見お待ちしています。

別に取り上げるまでもなく当たり前のことです。
というか相互乗り入れ契約していないところで課金引き落としされたりなんかしたら逆にエライことです。
ちなみに現在の相互乗り入れ状況はこちら。

頭では判っているのですが、ICOCAとSuica、ICOCAとPiTaPaは相互運用可能なわけなので、なんか使える？使える？と好奇心が沸いて、週末後輩の結婚式に新大阪行った際に使ってみました。
結果はやっぱり、「このカードは使えません」とのこと。
当たり前ですね。

でもそれだけなら、別にdoodleでラクガキしてそれでしゅーりょー、程度の話なのですが、同じことした人が結構いる？みたいで。
今朝、通勤で最寄り駅に向かっている途中にすれ違った、上司と部下風のサラリーマン2人組がいたのですが、部下っぽいのが上司っぽいのに「Suica、PiTaPaで使ってみたんですけどやっぱり駄目でしたね」みたいな会話をしておりました。

アホな事試す奴も結構いるもんなのだなあと。

既に森さんがレポートされていますが、日本のローカルサーチの草分けとも言えるモーバイルインフォサーチ実験/ここのサーチの主要メンバーである高橋克巳さんの、博士課程取得記念のプライベートイベント「未来の地図 ローカルサーチを語る会」に参加してきました。
森さん、高橋さんのプロフィール紹介にうちの拙い過去記事索くのはかんべんしてください...森さんの記事からうちにrefererが来てたのに、どこにもリンクなんかないぞ？なんで？と思ったら、「高橋さん」の名前のリンクがうちの記事になってるじゃないですか...。

イベントの内容は、第一部が高橋さんが入社されてから、ジオコーディングや位置データマイニングといった分野に取り組んできた歴史、モーバイルインフォサーチ実験を経て博士号を取られるまでの、20年の足跡の振り返り。

▲ 20年近く前のオンライン電話番号検索装置の実物 ▲
（完動品、しかもデバイス的に動くだけでなく、サービス的にも繋げばまだ動くらしい（私の聞き違いでなければ）。美香加テラスゴス。）

▲ 10年以上前に店舗の評判数でスポットに濃淡をつける口コミマップっすよ。 ▲
そのままCGMっすよ。それは時代を先取りしすぎているだろうと。

しかしモーバイルインフォサーチ実験＆ここのサーチって、WWWをクロールしての住所データ入りWebページ収集→ジオコーディングして経緯度つけて蓄積→位置をベースにWebページ検索って、正直これを超えるものっていまだに出てないんですよね。
Googleですら、飽くまでPOI（Point Of Interest、つまりスポット情報みたいなもの）としてはNTTかどこかから買ってきた電話帳データかなんかを元にしているだけで、WWWクロールはしているけど元々POIとして持っているデータに紐付けられるものをピックアップするのみで、住所だけを頼りにジオコーディングして新たなPOIとして登録する、ということはしていない。
正確には、WWWクロール→Webページ内住所ピックアップ、ジオコーディングで経緯度つけて蓄積→経緯度で検索、というのは、中国か四国地方アタリのどっかのベンチャーがやっていたはず（サービス名ややっている会社名ド忘れした）だが、それにしたってここのサーチでやっていたのと同じようなレベルではあっても超えている事はないし、Google MapsもPostGISのような空間DBもなかった10年近く前にあれだけの実験をやったのはやっぱりすごい。

高橋さんの振り返りの後は、第2部として、ゆかりの人々のプレゼンの時間へ。
私は飛び込みだったのですが、トップバッターとして、別に高橋さんとは繋がりのない話題だったのですけどもロカポイントの宣伝とマッシュアップアワードの報告をさせてもらいました。

その次は高橋さんのモーバイルインフォ実験当時の同僚の方による、当時の振り返り。
この方のプレゼンで一つ気付かされたのは、これは今回聞くまで全然意識してなかったんですけど、モーバイルインフォサーチ実験って、調べようとしている経緯度が判ると、そこからMapionやMapFanのような地図サイトに経緯度付きでリンクしたり、位置情報付きでプロアトラスを起動したり、天気予報に誘導したり乗り換えに誘導したり、位置情報をベースに保持したままいろんなサービスにユーザを誘導するクロスロード、みたいなことを行った最初のサイトだったんですね。
私も近々、携帯サイトで、位置情報をベースにいろんなサービスへユーザを誘導するメタサービス的なものを作ろうと思ってたり、また直前の記事で紹介したdoodleなんかもいろんな他サービスへの位置情報保持したままでの誘導なんかを普通に行っているわけですが、そういうものの走りはモーバイルインフォサーチ実験だったわけです。
というか、マッシュアップというと今はどうしてもWebAPIとかで外からデータ取ってきて自サイト内で組み合わせることを考えてしまいますが、ユーザにあまり意識させずサービス間で透過的に機能を連携させることも広義のマッシュアップとして含めて考えれば、モーバイルインフォサーチ実験はマッシュアップの走りであったと見ることもできますね。

続いてこれも飛び込みだったらしいのですが、オークニー森さんによる、位置情報業界やはり20年くらい？の振り返り。
その後が東大空間情報科学研究センター（CSIS）の相良先生による、ジオコーディングを中心とした研究の振り返り。
多摩市貝取1（丁目）と多摩市貝取1（番地）はどうやって見分ければいいんだYO！とか、龍ヶ崎？竜ヶ崎？龍ケ崎？（いろんな自治体や施設の「正式」となっているような名称として、いずれの表記も存在するらしい）の問題とか、富山県の方で市町村合併が起きて同じ町名が市内に存在するようになったにも関わらず、日常では郵便番号があるため誰も困らず気付かず、CSISのジオコーディング実験でエラー発生がバーストしたので調べてみたらその事が発覚して、市役所に問い合わせたら「全然気付きませんでした」と言われたような話とか...いろいろジオコーディングにまつわる面白い苦労を聞かせていただきました。
そのジオコーディング実験ですが、住所の変更とかには月1回のメンテで確実に対応していて、他にも異体字のテーブルなんかはユーザから報告があるたびに対応するようにしているので、Googleのジオコーダなんかが全然追いつけていない精度でジオコーディングできる、日本でももっとも優秀なレベルのジオコーディングサービスになっているようです。
すみません、その辺のメンテの苦労とか全然知らなかったので、今までやっぱり商用の方がいいのかなあとか勝手に思い込んでて、GoogleやYahooのWebAPIばかり使ってました...今後はCSISのジオコーダ使うようにします...。
あと、ジオコーディング実験はすごい人気で使われている遭難ですが、同じく相良先生がやられている「レストランのウワササーチ」は、あまり利用されていないということ。
こっちも皆さんよろしければ使ってください。

最後に、高橋さんの元同僚で技術系ではなく文系の方のプレゼンだったのですが、電話帳というのはインターネットがなかった時代の検索エンジンだ、という話が中々おもしろかったです。
今検索エンジンでいろいろ言われているSEOだのSEMだのっていうのは、電話帳の世界では昔からやられてきた事で、歯医者の名前として「A歯科」なんてのが割とあったり、寺田運送が引越し業に進出した際に「アート引越センター」なんて名前をつけたりしたのも、ABCやアイウエオ順で並ぶ電話帳で上位に載るためのSEO対策だし、金を出して大きな広告枠を出すのはSEMと同じ。
中には、競争の激しい鍵の業界で、「鍵」カテゴリの中でライバルの頭を取るのはすごく困難なことなので、「鍵」の前に並ぶ「鏡」のカテゴリの最後尾を鍵業者が安く買って、結果「鍵」カテゴリの最前列より前に載る、というようなウルトラCのSEOテクニックもあったりするようです。
そんなSEOやSEMのノウハウを永年蓄積してきていて、目先のテクニックは違っても考え方の基本は昔から豊富にあるのだ、と言われていたのが印象的でした。

発表をされていない方でも、すごい方々といろいろお会いすることができ、またあまり書けないような話題を含めいろいろ情報・意見交換することもできて、非常に楽しい時間を過ごせました。
高橋さん、楽しい場にお誘いいただきまして、ありがとうございました＆博士号取得、おめでとうございます！

Mash up Award後の懇親会では、いろいろな方とお会いする事ができました。
Award開催側として来られていた旧知のPlaceEngine、たたみラボの方々ともいろいろ新しい意見交換もできましたし、NTTデータ賞を「子育てMAP」で受賞され、今後のマッシュアップはガジェット中心になるかも？の話題でブログ上では何度か絡ませていただいた「convivial-weblog」の主宰の方が、実はOSGeo系でお会いし名刺交換したこともある人だった、というのも中々驚きでした。

そんな中、優秀賞を受賞した株式会社ゴーガの皆さんともお会いでき意見交換できたのですが、「お前、doodleをここギコで取り上げないとどうなるか判ってんだろうな」と脅され彼らの作品である「doodle」がとても面白いので、紹介します。

doodleというのは、英語でラクガキのこと。
決して、某G社のパクリではない（らしい）です。
その名のとおり、街角にラクガキのように、自分のメッセージを残す事ができます。

携帯から上記QRコードでアクセスすると、GPSでの位置取得画面になります（GPS非対応端末ではどうなるのか確かめてないので判りません...ジオコーダでの住所検索とかの口もあった方がいいような気も）。
すると、「近くのdoodleを探す」というメニューがあり、それをクリックすると、近くで過去に誰かが残したメッセージと、その場所への方向・距離等を見る事ができます。
それに対してレスをつけることで、その場所に紐付いたバーチャルな掲示板のスレッドのように使うことができます。
当然、他人の作ったスレッドを見るだけではなく、自分で>>1になることもできます...GPS取得後の画面で近くのdoodleを探す代わりに、その下のテキストボックスにメッセージを入れて「doodle!!」ボタンを押すと、自分がスレッドの1になって、「糞スレ立てんな！」と言ってもらえる栄誉を得ることができます。

なんでもないところにメッセージを置いて誰かが食いついてくれるのを待つのもいいですが、カンファレンスとかたくさんの人で場を共有しているところで、doodleを通じて場の感想とかを共有するのも、中々ライブ感があって楽しいです。
実際、Mush up Awardの授賞式の場で、このサービスを知ったのでさっそくアクセスしてみたら、ゴーガの方々がその場にスレ立てしていたので、「おめでとう」メッセージをその場で書きこめたりとかできて、中々おもしろかったです。
そんなことは別に、今までだって会場で無線LANとかあってIRCとかあればできたわけですが、そんなヘビーなデバイス使わなくても携帯一つで誰でも手軽に、かつその場限りでなく記録に残せる形で「その場所」コミュニケーションができるというのは面白いと思います。
そうそう、PCからも見られるインタフェースがあるので、その時の記録です。

doodle自体のメイン機能は上記のような感じなんだけど、掲示板を見たい/書きたいと思ってない時でもdoodleにアクセスさせるインセンティブとして、外部のAPIを叩いての周辺情報の検索機能が充実しています。
食堂検索なんかでは、Hotpepperだけでなく食べログからも情報を探して検索できる他、それぞれの店舗に「doodle!!」することもできるので、お店の口コミ情報等も残せる/見られるようにもなっています。
（上の機能をPC版で見た場合がこちら）
天気予報は普通に予報データを取ってくるのではなくて、直近の雨のレーダー情報を画像で出してたり、書名を入れて近くの図書館を検索できたり、他にもいろいろ変わったところから情報を取っているのも面白いです。

ちょっとすごいなと思ったのは、乗り換え案内。
doodleの機能というよりはリダイレクトしている先のGoogleの機能なんですが、出発地点・到着地点として経緯度を与えてやると、そこから最寄駅までの徒歩時間も計算した上で、乗り換え経路を探索してくれるみたいです。
残念ながら時間を検索してくれるだけで、経路図等は出ないようなのですが、それにしてもGoogleの乗り換えにそんな機能があるとは知りませんでした。

若い連中？が、街角にいろいろラクガキして街を汚すようなことは困った事ですが、そんなことで自己顕示する代わりに、若者の間ではPCより当たり前のネット接続手段となっているらしい携帯を使って、doodleに色々書き込んだりするような文化が出てくれれば、面白いですね。

すみません、まさにこれに参加した後疲れがたまって抜けなくなってしまい、ブログの更新とか遅れてるので今さらの報告になるのですが...。

既に上田さんがロカポブログで報告されているとおり、「位置情報ロカポ」チームでMash up Award 2ndに参加していたのですが、なんと入賞し、ホットペッパー賞をいただいてしまいました。

『禁煙レストラン』http://non-smoke.info
『ケータイ版禁煙レストラン』http://non-smoke.info/m/

 “Mash up Award 2nd” 審査結果発表！

参加しようよ！と言い始めたのが募集期間後半も大分過ぎてからだったので、開発期間は2週間あるかないか、実質正味週末だけの4日程度。
さらに東京と奈良という遠隔地での協業という事で、一緒に何か1つのもの作るのは無理だよなあ、ということで、JavaScriptは上田さんが得意で私は苦手なのでPC版は上田さん、携帯のノウハウは私が持っていて上田さんはよく知らないので携帯版は私、というふうに完全分業で行いました。
とは言え、携帯ノウハウあるといっても実際に作るのは2年ぶりくらい、うろ覚えなので何度も試行錯誤したり、当時はほとんどなかった3G機種でのノウハウとかは仕様差からの想像で補ったり、いろいろ大変でした。
最初の週末はほとんど実装そのものより機種毎の挙動情報収集で潰したような覚えが...。
禁煙情報の入力なんかも、本当は携帯から「その場で」できた方がいいのは判っているので当然やるつもりだったのですが、入力機能そのものよりもログイン状態のセッション管理実装（キャリア毎のユーザID有無、クッキー対応有無、ユーザのユーザID通知機能ON/OFF毎に、URL利用・ユーザID利用・クッキー利用を分けなきゃいけない）の方が大変で、最後の週末で手元にテスト機もない状況で実装するのは危険だったため見送りました。
いずれはその辺のノウハウも思い出さないと近々自分でやりたいことにも必要なので、携帯からのログイン/情報入力を実現したいのですが、ちょっとしばらく休ませて...。

何とか短時間でマルチキャリア対応の携帯サイトを作れたのは、携帯サイト構築から離れていても何となく自家製の携帯電話向けPerlモジュール群を思い出したように時々メンテしてきてたお陰なのですが、とはいえそれだけでは形にはできなかったわけで、いろいろな形でいろんな人に助けていただいたと思っています。
Web2.0ワークショップにお誘いいただき、携帯電話ノウハウを思い出すきっかけを下さった法林さん、Web2.0ワークショップ資料の思い違い・間違いをツッコミ入れて修正してくださったCeekzさん、Google Mapsの携帯からの画像インタフェースの存在を教えてくれたroseseさん、そのインタフェースをいろいろいじってノウハウを導き出してくれたwakasa.orgさん、ZeroMemoryさん、masa先輩、管理せずほったらかしだったiエリア変換モジュールをメンテしてくださったアイデアマンズ株式会社さん、皆さんのおかげで完成できたと感謝しております。
それから当然、この作品のコンセプトを提唱し、一緒に作り上げてきた上田さん、でもって週末PCに向かいきりで遊んだり遊びに連れて行ったりもしてやらなかったのに我慢していた息子とその息子の相手をしてくれていた家内に、感謝したいと思います。
賞金入ったら、どっか連れてってやるからな。

※とか言いつつ、Awardがなくても週末はこうしてブログ書いてたりして、結局ほとんど子供の相手はしてないんですけどね...ダメ父親ですな。

ちょっと前の話題ですが。

世界の携帯電話大手、バーコード読み取りで共通規格検討【ＦＴ】

おお、世界共通の規格で、どこのデバイスでも同じように読み取れるようになれば、位置情報付き2次元コード基盤実現の野望にも一歩近づきますな。

自分の国にそんな規格がなくても、日本とかいう辺境の島国に携帯デバイスで読み取れるバーコード規格があると聞いただけで、「それって位置情報つければイイジャン！」等と思いつく突拍子もない人もいたりするので、世界中でそんな環境が広まればきっとみんな同じこと考えるんじゃないかと思います。

Whitelisting -Identity 2.0 Europe-

OpenIDやFOAFを利用したWhitelistingが話題に登っているみたい。
今はまだCommentやTrackbackのSPAMをどう根絶させるかといったところが主眼のようですが、結局のところCommentやTrackbackの許可/不許可も、突き詰めればコンテンツへの追記という改変を認めるかどうかのAuthenticationをどうするかという話なわけなので、そこからコンテンツの閲覧をもAuthenticationする、といった方向へはすぐ来るのではないか。
さすがにページ毎に、この記事は誰でも閲覧可、この記事は友人のみ、とかそこまで自由自在に制御できるような方向へはすぐには来ないだろうが、サイト一律での閲覧管理をFOAFやWhitelistingで、とかならすぐ来るのではないか。

未踏への応募で落ちて以来、わざわざ別サイトまで作ったのに何もやっていませんが、なんとか望む方向に向かっているみたいですし、日本でもOpenID.ne.jpさんのような積極的なプレーヤーも出てきたようですし、私は位置情報系の方に注力して、こっち方面は口先だけに終わらせていただこうかなとか思ってます。

とか書いている間に今度はデスクトップクライアントでOpenIDを使う案とか出てきた。
いろいろ面白く動いてるなあ。

一つ前のエントリでロカポイントの精度を落して親しみ易くする！みたいなこと書いておきながら、ロカポイントが40cm精度であることを前提にしての話なんだけど。

ロカポイントで表せる40cm程度の精度って、よく考えると多分管理されるべき地物の最小の大きさくらいじゃないかなと思うのね。
例えば、路上の視覚障害者用点字ブロック。
あれの四辺がだいたい40cm角かそこらだろう。

あれ、現状いちいちIDつけて管理されているのかどうか判らないけど、少なくとも将来、点字ブロックにICタグ入れて視覚障害者を誘導する歩行者ITSなんかが検討されていたりするけど、そういう状況になれば全部IDつけての管理対象になることは間違いない。

そんな時、位置をつけて管理しなければいけない地物のIDとして、通し番号とかでの管理だと、IDを見ただけではどこを処理しなければいけないのか判らず、いちいち位置情報属性を紐付けてこなければならないので面倒だ。
○○区××町とか、簡単なエリア区分をIDに付加することも考えられるけど、それにしたってIDがそれだけで一意に場所を特定するわけではない。
でも、ロカポを使えば、最大精度の40cm角を下回らない地物ならば、絶対重複しない形で一意に場所に紐付けられたIDを付与する事ができる。
これ、実は意外と便利では？と思った。

単に位置に紐付けたIDが自動生成できるだけでなく、メンテナンスを頼む際なんかでも、ID→位置の変換テーブルを用意せずに計算だけで場所を特定できるので、特別なシステム等作らなくても簡単に出先の業者にメンテナンス発注出来たりとか、そういう利点もあるのではないか。

もちろん問題もあって、ロカポは現在高さ方向は考慮されていないので、多層に重なる現在の都市空間ではロカポだけでは不十分だけど、別に高さ用の追加領域を作ってやればいいだけの話。
たった12桁だけで世界全体が40cm精度にまで落としこめるのだから、高さ方向の精度だってあと数桁加えれば高層から地下まで十分表現できるコードが成立するだろう。
そういう高度方向への拡張については、各適用例が独自に対応してもよいし、ニーズがありそうならばロカポ側で共通仕様を作るというのもアリだと思うが、いずれにせよ位置情報を持つ地物の管理番号として、ロカポを使うのはアリなんじゃないかと思った。

覚えやすいどうこうのレベルに達してない希ガス

だから覚える必要はないんだってば...という一方で、そういわれた時に示せる定量的な反論材料がないのも事実。
なんか簡単な実験やって定量データとった方がいいかもしれないな。

例えば、ロカポの現状の仕様だと最大精度で40cmくらいが表せるわけだけど、同じ精度を日本近くだと経度方向1秒あたりほぼ40mくらいのはずだから、度分秒形式なら0.01秒くらいの位まで伝達すれば同じ精度を伝えられる事になる。
度でいうならば0.000003度くらいの桁になるけど、世界中の無作為な場所を100箇所とか選んで、ロカポと度単位での経緯度、及び度分秒の経緯度の3形式で電話を通して伝達した時に、どの形式で伝えるのが一番誤りなく、かつ速く伝えられるか、というのを求めてみたらいいかもしれない。

また、ロカポ自体も、より判り易くなるためにまだ工夫の余地もあるかもしれない。
仕様を変えるなら、まだそこまで普及していない今のうちだけと思うので、より判り易くするための仕様変更もありなのではないかと思う。

例えば。（飽くまで以下は、本エントリで私が出した仮の提案であって、本仕様の変更ではありません）

ロカポは飽くまで換算のし易さより精度向上を目標として、AA0.AA0.AA0.AA0　-　ZZ9.ZZ9.ZZ9.ZZ9の領域をフルに使ってるんだけど、これだとまず誰であろうと「暗算できない」という、親しみを持ってもらうには致命的かもしれない難点がある。
もちろんどんな仕様にしようと、地球全体から最大精度を出す桁まで全部暗算で可能、というのは無理があるけど、大体のアタリをつけるところまでだけでも頭の中でできる、後はその人の頭の出来次第でより精密なところまで可能、という仕様になっていることは、やっぱり普及するのには重要な要素じゃないかなあと思う。

そう考えると、今例えば経度方向を最上位桁A-Zの26文字で分割しているのを、2文字なくしてA-Xの24文字にするだけで、360度がきっちり割り切れ、かつタイムゾーン等でなじみも深い（残念ながらタイムゾーンと一致はしないが）15度刻みの経度分割ができる。
日本なら、東経135度以西はＵ、135度以東はＶと簡単に覚えられる。
このイメージのし易さが必要にならないかなと思った。
その下の桁は、いろいろ考え方はあると思うけど、A-Yの25文字、そしてその下の0-9の10文字であわせて250分割する事で、エリアコードあたりの経度方向の度数を0.06度、秒に直すと216秒、緯度方向なら0.03度、秒に直すと108秒といった整数値に落とし込める。
これなら、できる人は暗算できるだろう（少なくとも小飼弾ならできる、多分）。

ローカルコードは難しいけど、考え方はいくつかあるだろう。

1. どうせ最終桁までの暗算なんて無理なので、今度は[A-Z][A-Z][0-9]と使い切る
2. 26よりは割ったときのあたりがつけ易い、25で割り続ける形で[A-Y][A-Y][0-9]とする
3. エリアコードとローカルコードで使う範囲が違っていると使いにくいので、やはり[A-X][A-Y][0-9]とする。

というあたりか。
今気付いたが、3.の例が一番精度が悪くなるけど、実はエリアコードとローカルコードで考え方一致、というだけでなく、他の利点もあるのに気付いた。
というのは、エリアコードで経度は0.06度にまで落としこまれるわけだが、A-Xの24文字は6×4なわけで、一方その下の桁は25文字、10文字だから、3.の考え方だとローカルコードにより6000分割されることになる。
ということは、ローカルコード最小桁1あたり、経度方向だと0.00001度（0.036秒）、緯度方向だと0.000005度(0.018秒)というキリのいい数字に落ち着く。
これなら、ローカルコードですら暗算できるのではないか？（戸外(ry）

当然よい面もあれば悪い面もあるわけで、この改変をもし行った場合、現行ロカポだと日本周辺で最低桁で40cm程度の精度を出せていたのが、残念ながら1.4m程度の精度しか出せなくなってしまう。
現行ロカポ自体、精度は4mもあればいいんじゃないの？という事で、ローカルコード最終桁を事実上省略して運用する案も出てるわけだけど、今回私の提案した改変だと、最終桁を省略すると14mの精度となり流石に実用性がなくなる。
暗算はまず無理だが、いざとなったら40cm精度にもできる4m精度の10桁コードか、できる人なら暗算もできるけど、それ以上精度を上げられない12桁コードか、どっちがいい？っていう感じか。

ところで今回の案では、エリアコードで使わない文字ができた事で、逆にそれを使う事でエイリアスを設定することもできるようになる。
例えば、新宿駅周辺を独自座標系として設定したいなら、新宿駅を中心としてYA0.YA0とかっていうエリアコードを設定してやると、新宿独自の座標系を持てる。
エリアコードを付与してやるのは世界的な一意性を持たせてやるためだけなので、もう新宿周辺の話と判っていれば、エリアコードは用いずにローカルコード6桁だけで完結する。
問題は、作れるエイリアスに限りがあること（AZ...とかは考えずY,Zで始まるものだけを対象にすると、520×520＝270,400しか作れない...お？意外とあったな）。
それから、計算だけで成立しているはずのロカポの世界に、非計算のテーブル管理の部分ができてしまうので、組み込みデバイスなんかでの単純デコードができなくなってしまうことや管理組織をどうするか、みたいな問題も出てきてしまう。

お？待てよ？
今までロカポは便利だから使って欲しいというだけで、それを使ったビジネスモデルとかほぼないに等しい状況だったわけなんだけど、経緯度単純デコードの部分はこれまでどおり、自由に誰でも使ってもらう形で開放して、エイリアス部分を管理して販売するというビジネスモデルはあり得るかな？
緊急時の通報フォーマットとかに、計算変換できないエイリアス部分のコードなんかは使うとは思えないので、そういうクリティカルな部分は無償で回せるわけだし、付加価値にだけ課金するという形で、アリだったりするかも。

いろいろと忙しくてブログ書いてる暇もないうちにスルーしてしまっていたが、先々週の週末に誤報だったが火事騒ぎがあったのだった。

確か昼前だったと思ったが、家に家族でいると訓練とかでなく素でマジの火災警報が。
慌てて家族全員飛び出て、エレベータは止まっているので、お爺ちゃんに連れられた隣の家の小さい子を抱っこしてみんなで1階まで歩いて降りた。
途中避難階段で聞いた放送によると、火元は14階だという事。
うちは15階だから、よりにもよって下の階。最悪だ。

ところが、降りて様子を見てみると、どこからも煙等出ていない。
警備員のおっちゃんも暢気に消火器一つだけ抱えて、14階まで様子を見に行ったが、結局火の手は見つからず、誤報だったらしい。
とりあえず誤報と判ってもエレベータはすぐには復活しないので、近所で外食してのんびり帰ったのだけど。

しかしびっくりしたのは、結果的に後で誤報と判ったとは言え、素で火災警報鳴ってるのに、ほとんど避難する人がいなかったこと。
いくら週末で外出してる家庭も多いだろうとはいえ、400世帯から入ってる高層区民住宅なのに、避難して1階に下りてきたのが20人にも満たないというのはいくらなんでも少なすぎだろ。
うちなんか避難する時、家の中で薄着だった子供にジャンバーを着させたり、靴下を履かせたりしてから避難したけど、それですら緊急の際にのんびりすぎだったかとか思ってたくらいなのに。
みんなほんまに災害が起こった時大丈夫なのか。

というか、実は火災警報と同時になんか知らんけど関係ない1階のスプリンクラーが水が出まくって1階が水浸しになるわ、その後の報告もなく結局今に至るまで誤報の原因が何だったのか判らないわ、ほんまに大丈夫かいな、ここ。

Yaskeyさんが、MapServerを中心としたオープンソースGIS周りの歴史を整理されています。

MapServer とそれを取り巻く環境の変遷メモ -Yaskey Diary-

4月の大阪市立大学大学院 創造都市研究科のゲストスピーカーに向けて、MapServerに関する情報を整理中。
　　　.........
1996年には、MapServerの公式ホームページが開設されている。ちなみに、MapServerの前についている UMNとはUniversity of Minnesotaの略。

超有用。

MapServerってそんなに昔からあったのか。
当然、当時から「Web向け」GISソフトなんですよね。
すごいなあ。

でも上記記事中ちょっとひっかかったのが（苦笑）、

また、翌年にはマピオンがインターネット上でWebマップの提供を開始している。ネット上で地図が見れて、お店の位置がすぐ分るとあって、位置情報を掲載する料金を見て驚愕した。なんと１年間で数十万。何とガメツイ商売をする会社か！

「当時そう感じた」ということだと思いますが、ご存知の通りマピオンという会社自体は地図の提供元ではなく、外部から地図を買ってきて配信している会社ですよね。
で、当時の地図の値段がどの位だったかというと、OSGeo設立カンファレンスの私の発表で、そのさらに5年後くらいの段階での状況を紹介していますが、

「素人が営利目的でなくて実験的にやろうとしている位置情報サービスなので、なんとか安く地図使わせてもらえませんやろか」
「判りました、それでしたら大負けに負けて、月1000アクセスで2万円でどうです？」
「（絶句）」

というわけで、切り出した地図の画像1面表示するだけでも、年間たった12000アクセスで24万円要求（しかもこれで、非商用利用のために大負けに負けている）されるような状況だったわけです。
しかもこの業界、MapServerやPostGISもなかった時代、GISツールも馬鹿高い金を必要としていたのは周知のとおり。
先にも書いたとおりマピオン自体はそれらのデータやツールの1次ベンダではないので、それだけの原価がかかっている状況でのサービス提供に年数十万であれば、状況を知らない素人目にはガメツク映ったとしても（私も当時ならそう思っただろう）、決してアコギなことをやっていたわけではないと思いますよ。
というか、アコギだとすればマピオン1社ではなく、業界全体がアコギだったわけで。 

その辺を突き崩したのがGoogle Mapsだったわけですが、それも突き崩されてバンザーイ、嬉しいねー、では済まないわけで。
業界全体が必要以上に高額だったのは問題だったとしても、実際問題地図の作成にも、ゼンリンさんが日本中にすごい数の調査員を配置していたりするのでも判るように、すごいコストはかかっているわけです。
それをいきなり無料で開放でいいよねー、コストもそれに見合うものにしてよねー、でも品質は落さないで、というのも無理な話で。
いろいろな情報の配信が複数経路で保証されることを考えると、巨人Googleさんと組めたゼンリンさんは安泰だけど、他の地図ベンダーは潰れていいよ、というわけにもいかないわけなので、その辺をどうやって担保していくかを、今後みんなで考えないといけないんじゃないかなと思います。

ロカポイントを応援してあちこち宣伝してますと、いろいろご意見・ご指摘をいただくこともあります。
当然謙虚に伺わせていただいているので、問題点については受け止めてロケージングさんの方にも伝えて一緒に解決法を考えたりもしているのですが、一部にはちょっとした認識ズレにもかかわらず度々いただくような指摘もありますので、そういった誤解の1つを今回解かせていただこうと思います。

ロカポイントは「覚えやすい」「人間に扱いやすい」ことを目的に作られていますが、それ故にいただく話としてももっとも多いのが「難しい」「覚えられない」というものが非常に多いです。
これに関しては、確かに改善していく必要がありますが（そのため、例えばローカルコードの最小桁をフルに活用すれば40cm程度の精度が得られる仕様を、あえてエリアコードの最小桁の数字と合わせることで、精度は4m程度になってしまうがリズムを作り覚え易くする、というような方法も提唱されている）、その一方で誤解もあるのでそれは解いておきたいと思います。

まず第一に、ロカポはまだ普及していない仕様である、ということ。
その段階で受ける印象と、普及してそれを使うのが当たり前になった段階で受ける印象は明らかに違うはずです。

例えば、私は市外局番4桁・市内6桁の田舎に生まれましたが、高校くらいまで6桁覚えるだけで要の足る生活をしていました。
大学になって故郷の外に生活圏を移し、普通に市外局番含め10桁を操らないといけなくなった時は、そんなもん覚えられるわけないだろ！とか思ってましたが、実際に使うようになるとすぐになれました。
東京・大阪の市内局番が8桁になった時も、携帯電話が11桁になった時も、郵便番号が7桁になった時も、みんな導入前は不安がありましたが、あっという間に慣れました。
当たり前に普及する仕様になれば、一見難しそうな仕様に見えても、普通に扱えるようになるはずです。

もちろんその事と、位置情報を人間系を介して流通させるという事が普及するか否か、という事とは別の話なのは言うまでもないですが、位置情報を流通させる必要性が生じた場合に、もっとも簡単で覚え易く流通もし易い表記法はロカポであるとの自信はあるつもりです。
ロカポが電話番号等と比べて覚えにくいのは表そうとしているものが違うのだから仕方のないことで、論点とすべきは本当に位置情報を人間系を介して流通させるという事が必要ないのか否か、そしてもし必要だったとした場合に、同じ位置情報を表すコーディングシステムの中でどの仕様がもっとも使い易いか、ということのはずです。

また、別にロカポは全て暗記する必要はなく、暗記するのはせいぜい2、3件で十分で、後はほんの数分、脳内のメモリに蓄えられれば済むだけのものです。
既に電話番号、住所、郵便番号等と色々なコードが生活の中に出回っていますが、日常使っているそれらのコードを全て暗記している、という人がいますか？
私など、電話番号も住所も郵便番号も、自分の現住所と自分の側の実家くらいしか暗記していません。
家内の携帯電話番号すら、携帯の電話帳がなくなったら自信を持って出てこない状態です。
後はみんな、住所録や携帯の電話帳メモリに保存しているのを呼び出して使っていますし、それで事足ります。
ロカポも同じで、暗記するのは自分の家のロカポくらいで十分で（それすら別に暗記する必要性はなく、むしろ使っているうちに事前に覚えるだろうというのが本筋）、後はメモや携帯デバイスに蓄積しておけばいいだけの話なのです。
目的地のロカポをメモや携帯デバイスに書き写す間、緊急時に自分の居場所を口頭で電話口で伝える間、その間だけ覚えておける仕様であればさえいいのです。
その程度の範囲は、仕様として十分にクリアしていると思います。

もちろん、これも位置情報の人間系を介した流通の、必要性の有無とは関係ない話ではあります。
コンピュータシステムがデータを扱うに当たっては、経緯度を直接扱うのが一番処理も早く紛れのない方法なので、今後世の中が全てシステム化され、あらゆるデバイスの間で人間系を介さずデータを同期できるようになるのであれば、ロカポ等不要になり直接経緯度を扱えばよいという話になります。

ですが、本当に今後位置情報を流通させるにあたり、人間系が不要になるでしょうか。
既に普及しているメールアドレスやスケジュールといったものですら、会社のサイボウズとGoogle CalenderとW-ZERO3を同期するのに、むちゃくちゃ苦労しているというのに。

むしろ、日本版E911法の整備等で今後位置情報の利用が促進されてくるにつれ、人間系で位置情報を扱う必要はますます増えてくるものと思われます。
システム的に経緯度を送れないところへ位置情報を通知するには、経緯度を直接電話等で伝達するのは、すばやい対応等を考えるとまず困難な話。
かといって、口頭で容易に送れる住所では、表せない場所というのは非常に多いし、送れても正確な場所を逆算するには、受け取った側でジオコーディングできるデータベースを持つ必要がある。
世界一律で、簡単な計算ロジックだけで経緯度との一意な変換・逆変換ができ、口頭での伝達も容易なロカポイントの活躍の場はいくらでもあるように思えます。

ロカポイントが覚えにくい、という点に関しては、そういう視点で見ていただければ、と思います。

うわ、こんなのあったのか。
全然アンテナひっかけてなかった。
諸事情あってテラ忙しかったのだが、私的にも今の仕事的にも行かなきゃやばいだろうと言う感じだったのに見逃してた。カナシス。

というか、うちの会社から誰も行ってないのか？

『モバイルナビ会議 sponsored by ナビタイム』　-チミンモラスイ？-

高機能化する携帯電話、普及しつつある公衆無線LAN。今後発売される携帯にはGPSが実装されることが義務付けられ、2007年はGPS元年とも言われています。

このような流れを受け、言うまでもなくモバイルシーンでの仕事環境、生活環境は確実に便利になりつつあります。そしてこうした時代では、モバイルシーンにおいてどういったツールが必要となってくるでしょうか。

今回のセミナーではモバイルシーンのナビゲーションをリードし続けているナビタイムさんと一緒に近未来のモバイルナビを考えます。ナビゲーションの現状、課題を見据えつつ、モバイルシーンで何が可能になるのかを議論します。

ナビゲーションはどこまで便利になったのか、何ができて何ができないのか、ウェブや他の機器との連携は今後どうなっていくべきなのか。また、そうしたサービスや製品を広めるためにブログなどのソーシャルメディアとどう協力していくべきなのでしょうか。

以前紹介したGoogle Mapsの地図を自由に切り出すインタフェースですが、ちょっと使いにくい面があります。
画像の縮尺をZMで設定するのですが、ZM=0で最大縮尺、ZM=1で少し小さくなる...ZM=10で最小縮尺、というような単純なパラメータではなく、同じZM値を設定しても画像のピクセルサイズが異なれば違う縮尺の画像が表示されるという困った代物です。
なんか風に聞いた噂では、ZMへの設定値として表示したい領域の大きさをmで指定してやると、画像のピクセルサイズ内でその大きさが入るような縮尺を自動選択してくれるのだ、というのもあったのですが、いろいろ試してみましたがそんな事もなさそう。

んで、最近ちょっと遊ぶ機会があったので、ついでにちょっとZMパラメータ、表示画像のピクセルサイズと縮尺の関係を調べてみました。

調べてまず判ったのは、

• ZMと縮尺の関係に効いてくる画像サイズのパラメータは、画像幅のピクセル数のみ。
  縦長画像であれ横長画像であれ、同じピクセル幅の画像で同じZM値を設定した場合は、同じ縮尺が選択される。
  
• 縮尺が1つ小さくなるZM値と、画像幅のピクセル数は比例する。
  つまり、幅200ピクセルの画像で、ZM=600の場合に１つ縮尺が小さくなった場合、幅300ピクセルの場合ではZM=900の時に1つ縮尺が小さくなる

ということは、特定のピクセル幅の際に縮尺が切り替わるZMの値を調べてやれば、後は比例計算でどんなピクセル幅の時でも狙った縮尺を出すためのZM値を求める事ができます。

というわけで、幅200ピクセルでの表示を行った際の、ZM値と利用される縮尺の対応を追記欄で一覧してみました。
ついでに、飽くまでGoogle Maps上に表示されるスケール表示のピクセル幅と画像のピクセル幅を比較した上での概算ですが、各縮尺の際の、日本付近での幅200ピクセルに相当する長さも調べてみました。
言うまでもなく、メルカトル図法の図ですから、ピクセルあたりの長さは緯度により変化するので、飽くまで参考までに日本周辺での長さを調べたものです。

本当はピクセルあたりの緯度・経度ズレ量が判るのが一番いいのですが、それも過去に導出式は調べているので、その時の結果と対応付け＆裏づけチェックだけしてやれば出せそうです。
が、眠いのでそれはまたの機会に。

• OpenIDの属性交換拡張の実装例、及びOpenIDサーバに認証させるにあたってのケーススタディ
• PlaceXMLは...イマイチでした　のコメント

あたりでケーススタディという言葉を使っていて、もっといい言葉があったはずというか、俺の言いたいことと「ケーススタディ」だとちょっとニュアンス違うんだけど...という感じなんだけど言葉が出てこない...という思いでもやもやしていたんですが。

昨日やっと思い出した。
ベストプラクティスですよ。
本棚見て思い出しました。

Perlベストプラクティス posted with amazlet on 07.03.09 Damian Conway クイープ オライリー・ジャパン (2006/08/24) 売り上げランキング: 13236 おすすめ度の平均: 日頃のPerlスタイルの復習と発展学習に 私には早すぎたかな？ Amazon.co.jp で詳細を見る

というか10日間も思い出せなかったのか。
もう歳だなあ...。

転職の連絡をしばらく会っていなかった友人にしたところ、転職祝いの飲み会なぞを開いていただいてしまいました。
どうもありがとうございます。
新宿で飲んだのですが、なかなか静かで落ち着いたいい感じの店でした。

しかし、その時も話題になったのですが、共通の知人で某技術的にとんがった会社の社長がいるのですけども。
技術的に優れた人って、すごい人ではあるのだけれどどこか自分の業界以外への想像力に欠けてたり、他者への共感力に欠けてたりして何だかなあと思ったりする人も多いのですが、その社長の彼の場合、すげえ技術力持っているにも関わらず、自分のビジネスドメインとは違う新しい技術分野に関わってはその技術を「目の見えない人の生活向上に役立てるシステム構築に使えないか」と本気で考えたり、かと思えば一方で「一億円あれば人工衛星上げられるみたいなんだけど、なにかビジネスモデルあるだろうか」等と面白いことを考えていたり。
やっぱマジですごい人って、考える事のスケールもでかいし懐も広いよなあと、皆で感嘆しておりました。 

PlaceXML報告会で、YRPユビキタス研の高木先生等が中心となって開発されている、SVGビューワのα版を見せてもらいました。
これまでの唯一解と言ってもよかったアドビのSVG Viewerと比較して、その神速ぶりに驚くばかり。

まず最初に、データサイズ14MBくらいの、地球地図起源の日本全国のベクトル地図画像を読み込んだのですが、新SVGビューワが4秒かそこらで読み込み・表示完了したのに対し、アドビのSVG Viewerは20秒近く経ってようやく読み込み完了。
さらに読み込まれた後も、新ビューワの方はマウスでのドラッグでGoogle Mapsばりに自由に動かせるのに対し、アドビの方はドラッグ→数秒後に反応、という遅さで、全然操作しているという感じになれない。
アドビ側はさらに酷い事に、数回ドラッグしたところでメモリリークなどが発生するみたいで、ペイント色が指定範囲からはみ出して塗られてしまうようになったりとエライ事に。

続いて1.5MB程度の、おそらく京都の？街中地図と思われるものを開いての比較。
上の写真で、ノートPC画面の左側が新ビューワ、右側がアドビビューワなんだけど、同時に読み込み開始してからケータイのカメラ準備し始めて、準備できた直後に撮ったところ、新ビューワは既に描画を完了しているのに対し、アドビ側はまだ表示されていない。
さらに描画完了後、Javascriptを使っての地図の自動上下左右スクロール、拡大、縮小のデモに入るのだけど、同じ速度でタイマを回しているにも関わらず、新ビューワの方は軽快にさっさとスクロール・ズームインアウトするのに、アドビビューワの方は描画が追いつかず、新ビューワのスクロール速度に追いつけない状況。

そんな感じで、むちゃくちゃ速いSVGビューワでした。
さらに、対応しているSVGの仕様が新しいので、アイコン情報のように画像全体が拡縮されてもサイズを変えない要素が存在可能（古いSVG仕様だと、アイコンも一緒に拡縮される）だとか、地理的情報を持ったレイヤの重ね合わせ等にも対応しているらしい。
高木先生曰く、SVGは重い、遅いとかよく言われるけど、これまでアドビのビューワだけでそう判断されてきたわけで、その誤解を払拭したい、もっとSVGが使えるものであることを証明したいとのこと。

ちなみに、今のところ対応はIEのみで、FirefoxやOperaはネイティブでSVG対応するので対応しない予定だったようですが、ただFirefoxネイティブのSVG描画エンジンは、IEのアドビ向けのより低い性能しか出ない、ということでした（Operaは確認せず）。
なので、それだったらFirefoxにも対応させた方がよいのでは？と聞いてみると、Firefoxはオープンソースだけど、このSVGビューワに関しては一部高木先生のKDDI時代の成果とかが入っているので、それをフリーで配布するレベルの権利は既に購入済みだけど、さらにオープンソースで出すとなると、もう一段高いレベルのファンドが必要になるので、そちらの問題ですぐには難しいとの事でした。
確かアドビのSVG Viewerは、IE向けだけど何かちょこちょこっと設定した上でFirefoxのプラグイン置き場にdllを置くとFirefoxでも使えるようになったような記憶があったので（思い違いかもしれないが）、そういう形での対応はありうるか聞いてみたところ、ActiveXのインタフェースをFirefoxのインタフェースでラップするような設定ができるのであれば、Firefoxでも使えるようにもできるかもね、という事でした。

このビューワが普及すれば、SVGに対する世間の評価も変わってくるかもしれません。

仮面ライダーカブトの後頭が、かなりアホっぽい顔に見えます。
口をポカンと開ききって歯が1本。

ちょっと斜めから見ると、カブトホーンがバカ殿のちょんまげのように見えて、さらにいい感じです。

PlaceXML成果報告会2日目の目玉であるPI（Place Identifier）は、中々面白い仕様でした。

要するに、Web等上に位置情報を埋め込む際の記述仕様なのだけど、単に経緯度という単一の記述方式ではなく、もっと人間にとって判り易い記述方式（俺の家とか、サークルのBOXとか）も相互に運用可能にしようという仕様。

説明するより記述例を示した方がいいんじゃないかと思うけど、例えば、普通にWGS84測地系で位置を表そうとした場合、PIだとこうなる（wgs84.pi.org.jpという名前空間は仮）。

tag:wgs84.pi.org.jp,2006:pi:E139.43.12N35.40.11

なんだこりゃ？訳判らん普通にGeoタグとかで経緯度書いた方が判りよいじゃないか、と思われるかもしれないけれど、確かに経緯度だけだとそんな感じかもしれない。
でもPIで許される他の色んな表記方法を並べたら、興味を持ってもらえるかもしれない（言うまでもなく、いずれも名前空間は仮）。

tag:address.pi.jp,2006:pi:東京都港区北青山2-8-44　（住