SQL Server 2008 の空間サポート　-hogemanのコアダンプ（´皿｀;）-

来年リリース予定のSQL Server 2008 では空間情報サポートが入るそうで、IBM で DB2 Spatial Extender とかを書いた人の手になるものなのできっとまともです。

ポイントは、

• Flat EarthモードとRound Earthモードがある。
• 約70種の空間演算関数を用意。
• OGC の Simple Feagures for SQL にも対応。

だそうですが、私もFlat EarthモードとRound Earthモードが気になります。

以下のような問題意識（曰く「セマンティックの違い」）で2つのモードが分けられているそうなのですが、

• 平面なほうのモデルは、距離とか面積を座標系と同じ(メートルとか)単位で扱う。たとえば座標(2,2)?(5,6)の距離は5。
  一方丸いほうのモデルは、位置を緯度経度で表す。でも座標間の距離まで度で表すのはイラネ（PostgreSQLの幾何データ型自重www）。やっぱメートルとかっしょ（よく言った）。
• 平面なほうのモデルだと、bounding box に意味があるけど、丸いほうのモデルだとbounding circleのほうが自然だよね（そのとおり！）。

ということで、単純に言うとFlat EarthモードがSpatial、Round EarthモードがGeoSpatialということのようです。

PostGISでのdistance_spheroidでのフィルタリングのようなのが、インデッ クス効く形で（PostGISはインデックス効かない）提供されるなら、中々すごい事だと思います。
ここまで考慮されてるなら、東経180度の向こうは西経領域、とかも対応されてるんだろうなあ。

Oracle SpatialはGeoSpatialだって聞くんだけど、触ったことないのでどんなI/Fか知らないんだけどどんな感じなんだろう。

なんか、おもしろい本が出たみたいです。

あやまる岬 posted with amazlet on 07.06.26 高井ジロル ワニマガジン社 (2007/06/25) Amazon.co.jp で詳細を見る

<ケータイ>++<おもしろマップ>でメッセージを伝える新方式コミュニケーションBOOKの登場! 本書に掲載されたQRコードを携帯電話のバーコードリーダーでスキャンすると、携帯地図サイト上に存在するおもしろ地名、駅名、施設名が表示されます。それを使って友達、家族、恋人にメッセージを伝えよう! たとえば…、

• かるーい感じで謝りたいときは… →「あやまる岬」@鹿児島県奄美市
• 世界の中心で愛の最上級表現を叫びたいなら… →「世界でいちばん君が好き」@東京都昭島市

…などなど、全146個のQRコードを掲載しました! ページからハサミやカッターで切り取って使える「QRコード手渡しチップ」も付いているので、「これ、ケータイで見てみてね」なんて言いつつ、メッセージを伝えたい相手にQRコードを渡すワザも可能。...

おもしろい地名や施設等の場所をQRコードにして、携帯でアクセスするとその地名や施設の地図が表示されるような形で、おもしろコミュニケーションを取ろう、という本のようです。
発想も面白いですが、個人的にはQRコードを携帯からの地図に結びつける、というあたりが、俺の主張と似ててウレシス。

おもしろ地名といえば、こんな本もあるみたい。

新しい世界地図―世界ニホン語的珍地名 posted with amazlet on 07.06.26 新しい世界地図製作委員会 アートン (2005/06) 売り上げランキング: 153277 おすすめ度の平均: 笑おう！ バカらしく開放的な本! 帯でだいなしに Amazon.co.jp で詳細を見る

「スケベニンゲン」（オランダ）、「エロマンガ」（オーストラリア）、「キンタマーニ」（インドネシア）、「シリフケ」（トルコ）、「キバルタイ」（リトアニア）、「マンコカパック」（ペルー）…… 　
世界各地の地名から日本語として読めるものを（目を充血させながら）抽出し、「シモネタ」「あいづち」「新語」などの細かいテーマ別にマッピング。ニホン語的珍地名を満載した、使うためではなく楽しむための新感覚世界地図帳です。

うーん、馬鹿馬鹿しくも面白そう。

JSONモジュールでデータを出力する際、UTF-8の含まれたオブジェクトをobjToJson関数で変換すると、

    {
      "parent_category_id" : "0",
      "mapplets" : [
        {
          "murl" : "http://rkmt.net/soft/pemapplet.xml",
          "registered" : "2007-06-16 12:34:58",
          "name" : "PlaceEngine Mapplet",
          "id" : "14",
          "description" : "Place Engine \u306e\u30de\u30c3\u30d7\u30ec\u30c3\u30c8"
        }
      ],
      "name" : "\u305d\u306e\u4ed6",
      "id" : 9
    }

みたいな感じでエスケープされてしまい、うまく出力されずに困っていました。

ですが、同じオブジェクトをYAMLモジュールに与えてやるとちゃんと望む結果を返してくれるので、緊急避難的にこんな感じにしたところ、うまくいきました。

    my $ydat = Load(Encode::encode("euc-jp",Dump($dat)));
    print Encode::decode("euc-jp",objToJson($ydat,{pretty => 1,autoconv => 0}));

全く本質的な解決ではなく、YAMLへのシリアライズ/デシリアライズ処理の分遅くなるので、アクセスの多い処理なんかには使えないですし単に要件がシリアライズなら素直にYAML使っておけという感じなのですが、JSONで出すのが必須でかつ、今回の私の場合のような1日1回のバッチ処理とかならば、その程度なら上記で簡易に逃げられそうです。
本質的な解決方法ご存知の方は教えていただければ幸いです。

同じやり方で、以前悩んでたData::Dumperのエスケープも回避できるのを確認しましたが、Data::Dumperこそ基本的な用途はシリアライズでしょうし、そんならそのままYAMLが使える（し、むしろ判り易い）ので使い道ないでしょうね...。

----- 追記 -----

コメントで

$JSON::UTF8 = 1 のようにしてみるのはどうでしょうか?

といただきましたが、それについては対応しておりました。

ですが、直接JSONモジュール作者のまかまかさんにメールで尋ねたところ、

これはJSON 1.08でRFC4627に対応しようとして（というかJSON::XS互換に近づけようとして）不十分なままリリースしたために発生する問題です。
解決方法としては1.07かそれ以前のものを使う、あるいは最新のJSONに同梱しているJSON::PPを使ってください。

という回答をいただきました。
普遍的な問題ではなく、たまたま私が使ったタイミングが悪かっただけの一時的な問題だったようです。

さらには、はてブで指摘されたのですが、

そもそも unicode escape で何が問題なんだろう

ええ、だってそのままじゃJavaScriptとして送れないじゃん、と思ったものの、もしかしてそういう指摘をされるということは、JavaScriptでそのまま認識できるの？と思ってunicode escapeされたJSONデータをJavaScriptで読み込んでみたら、普通に読めました...。
別に根拠もなく、JavaScriptでは読めないものと思い込んでしまっておりました。
いや、読めるなら何の問題もないんです...無駄な事に時間を使ってしまいました...。

PlaceEngineが近頃大進化を進めています。
といっても多くは半月ほど前の話題だったりするのですが、何で取り上げるのが遅れたかは後ほど。

まずは対応プラットフォームの拡大。
2007年6月8日のアップデートで、正式にWindows VistaとMacintoshに対応しました。
これで、Mac人口の高い最先端Geekの間でもPlaceEngineが流行ってくれるかなあと期待してみたり。

さらに同じアップデートで、ついにローカルDB機能に対応しました（注：Windows版のみです）。
これまで、PlaceEngineはWiFiの電測情報をサーバに送って、サーバからのレスポンスで位置を取得していました。
これは、ローカルで膨大なDBを持つ必要がない、リアルタイムで最新のアクセスポイント情報から測位できる、住所等の付加情報も加えられるとよい点も多いのですが、一方でネットと接続できていなければ全く位置が取れないという点で問題がありました。
対するローカルDB情報は、Locky.jpシステムやPlaceEngineでもPSPのみんなの地図２で採用されたように、アクセスポイントのDBをローカル機器に持つ方式で、最新のアクセスポイント情報を常時更新等はできない代わりに、完全にネットから切り離されていても位置が取得できるという利点があります。
今回のアップデートで、PlaceEngineでも、現在地周辺のローカルDBを一部手元にダウンロードしておいて、ネット非接続時にローカルDBを使って位置推定できるようになりました。
単なるログ用途であれば、電測情報のハッシュを手元に溜めておき、ネット接続時にまとめて位置情報化することはこれまででも出来たのですが、どうしても非接続時にリアルタイムの場所が欲しい際には、このローカルDB機能が以後力を発揮する事になります。

とはいえローカルDB機能には、一度ダウンロードするとどの位の範囲で使えるのか、またDBの更新等は手動でしか行えないのか自動でやってくれるのか、複数のDBが作られるようなのだがその使い分けは、等ちょっとまだよく判らないところも多く、今後の公開が待たれるところです。
また、ローカルDBからの位置の取得は何故か電測ハッシュを引数として与えられないため、リアルタイム位置のデータしか取れないのですが、これも何となくI/Fが他と変わってくるので改善して欲しい点ではあります...まあ、リアルタイムでないのならネットが繋がるまで待ってもよかろうよ、という感じなのかもしれませんが。

さて、手前味噌ながら、PerlのPlaceEngine対応モジュール、WWW::PlaceEngineも本日アップデートしまして、ローカルDBからの位置取得機能に対応しました。
プラットフォーム拡大やローカルDB対応は半月ほど前のニュースであるにも関わらず、今頃取り上げた理由が、単にこの自分のモジュールが今までアップデートできなかったせいだったりもします。
（どうせなら一緒に取り上げたかった）
でも、よく考えてみると...ローカルDBには対応したけれど、同じタイミングで出ているMacintoshには対応できてないな、このモジュール...。
いや、インタフェースは同じはずなので、ロジック的にはそのままで動くはずなんだけど、Windows版とMac版でPlaceEngineクライアントのバージョン番号体系が異なるようなので、今のままだとMacintosh版クライアントはWWW::PlaceEngineの非対応バージョンとみなされてしまう。
PlaceEngineクライアントのバージョン判定してる部分だけ外せば動きそうだけど。
早めになんとかできるよう善処します。

さて、そんなこんなでPlaceEngineネタを取り上げるのが遅れているうちに、すごいニュースが飛び込んできました。
PlaceEngine技術を事業化するための会社「クウジット」が、設立されたようです。
これで、研究ベースだとなかなか思い切ったビジネス的挑戦なんかもできなかったんじゃないかと思いますが、面白いことができるようになりそうで、なかなか期待できそうです。
ALPSLABの中の人なんかも、「これでPSPだけでなく、DSでもPlaceEngine展開できるようになるなあ」とかつぶやいてました。
うちのサイトでも以前、FONとPlaceEngineの、技術及びムーブメント双方での親和性なんかを指摘しましたが、この辺の提携なんかも独立会社化したことで今後進んでいったりしたら面白いなあと思いました。

なんか日本の都市圏でしか使えない技術のように思われているPlaceEngineですが、国によってWiFi機器のID仕様が異なるわけでもないので、開発者の暦本さん自らパリに行かれた際PlaceEngineにAPを登録されていたように、別にデータさえ集まればどこでもそのまま持っていける技術なわけです。
（もっとも、APを経緯度座標系で管理しているとして、近隣のAPを導出する際の計算のロジックや定数が、APが日本近傍にあるとの前提でもし設定されていたとしたならば、その辺は世界対応するには考慮しなければいけませんが。）
なので、うまくいろいろ提携しつつ事業を拡げていけば、トップダウンなGPSとは別の、ボトムアップで世界的に整備される位置情報基盤として、大化けする可能性はあると思います。
ぜひ、多くの人が使ってくれるようになって欲しいと思います。

住所パワー

ちょっと流行っているみたいです。
盛り上がる冗談ネタとしても面白いんですが、一方で家を探している人への地域の安全度や便利度などをメタデータとしてリコメンドしたりとか、そんなのを研究してたりサービス化したいとか言ってたり、みたいな人も回りに大勢いたりするので、そういうアプローチの1つとしても注目できますね。

ただ、住所パワーの今のやり方だと、どの施設も半径1.5km以内と一律に切っているので、あまりアテにならなさそうです。
例えば白金台みたいな超高級住宅地が神保町みたいなオフィス街よりかなりポイント低いんですけど、これ明らかに1.5km圏内でギリギリかかるか、かからないかのところの、五反田駅前大風俗街を拾ってるからです。
東京で1.5km先の風俗街なんか街の雰囲気には影響及ぼさないでしょう。
コンビニの数も1.5km先まで計上しても仕方ないですし。

また、関西ド田舎の友人(彼の家の周辺はわずか224pt)とも話したんですが、移動すべて車の田舎では、1.5キロ等という徒歩圏での区切りは、正直関係ない数字だと言っていました。
施設の密度は地域毎の生活スタイルで差があるのは当然なので、このやり方では遠隔地の絶対値を比べても意味ありません。
絶対値を比べるなら地域毎の生活スタイルを何らかの形で指数持ちして範囲を可変するか、それとも固定範囲なら飽くまで周辺地域との相対比較にとどめるか。

住所パワー自体が改善するにせよ類似指標が現れるにせよ、そういったあたりが改善されれば、ネタだけではなく使える社会指標としても役立つようにもなるかもしれません。

前提が多すぎてこのタイトルでいいのか微妙なんですけども。

まず以下、IEと書いているのはIE6SP2に、タブ表示の拡張したものです。
素のIE6やIE7でどうなるかはよう判りません。

また、Google API統一インタフェースと書いているのは、Ogawa::Memorandaさんのこちらの記事で紹介された、

GoogleのJavaScript API三兄弟である、Maps・Search・Feedのインタフェースがこっそり統一されつつあることに気がついたので、このエントリーで紹介します。

というものです。

上記記事を読んだ直後に、このブログでもFeed APIとMaps APIを両方使っていることもあって、上記の統一インタフェースに全面移行しました（例：このエントリ）。
で、私のメインブラウザであるところのFirefoxでだけ確かめて、動いた動いた、と思っていたのですが、昨日ちょっとMaps API触ってみようと思っていろいろ試していると、IEで動かないのを確認しました。

あれ？と思って、Ogawaさんが公開しているJavaScript API三兄弟のサンプルページを表示してみると、IEでもちゃんと動く。

でも、全く同じスクリプトを、私のサーバにおいてやると（APIキーはもちろん変えてます）、

１．サンプルページ１（統一I/F、HTTPヘッダ指定：EUC-JP、HTMLメタタグ指定：UTF-8）

IEではMaps APIのところで、エラーが出て動かない。

何でだろうと思って、エラーの内容や処理を追ってみると、どうも共通I/Fから実際にMaps用のスクリプトを呼び出しているところで、文字コードの解析エラーが起こってMapsのJavascriptコードが読み込まれてないっぽい。
でも、確かに元のブログ記事ではEUC-JP環境なのでなんか文字コードエラーが起こる余地はありそうなんだけど、このサンプルではOgawaさんのコードをそのままコピペしてるだけなので、一切の差はないはず。
途方にくれて、HTTPヘッダレベルとかでも比較してみると、Content-typeヘッダがうちではEUC-JP、OgawaさんところではUTF-8になってる。
HTMLレベルではHTTP-EQUIVのContent-typeでどちらもUTF-8にしてるので、差はないはずなんだけど、もう他に確かめられるところもないので藁にもすがる思いでエンコーディングをHTTPヘッダレベルで変えてみた。
すると...

２．サンプルページ２（統一I/F、HTTPヘッダ指定：UTF-8、HTMLメタタグ指定：UTF-8）

IEでも動いた！

で、言うまでもなく、共通I/Fを使わず、昔ながらのMaps API直接呼出しならば、HTTPヘッダ指定がEUC-JPでも、HTMLメタタグレベルでUTF-8を指定しておけばちゃんと動く。

３．サンプルページ３（Maps API、HTTPヘッダ指定：EUC-JP、HTMLメタタグ指定：UTF-8）

思うに、GoogleのAPIは常にUTF-8でJavascriptコードを返すはずなので、その返されたMaps APIのJavascriptコードを、IEがEUC-JPとしてパースしちゃっているっぽい。
サンプル１．、２．、３．の違いは、３．はMaps APIのJavascriptコードを直接HTMLから読み込んでいるのに対し、１．、２．は共通I/Fを通じてJavaScriptコード内からMaps APIのJavascriptコードを読み込んでいる。
かつ、２．で動いて１．で動かないという事は、IEには、Javascript内から呼び出したJavascriptコードを、呼び出し元HTMLのHTTPヘッダのエンコーディング（たとえそれがHTMLメタタグで打ち消されていても！）でパースしてしまうという、バグがあるのではないだろうか（追記：実際にはちょっと違ってた。詳細は文末追記参照）。

ちなみに、それではと思って、サンプル１でのJavascriptコードに全てエンコーディングを指定してやればどうだろうか、と思って試してみたが、

４．サンプルページ４（統一I/F、HTTPヘッダ指定：EUC-JP、HTMLメタタグ指定：UTF-8、scriptタグ指定：UTF-8）

これでもうまくいかないので、根は深いっぽい。

逆に、HTMLメタタグ指定ではEUC-JPにしておいて、HTTPヘッダ指定のみUTF-8としてやってやるとどうなるかというと、

５．サンプルページ５（統一I/F、HTTPヘッダ指定：UTF-8、HTMLメタタグ指定：EUC-JP）

これはうまくいく。

よって、どうしてもUTF-8以外でGoogle Maps APIを使いたい人は、統一I/Fを使わずこれまで通り直接Maps APIのJSを呼び出すか、或いはかっこ悪いですが、HTMLメタタグで利用するエンコードを指定し、HTTPヘッダでUTF-8を指定する、とかの方法をとる必要があるようです。

----　追記　----

ほとんど書いてしまってから気付いたので、打消し追記で処理します。

サンプルページ１のエンコーディングをIEのメニューから表示させてみて気付いたのですが、そもそもページ全体が、HTMLメタタグで指定したUTF-8ではなく、HTTPヘッダのEUC-JPでレンダリングされてしまっていました。
よって問題は、

1. IEがHTMLメタタグを無視して、HTTPヘッダのエンコーディングでレンダリングしてしまう（あまりそんなバグは聞いたことがないので...マルチバイト文字を含まない場合だけかな？）
2. JavaScript中から読み込んだJavaScriptに対して、IEがHTMLをレンダリングしたエンコーディングでパースしてしまう（というかエンコーディングを指定する術がない）

のダブルコンボで問題が発生しているみたいです。

よって、UTF-8以外で防ぐ方法は、当面は統一I/Fを使わないことしかないみたいですね...。

関数型指数 (潜在的な関数型プログラミングの嗜好度) をはかる IAT のつもりです。

なんか流行ってるみたいなのでやってみました。

結果。

あなたの関数型指数は -0.333472217080005 です。正が関数型、負が手続き型です。

手続き型な人みたいです。
Haskellとかさっぱわからんしー。

関数型言語と手続き型言語のそれぞれが、ポジティブな言葉とネガティブな言葉のどちらと相関が高いかで指数を出してるんですかね。

位置情報連動広告「AdLocal」（アドローカル）を運営するシリウステクノロジーズは6月15日、AdLocalの広告入稿機能を一般公開した。広告主は代理店を経由することなく、モバイルサイトに出稿できる。個人飲食店などでも簡単に利用できるようにし、広告主の拡大を目指す。
　　.........
広告主としては、ラーメン店などの個人店主をターゲットとしている。1万円から出稿できるようにし、気軽に使ってもらえるようにした。

いい動き。
位置情報連動広告は、以前も書いたけど

「今・ココ」のコンテクストを利用できる位置ベース広告は、広告配信範囲を限定することで効果的な広告を安価に配信できることに魅力があるのであり、今までの非位置ベース広告だととてもネット広告のクライアントにはなれなかったような、地域密着の中小事業者、特に飲食・サービス関連の事業者にとって魅力ある広告システムになる。

というふうに地域密着の小規模事業者にとって効果・価格の面で魅力的な広告システムになるので、今回のように直販で安い金額から簡単に出稿できる途が開けたことはとてもよいことだ。
うまくアピールできれば爆発的に利用が広がるんじゃないかと思う。

ただし飲食店の多くはモバイルサイトを持っておらず、ぐるなびのような飲食店情報サイトにしか情報を掲載していない。この場合、広告のリンク先がないという問題がある。このため、シリウステクノロジーズはマイネット・ジャパンと共同で、無料モバイルサイト制作システム「katy」とAdLocalを一緒に売り込み、モバイルサイトの制作を促す。

という、モバイル上での広告からランディングページまで、一括してソリューション提供するというのもうまい戦略だと思う。
モバイルサイトの構築ノウハウなんて、街中の飲み屋のおっちゃんおばちゃんが普通に知ってるわけないからな。

というか、今だから書くけど、先に引いたうちの以前の記事の中で、

だが、最近業界の中の人に伺ったところだと、システムは優秀なものができて位置情報広告ビジネスをする準備はすっかり整っているにもかかわらず、ほとんど広告を出稿してくれるクライアントが集まらず、の開店休業状態で、どうしましょうか、という状況らしい。

と書いた話題の対象はまさにこのAdLocalだったので心配してたのだけど、今回の記事を引けば、

AdLocalを採用しているサイトは約20サイトあり、ディー・エヌ・エーのソーシャルネットワーキングサービス「モバゲータウン」で地図上に家が作れるタウン機能の部分や、カカクコムのレストラン情報サイト「食べログ」などがある。ユニークユーザー数は合計で120万人以上という。

なんだ、全然成功してるんじゃないの？
最近うまくいきだしたのかな。
そもそも元の話題自体がガセだった可能性もあるけど。

いずれにせよ、この方面には期待しているので、大成功して欲しい。

私のよく知る業界では老舗の某A社に、ほとんどの人がGoogle発祥と思ってるある技術について、実はGoogleが発表する1年以上前にその技術はこの人が開発して発表していたという、知る人ぞ知る伝説スーパー技術者がいる。
だが彼のようなスーパー技術者がいるにも関わらず、A社は何故かネット世界に対するテクノロジー的な貢献が少ない。
いわゆる「ラボ」の名が付くコンテンツはA社にもあるのだが、その中身は「ラボ」からイメージする開発者の自主的技術発表の場とは程遠く、ほとんど同社がプロジェクトとして取り組んでいる技術のテクノロジープレビュー的な位置付けでしかない。
ましてや、Web2.0、Blogosphere、CGM的な立場から貢献する技術やサービスの公開については、皆無と言っていい。いや、言っていいというか掛け値なしに皆無だ。
この方面での貢献やユーザ支持は、業界では老舗ながらネット上では過去あまりプレゼンスのなかった某B社が、最近始めたばかりの先鋭的ラボ集団に大きく水をあけられている。
それどころか業界の中でかなり出遅れていた、A社が開発したソリューションと同等のものをようやく最近になって投入した競合の某C社でさえ、さっそくブログパーツやCGM的コンテンツを導入したのに比べると、完全に業界に置いていかれている。
どうして彼のような先鋭的技術者がいるにも関わらず、A社はそういった方面で置いていかれてしまっているのか、不思議で仕方なかった。
たまたま、知人経由で技術者向けカンファレンスの参加者を紹介して欲しいと言われ、A社の彼やB社ラボの知人に声をかけた事もあって、久しぶりにいろいろ話したのだけれど。

で、上のような疑問についてもちょっと話してみたところ、驚かされた。
表に出してないA社内のラボ的なところでは、ブログパーツのようなWeb2.0的なものも、CGM的なコンテンツも、とっくの昔にネタは揃っているらしい。
にもかかわらず、なんでそれが表に出てこないかというと、そういうものに価値を見出せないスーツ勢力との社内政治の結果だという。
表に出してユーザに公開するものは、すべからく直接マネタイズできなければならない、また技術者の自主的な開発など認められず、必要な開発であるならばすべからくプロジェクトとして管理されなければならない、等と考えるスーツ連中に阻まれて表に出ていないのだそうだ。
あるいは社内の、例えばPCとモバイルとかのセクショナリズムで、うちの部署の守備範囲にあるソリューションは勝手に出されては困る、みたいな話で潰れるケースもあるらしい。

あきれて開いた口が塞がらなかった。
B社のラボ集団とも交流はあるので聞くところによると、やはり同様にラボ的な活動に対する社内の抵抗は存在し、開発したソリューションが社内政治の結果表に出せなかったり骨抜きにされたりといった苦労はどこでもあるようなのだけど、それにしたって100%（Web2.0やCGM的なソリューションで言えば）阻まれるというのはいくら何でも酷すぎる。

マネタイズできないソリューションは発表してはいけないて。
A社のスーツな連中は、ラボ的な活動の成果とは直接生み出す金だけだとでも思っているのだろうか？
Googleが伊達や酔狂で20%ルール導入しているとでも思っているのだろうか。
別に私が今さら書くまでもなく、ソフトウェア技術者の生産性はモチベーションの高さや新情報へのコミット度で10倍、100倍のレベルで変わってくるし、そのモチベーションやコミット度をコストをかけてコントロールすることなく、個々の技術者が自主的に高めてくれるならば、これほど安上がりなことはないだろう。
プログラマかコーダか、という話があるけれども、開発者が単に言われたことをするだけのコーダではなく、自発的にイノベーションを行うプログラマとして育ってくれれば、結果的に「マネタイズのために言われた事をする」際にもはるかに高い生産性で仕事をすることができ、結果的に大幅なコスト削減に繋がると思うのだが。
最近あちこちで盛んなラボ活動というのも、別にラボで開発したものをすぐマネタイズするとか、開発者が我侭や伊達や酔狂でやっているとか、そんな事が目的ではなくて、もっと大局的な、技術力向上による全般的な体質改善とコスト削減を視野に入れていると思うんだが。

また、こういった方面の活動を行わない事で、A社が取りこぼしてしまう支持層だってあるだろう。
先日、某所でこの業界でのサービスの人気投票みたいなことが行われていたんだけど、老舗でもっとも知られているA社のサービスが全投票数の5割近くの支持を受けていた一方で、B社のラボ活動も全体の1割程度の支持を受けていた。
A社は何年間もやっている、社を挙げて提供している正規の本格的なサービス、B社は最近始めたばかりの数人が片手間でやっている、ラボ的要素だけの非公式サービスであることを考えると、恐ろしい勢いでの支持率急追と言わざるを得ない。
この辺を支持する層は、今後流れ的にどんどん増えていくと思うし、また今は過去の蓄積から期待をもってA社を支持している層も、A社が何も行動を起こさないと判れば支持は離れていくだろうから、今後ますます支持率は追いつかれていくだろう。
だが今ならまだ、A社がこういった方面のソリューションを出せば、基本の支持層が厚い分相乗効果で支持層を大幅拡大できるだろうと思う。
これらの業界もGoogle等の巨人達が食い込んでくるようになって、技術力で圧倒されるだけでなく、A社やC社が売りにしてきたきめ細かなサービスの提供等まで、マッシュアップ基盤の提供等で世界60億人のクリエイティビティがGoogle等に集約されるようになり脅かされ始めている。
そこで反撃の狼煙を上げるには、まず時間稼ぎをせざるを得ないし、その稼げる時間を少しでも先延ばしするには、これまで支えてくれた支持層を少しでも厚く、長く持たせるための活動に力を入れなければいけない。
そんな中で、一定の支持率が存在する層をわざわざ取りこぼすような戦略は、行ってはならんのじゃないかと俺なんかは思うのだ。

そんな大局観もなく、目先のマネタイズできるかできないかだけでギークのクリエイティビティを阻害するスーツ連中は、万死に値するんじゃないかと思う。
目先で現金化できないソリューションを否定し馬鹿にするのはいいが、そのような彼らは目先の小銭を積み重ねる事で、Googleを上回る効率・価値を生み出せるという目算があるのだろうか。
というか、Googleは技術会社だと言われているけれど、ソフトウェアエンジニアリングのルールに「売れるかどうかは考えない」等と明記されているのも、見方によってはGoogleの「優秀な」スーツ陣による、「ギーク陣はギーク陣で全力で最高のいいもん作れ、どう売るかは俺達が全力で考えるから」という、覚悟完了のメッセージと受け取れない事もない。
「売れるもん作らなきゃ売らんぞ」というスーツと、「全力でいいもん作れ、どう売るかは全力で考える」というスーツと、果たしてどちらが優秀でかっこいいのか、と思ってしまう。

ブログバトラーの話。

なんかよく判らんのだけど倒したら記事に貼れといわれたので。
倒した証拠？になるらしい。

　　　　　　　　 ,. -‐'''''""¨¨¨ヽ
　　　　 　 　 (.＿＿_,,,... -ｧァﾌ|　　　　　　　　　　あ…ありのまま 昨日　起こった事を話すぜ！
　 　 　 　 　 |i i|　 　 }!　}} /／|
　　　　 　 　 |l､{　 　j}　/,,ｨ//｜　　　　　　　『おれはカメラの前でポーズをとっていたと
　　　　　　　 i|:!ヾ､_ﾉ／ u {:}//ﾍ　　　　　　　　思ったらいつのまにかジョジョ化していた』
　　　　　　　 |ﾘ u' }　 ,ﾉ　_,!V,ﾊ |
　　 　 　 ／´fト､_{ﾙ{,ィ'ｅﾗ　, ﾀ人　　　　　　　　な…　何を言ってるのか　わからねーと思うが
　　　　 /' 　 ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ　　　　　　　　おれも何をされたのかわからなかった…
　　　　,ﾞ　 ／ )ヽ iLﾚ 　u' |　| ヾｌﾄﾊ〉
　　 　 |／_／　 ﾊ !ニ⊇　'／:} 　V:::::ヽ　　　　　　　　頭がどうにかなりそうだった…
　　　 /／ 二二二7'T'' ／u'　__ /:::::::/｀ヽ
　　　/'´r　-―一ｧ‐ﾞＴ´　'"´ ／::::／-‐ 　\　　　　ブログパーツだとかマッシュアップだとか
　　 / // 　 广¨´ 　/'　　 ／:::::／´￣｀ヽ ⌒ヽ　　　　そんなチャチなもんじゃあ　断じてねえ
　　ﾉ ' /　 ノ:::::`ー-､___／:::::／/ 　 　 　 ヽ　　}
_／｀丶　/::::::::::::::::::::::::::￣`ー-{:::...　　　 　　　ｲ　 もっと恐ろしいものの片鱗を味わったぜ…

えー。

昨日のソニーCSL懇親会で、某「ラボ」新人の方を紹介していただきまして、その人の作ったブログパーツ「ジョネレーター」を教えていただきました。
カメラのついたPCでジョネレーターの貼られたブログを表示して、カメラに向かってポーズを取る（この時、写っている画面上の動きを止める事が大事）と、そのポーズをジョジョ化して画像にしてくれます。

私も現地でやっていただいたのですが、今家にカメラ付きPCがないため自分でのサンプルが出せないので作者さんとこの直リンさせてもらうと、こんな感じの画像が作れます。

オモシロス。

ブログパーツを貼った側の何かを主張するのではなく、ブログに来た人に遊んでもらうブログパーツっていうのは新しい気がしますね。
ミニゲームとかとはちょっと違う気がするし。

ソニーCSLオープンハウスに行って来ました。
展示自体は仕事に押されて最後の1時間くらいしか見られなかったんですが、

• フラクタル構造を持っていて遠くからでも全体がカメラに入らない近くからでも、斜めからでも認識できる2次元コード。
  一部だけが写っていてもそれがコード全体のどの一部か、というのも判るので、カメラ上にコードに紐付いたバーチャルリアリティの地物を表示したりと、そういったエンタテイメントな用途に使えそう。
• まさに上記の2次元コードをゲームに応用した、秋発売のPS3用ゲーム「アイオブジャッジメント」のデモ。
  フィールド上に配置されたカードをカメラで写すと、モニター上には遊戯王よろしく俯瞰されたクリーチャーの姿が3D表示され、カードを動かしたりぶつけたりすることでクリーチャーを移動させたり向きを変えたり戦わせたりできるというすごいゲーム。
  カードを傾けるとそれに合わせて3D画像も傾きを持ったり、画面上で3D画像に当たるよう指でクリーチャーをはじいてやると、そのままそれが攻撃になったり、まさにこれぞインタラクティブな仮想現実？という感じで驚きました。
• 家中のデバイスとデータストレージがネットワークで結びつくようになり、昔のように映像は居間のビデオ＆テレビ・音声は個人部屋のコンポと言うような「コンテンツ⇒1つのデバイス」が成り立つ時代ではなくなった中で、「どのコンテンツ」を「どのデバイス」で「どう動作」させるかという3つの設定で家中のデバイスを操作する新しいUI「TripletUI」。
  コンテンツを選ぶと自動的にそれを操作可能なデバイスが優先表示されたり、逆にデバイスから特定すると操作可能なコンテンツが優先表示されたり、またWiFi位置情報で同じテレビでも居間にいれば居間の、個人部屋にいれば個人部屋のテレビが優先表示されたり、中々便利なUIに思えました。
  またデバイスといっても単に家電だけではなく、おじいちゃんの家のプリンタに子供の写真を送ったり、Flickrみたいなサイトに投稿したりと、いろいろなものがデバイスとして設定されていました。

みたいな面白い展示がいくつもあり、刺激的でした。
もちろん、PlaceEngineも新しい発表があったようなのですが、1時間と時間が限られていたので、ネットワーク上にも新情報は流れていて知っていたこともあり、勝手知ったる？PlaceEngineは会場ではあまり見られませんでした。
PlaceEngineの新機能については、エントリを改めて取り上げます。
後の懇親会も参加しまして、旧知のたたみラボやALPSLAB、CSLインタラクションラボの方々と情報交換したり、新しくサイボウズラボやIMG SRCの方と知り合えたり、ミーハーですが天外伺朗さんや茂木健一郎さんの名刺をゲットできたり、楽しい時間が過ごせました。

で、そのCSLオープンハウスで、一番入り口に近いところでポスター発表されていたのが、こちらの本も書かれている経済物理学者の高安秀樹先生。
私も以前興味を持った聖ペテルスブルグのパラドックスを再考されていて、聖ペテルスブルグでの賞金とその賞金を得る確率の分布が経済界での会社の収益とその収益の会社の存在数の分布に一致すること、また成長産業ではその分布が聖ペテルスブルグで言うところの1回の試行での期待値が1以上、斜陽産業では1以下のようになる事などを示されて、経済活動というものが一種の全体としてギャンブル性を持っていることを示唆されていました。

それは面白かったんですが、でも元々の「何故期待値が無限大なのに、人はいくら賭けてでもこの賭けをしないのか？」という疑問には答えていないような気がしました。
その場では他の展示を見るために時間がなくて尋ねることも議論することもできなかったんですが、私は素人ながら、この問題初めて見た時から期待値で語るのは変な気がしていました。
そりゃ期待値が無限大であるのだから、無限回挑戦することが許されていればいつかは大儲けできるので、掛け金が1万円だろうが1兆円だろうが私もこの賭けに参加すると思う（そもそも、そんな掛け金を無限回投資できる奴が大儲けしたいかどうかは別として）。
でも実際には、人の持っている資産は限られているのだから、掛け金次第で挑戦できる回数も限られてくる。
回数が限られるだけでなく、掛け金が全資産のどの位の割合かによって、もし外れた場合のことを考えると、そのインパクトも異なってくる（100円だったら割と気軽に出せるけど、1万円だったら考えるし、100万円をおいそれと出せる人はいないよね）、これが第1の問題。
そして、いくら期待値が無限大といっても、そんな天文学的な額を儲けるとかいう前に、結局のところ投資額を1円でも上回るか、元が取れるか否かという、もっと単純でデジタルな指標が賭けには存在するのではないかという問題。

特に元が取れるかという方は重要で、仮に掛け金を1000円として、元手を上回った段階で挑戦をやめると考えた場合、1回目の挑戦で元手を上回ろうと思うと、1024円以上稼がないといけないのだから、その確率はたったの1024分の1しかない。
もし1024分の1023の確率で1回目は元が取れなかった場合、2回目の挑戦では1回目の損分も合わせ2048円以上稼がないといけないのだから（1回目で元手未満の1024円未満を稼いでいる可能性はあるので正確ではないが、簡単のためこうしておく）、その確率は2048分の1となり、また負けたらその次は4096円以上で4096分の1、と負けが込むほど次で元手を取り返せる可能性は低くなっていく。
無論先に書いたように期待値が無限大である以上無限回投資可能ならどこかで絶対チャラ以上にはなるはず（たとえそれに何億回、何兆回かかるとしても）だけど、実際は有限回しか挑戦できない以上、掛け金が上がるほど元手を取り返せる確率も低くなるし、挑戦できる回数も低くなり、2重のバイアスでそんな賭けに参加しようという気は起こらなくなる。

数式とかは苦手なので数学的に説明しろとか言われると困ってしまうけれども、単純に上のような理由で聖ペテルスブルグのパラドックスは起こっているだけだと思うんだけどなあ。
とかいう事をずいぶん前から思ってたんだけど、今聖ペテルスブルグのパラドックスの説明のために引いたリンク先の説明を見ると、数式が十分理解出来ていないので違うかもしれないけど、同じような事を書いているんじゃないかと思った...。

先のエントリーでこんな事書きましたが、そこで述べたGoogle Mappletが持つエディトリアルコンテンツとしての可能性のほうも試してみたくて、こんなMapplet作ってみました。

日本のMapplet集
http://kokogiko.net/mapplet/jp-mapplets.xml

やっていることは、日本で作られたMappletを一覧して紹介して、かつそのテスト動作までさせられるものです。
何で「日本の」という切り口なのか、便利な物は外国製でも紹介すればよいではないか、という話もありますが、まあ一つの「エディトリアル」な切り口ということで。
テスト動作をさせるところのロジックは、Mapplet Scrach Padのものを流用しました。
できれば、気に入ったMappletをこのMappletから登録するところまで実装したかったのですが、登録までの遷移が解析し切れず妥協しました。
気に入ったMappletを自分の登録Mappletにする際には、今のところ、一覧の下にMappletモジュールのURLを記載しているので、そちらから拾って手動登録してください。

デザインとか分類とかは...今後善処します。
誰かよければ助けてください。

日本国内で新しいMappletが追加されるたびデータ更新していく予定ですが、できれば既に同じようなことをやられているMappletナビ α版というページを見つけたので、こちらの方が集めてくれた情報をデータとして使えないかなとか思ったりもしてます。
あちらのサイトの方はデータの収集（エディトリアル）に注力してもらって、私は実装側で、みたいな。
そうすれば、「Powered by Mappletナビ α版」見たいな感じでMappletからあちらのサイトへの導線も貼れるし。
それに、今はMappletのタイトルや概要、作者をいちいちモジュールXMLから読み込んでいるのですが、これ、Mappletの数が多くなると破綻しますが、Mappletナビさんのデータを使うと既にその辺をまとめてあるコンテンツとしてデータ化されているので、負荷軽減にもなる。

最初からそうしてもよかったんですが、どうしてもMappletを分類で分けたくて、Mappletナビさんの現状のデータが分類分けされていないので、当初は見送りました。
Mappletナビさん、分類を考えていただければ幸いです。

でもこのMapplet紹介Mappletって、結局Mapplet一覧データを読み込んでいるだけなので、テスト動作をさせるところのロジックなんて共有できるし、その他の切り口からの「Mapplet集」も作れるASP化できそうですね。
例えば「ジョギングマニア必須のMapplet集」とか、「世界グルメMapplet集」とか、データだけ食べさせれば作れそうです。
ちょっと考えてみます。

---- 追記 ----

> おりょ、なんでやろ？ うちでは　FireFox　やないとあかんみたい。まぁ、それでもええねんけど。修行修行。

あああ悪い癖でFirefoxでしかテストしてなかった、と思いIEで確認した。
んで、2つ問題判明。

1. データの形式間違ってました。
   JSONって配列要素の最後に空のコンマ入れちゃダメなのね...そんな話聞いてたような気もするんですが、Firefoxで動くのでスルーしてしまってました。
2. 上記を解決してリストはIEでも出るようになったんですが、今度はテスト起動ができない。
   原因調べようと思って元プログラムのMapplet Scrach PadをIEで動かしてみたら、なんかMapplet Scrach PadもIEで動かないっぽい。
   正確には、日本のMapplet集の動かなさとMapplet Scrach Padの動かなさの挙動は微妙に違うけど、いずれにせよ元が動かないのでは動作を追いようがないので、一旦この解決は保留。

ということで、申し訳ないですがしばらくFirefox専用のMappletとさせてください。

というか、さらにOpera9でも調べてみたんだけど、なんとOpera9ではそもそもMapplet自体がまだ動かないみたい。
まだまだ、飽くまで「Preview」という段階のようです。 

単純な機能のはずなのになんとわかりにくいタイトル。

Mappletの習作として、表記のものを作ってみました。
PC版のGoogle Mapsで閲覧中の地図について、携帯版Google Localに転送するためのQRcodeを生成するMappletです。

中心座標を取得してURLを生成し、送るだけの簡単なものなのですが、作っている最中にハタと気付きました。
携帯版Google Localは、一般的な地図サイトと違い、場所（経緯度）だけでは地図は出ず、検索ワード（ラーメンとか）とセットで初めて結果が出てくるので、経緯度を転送してもそれだけでは地図は出ず、イマイチ感が否めません。
もちろん検索ワードも一緒に送ってもいいのですが、PC側で検索ワードを入力させるにも関わらずPC上では検索結果は出せないので、これも別の意味でイマイチ感が漂います。

悩んだ末、とりあえず携帯版Google Localへは経緯度を送るだけにとどめ、代わりに別サイトで経緯度を送ればすぐ地図を表示してくれる（かつ、Googleの地図ベースの）サイトを選んで、そちらのQRも発行できるようにしました。
選んだサイトは、知人のmasaさんが開発している「ここらで」。
多分、個人携帯地図サイトでは一番高機能（ユーザビリティも含めて考えて）のサイトではないかと思います。
セレクトボタンでGoogle Localか「ここらで」かを選び、QRコード生成ボタンを押すとQRが発行できるようにしました。

なお、QRコード生成には、たたみラボさんが公開されているQRコード生成スクリプトを利用させていただいています。
現在、利用許可を申請中ですので、問題があれば別スクリプトに差し替える可能性もあります。
「ここらで」については、許可をいただきました。
また、Javascript中でsprintfを利用するために、webtoolkit.infoさんのコードも転用させていただきました。

実はQRコードを最初のMappletネタに選んだのは、いまだに位置情報QRコード普及の野望を持ってたりするからなのですが、今回は単にPC地図の位置を携帯へ転送するためのQRコード生成だけですけども、いずれはそういうのに繋がるような何かを作りたいなと、そう思ってます。

---- 追記 ----

アホや肝心のMappletの場所書くの忘れとった。
以下のとおりです。

http://kokogiko.net/qrmapplet.xml

最近会社内で話題になったのを機に、測地系について再考。

測地系の違いと言うのは、基本的に基準とする楕円体の違いと原点の違いから発生します。
明治以降元々日本で使われていた旧日本測地系（Tokyo Datum）というのは、準拠楕円体として「Bessel」というのを用いています。
それに対し、最近使われるようになった、世界的な測地系にほぼ一致させた新日本測地系（JGD2000）というのは、準拠楕円体として「GRS80」というのを用いています。
また、旧日本測地系では、地球と準拠楕円体が測地原点である東京麻布で接するような位置関係でしたが、新日本測地系では地球中心と楕円体中心が一致するような位置関係のため、座標系としての原点もずれており、変換にはそのためのシフトパラメータが必要となります。
過去色々遊んだ経験上では、新旧の日本測地系で西北-東南方向に400m前後位置がずれる云々の話は、楕円体よりもこの原点ズレが誤差原因の大半を占めています。
また、GPS等で用いられ事実上の世界測地系となっているWGS84座標系は、実は準拠楕円体としてWGS84というのを使っており、新日本測地系とも少し違うのですが、GRS80とWGS84の違いは短半径が0.1mm違うだけでかつ原点は一致しているため、事実上同一とみなして間違いはありません。

実は、座標系としての、旧日本測地系と新日本測地系・世界測地系との間の差は、以上でしかありません。
ですから、本来は旧日本測地系と世界測地系の間は、計算だけで変換可能なはずなのです。
ですが、多少地理をかじった人なら、旧日本測地系と世界測地系の間の変換は、計算だけでは変換できず、地域ごとの変換テーブルを用いたリニア補間をしなければならない、と言う話を聞いたことがあるのではないかと思います。
これは、本来の座標系としての測地系の差の他に、その座標系の元で行われた「測量成果」の問題が絡んできます。

測量は、政府が公共事業として行った測量成果、その結果として設置された測量基準点を元に、三角測量等で測量されてそれぞれの場所の経緯度が特定されます。
当然、測量基準点の経緯度は政府が定め認定したものですから、日本中の各地点の経緯度も、その基準点をベースにしたものが「正」として認定されます。
ですが、旧日本測地系の元で行われた測量基準点の設置では、当時の測量技術の精度の問題等もあり、本当の旧日本測地系での経緯度座標値と認定された経緯度座標値の間に、ズレが生じました。
当然、精度誤差によるズレなので、計算では吸収できない非線形なズレです。
これは、周りの基準点との三角測量で位置を確認できず、天文測量等に頼るしかなかった岬や離島等では、特に大きな誤差となりました。

つまり、旧日本測地系の元で公式に認定された測地成果としての経緯度は、旧日本測地系の座標系の元でも「ズレて」おり、正しい値ではなかったのです。
旧日本測地系の正しい直交座標上に、測地成果での座標に従った地図のプロットを行うと、地図が正しい位置関係には表示されなかったということです。
にも関わらず、公式な経緯度座標としては測地成果の値が採用されているため、それを新日本測地系・世界測地系に変換する際には、計算ではなく地域毎の変換テーブルを利用したリニア補間でしか変換できない、ということなのです。

さて、ここで我々が日常用途で旧日本測地系⇒新日本・世界測地系の変換を行う場合を考えてみます。
考えられるのは、いまでも多くの日本の地図サイトが旧日本測地系を座標指定に使っていますが、その地図の上で得た経緯度を、新日本・世界測地系に変換するような場合です。
日本の地図サイトが、旧日本測地系での地図のプロットをどのように行っているのかは、実は正直よく判りません。
役所から出た公共測量成果の値をそのまま利用してプロットしているのか、それともそれに従えば地図が実際とは異なる歪んだ位置に表示されるのは判っているので、独自に位置の補正を行っているのか。
もしかしたら地図会社によっても異なるのかもしれません。
しかし、そのどちらかによって、旧日本測地系⇒新日本・世界測地系の変換を行う際の計算方法も異なってきます。
前者の場合は、測地成果の座標ズレをそのままひきずっているので、正確な変換をするには地域毎の変換テーブルを利用したリニア補間をしなければなりません。
ですが後者の場合、地図の位置はすでに正しい位置に補正されており、座標系が異なるだけ、という問題になるので、正しい変換をしたいならば楕円体と原点ズレを補正するための計算だけで行われねばならず、地域毎の変換テーブルを利用したリニア補間等を用いると、正確に計算しているつもりが余計に間違った変換結果を出す事になってしまいます。

旧日本測地系⇒新日本・世界測地系の変換というと、計算だけのものは簡易変換、地域毎の変換テーブルを利用したリニア補間が精密変換、と思い込みがちですが、「旧日本測地系」上での元のデータが持つ意味を正しく知らなければ、精密変換をしたつもりがかえって誤差を生む変換をする事になります。

個人が素人勉強で覚えた話なので、専門家からみれば細かい間違いがあるかもしれませんので、是非ツッコミよろしくお願いいたします。

今週はやたら地図・位置情報関係の話題が多い週だった（Where2.0の影響？）。
リアルタイムで気付いていた話題もあれば、masaさんのレポートを見るとgooラボのやつみたいに見逃してたのもありましたが。
そんな今週の話題の中でも、個人的に一番「これは怖い」と思ったのが、GoogleのMapplet機能の追加でした。

maedaさんには予言したとか書かれましたけど、記事書いた当時からPersonalized HomePageのガジェットとかありましたし、それ以上にstfuawscなのでどうでもいいんですが。
それでも形になったのを見ると、これは怖いと思った。

Mappletみたいなのが出てきそうな予感は感じていながら暢気な話なんですが、一方で私はこんなことも書いてまして。

Google Mapsが台湾やタイにも対応

別にこれは位置情報業界にとっても危機ではなくむしろ歓迎すべきことで、いぜんにも書きましたけど、このような世界共通で使える基盤としてのグローバルサービスも必要だけれども、一方で各地の特色・ニーズに最適化したローカルサービスも必要になるのは当然であり、そのセグメント分けで共存はできるんじゃないかと思います。
だから競合するどころか、むしろグローバルサービス⇔ローカルサービス間のシームレスな相互接続経路すら作られていいんじゃないかと思ったりもします（例えばGoogle Mapsで、日本近くの拡大図に来るとマピオンやMapFan、韓国だとCongnamulなんかの対応するページへの導線が貼られたり、逆にそれらのページからも、各国全図以上の縮尺に対してはGoogle Mapsへの導線が貼られたりとか）。

ローカルサービスはローカルな事業者に任せておけばいいという意味では、Googleトランジットなんかは別にGoogleがやらなくてもいいサービスじゃなかったのか、という気もしますね。

うちの会社なんかも某地図サービスやってて、技術力よりは編集された（自分達で編集する場合も、編集されたものを買う場合もある）エディトリアルコンテンツの展開で売っているところで、それなりの支持も集めてたりするんだけど。
Googleはコンテンツそのものに人間の手を入れるようなことは絶対にやらないが、一方で特にコンピュータやWebのリテラシーの低いユーザ層のニーズ、或いはグローバルではなく各国事情特有のニーズ、に答えるようなコンテンツ（Googleが絶対にやらない類のコンテンツ）はやはり一定のニーズはあって、各国独自の地図サービスはそういうところを追求していけばええやん、元々そっちが得意そうなんだし、みたいな事を考えてた。
だからグローバルな次元の共通地図基盤はGoogle Mapsが、各国の固有ニーズに答える、痒いところに手が届くようなサービスは各国の地図サービスが担当して、共存できるというだけでなく、積極的に協力して、「この地域の詳細情報はこちら」みたいな感じでGoogle Maps⇔各国地図サービスの導線を張る様な展開もありじゃないの？とか考えてたりもしてた。
（実際にそんな提携が進んでいるわけではなくて、俺が勝手に思っているだけですよ）

でも、Mappletが出てきたのを実際に見て、その甘い見通しが吹っ飛びまして。
なぜならば、Googleは技術的に処理できるところばかりが強くてエディトリアルなコンテンツが弱いとしても、Mappletが出てきたことで、それをGoogle以外の誰かがGoogleの基盤の上で補うことができるからです。
Googleは全くコンテンツ作成の労と金を払うことなしに、全世界60億人のセンスと開発力を使ったエディトリアルなコンテンツも自分達の中に取り込める可能性を実現したのです。
「今週末行くなら？話題のスポット100選」だとか、「今見ごろの桜スポット100選」なんてなコンテンツだって、Google Mapsの上で展開できるようになるのです（何度も書きますが、Google自体はコンテンツ作成に一銭の金も払う事なく！）。
それだけでなく、それぞれのエディトリアルコンテンツの、レイヤーを重畳しての比較検討もできるようになる。

タダでGoogleにそんなコンテンツを作ってやるインセンティブなんてないだろうって？
開発者にしろアーティストにしろ、表現したいと感じている人間のモチベーションをなめちゃいけませんぜ。
それに、Mappletの規約自体はよく読んでないけど、もし商用利用が禁じられていないなら、天下のGoogle Maps上で自分が儲けるための機能をMappletとして仕込んでくる奴だってでてくるかもしれない。
例えばちょっと考えるだけでも、HotPepperや食べログやぐるナビのAPIから取得できるPOIには、アフィリエイトへの導線を張れるようになっているものもあるけど、そのようなアフィリエイトリンクを張ることがMappletの規約で許されるなら、儲ける事を目的でそれらのグルメサイト比較検索Mappletを作ろう、と言う奴も出てくるかもしれない。
もし現在規約で認められていないとしても、認めた方が優秀なコンテンツが提供されるとGoogleが考えればそんな規約は撤廃されるだろうし、そうなるとGoogle Mappletが一つの位置情報コンテンツビジネスの場として成立するようにもなるかもしれない。

便利なMappletが山ほどできたとしても、ユーザがそれにリーチするのも大変だろうって？
それは確かにそうなんだが、注目の新作Mappletを紹介するMappletなんてのだって作ろうと思えば作れるだろう。
「団塊の世代のセカンドライフを応援する新作Mappletとその使い方紹介Mapplet」とか。
そうなってくると、Googleは何もエディトリアルな事に投資も労力もかけていないにもかかわらず、Google Mapsがどこにも負けないエディトリアルコンテンツの一大集積地になる未来は容易に想像できる。

翻って、国毎の地方ローカル地図サービス側だ。
そりゃ俺がこう書いたからといって、今日や明日や明後日や、まあ少なくとも1年位の間は、Google Mapsもすぐにはエディトリアル化されるわけではないと思うし、これまで国別のローカルエディトリアル地図サービス使ってたユーザが、すぐにGoogle Mapsに移る、というようなことはないだろう。
でも、3-5年の間には、間違いなくそういう方向に進むだろう。
そんな時に、技術力ではGoogleには勝てそうもない、でもローカルでエディトリアルなコンテンツ提供力では勝てる、とか考えてるようなローカル地図サービス業界は、どう生き残っていけばいいのか？
本当にエディトリアルなところでしか勝てないのならば、それでもGoogle Mappletの潜在的な世界60億人のコンテンツ提供能力には勝てるはずもないのだから、それならばむしろ金もかかる自前の地図提供基盤は捨てて、Google Mappletのビジネス基盤上での優秀なエディトリアルコンテンツプロバイダとして生き残る道を探った方がいい。

それが嫌なら、単にコンテンツの編集能力とかだけではなく、それ以外の部分でGoogle Mapsに勝てる部分を模索しなければいけないだろう。
例えば、まだGoogle Mappletが出たばかりで、エディトリアルな地図サイトとしては遥かにユーザから支持されている今のうちに、Google Mapplet同様のユーザコンテンツを自サイト内に取り込めるような経路を設けることで、ユーザコンテンツの受け入れ基盤としての国内優位を今のうちに築くとか。

Google Mapsは位置情報業界に対する黒船とかよく言われたけど、それに喩えるなら今回のGoogle Mappletは下関戦争あたりのインパクトか、いずれにせよ国内地図サービスにとっては、今後は正念場になるのではないかと思う。

こんな記事を以前書きましたが、その後、部署内のメーリングリストを通じて問題と施策の概要を連絡して、部長から対応したいのでレビューを開いてくれと言われて、資料作ってレビューして、とりあえず私の案が採用してもらえることになりました。
「それ××でできるよ」では通用しなくても、ちゃんと手順を踏めばちゃんと実現できました。

とはいえ、なおこの後に開発部隊内での実現性検討、スケジューリングとかいろいろあるみたいなので、形になるのは何週間後か、下手すれば月単位で後かも。
「それ××でできるよ」の示唆だけで開発部隊がピンと来てくれて、自分達の方で改善案まとめて、すぐ日々の改善サイクルにあげてくれるようなところに比べれば、格段の動きの遅さは否めない。
でもまあ、できることからやって徐々に改善していくしかない。