古いVAIO（といってもうちにある唯一の携帯用PCなんだけど）を息子でも使えるようにもうちょっと設定してやろうと思い、HDDの中整理してたら、超昔のケータイ版ここギコの画像が出てきた。

ケータイ版ここギコと言っても、今のブログしか知らない人には何のこっちゃ？という感じだと思うけど、昔はケータイ向け勝手地図サイトやってたのね。
元はこの2ちゃんねるスレ（今見れば恥ずかしいスレタイつけてるな...）が起源でできたケータイ向け勝手サイトで、2ちゃんねるが起源なもんでGPS吉野家検索機能つけたりとか、色々遊んでた。
吉野家の情報といっても、そんなの経緯度情報付でなんか当時は存在しなかったので、

• 吉野家オフィシャルサイトをクロールして住所ゲット
• 住所文字列をマピオンの住所検索に食べさせて住所代表点の経緯度ゲット
• MapFanが当時から比較的地図面上に吉野家の位置を表記していたので、マピオンから得た経緯度情報周辺のMapFan地図を表示し、目視で場所を修正してやると経緯度が修正されるようなVisual Basicプログラムを組んで、1店舗1店舗手作業位置修正
• もちろんマピオンがうまく住所変換できない店舗も、MapFan地図上に表記のみつからない店舗もあったので、チェック度合に応じて精度情報を付けた上で、ケータイGPS（或いは住所やiエリア等）からの検索結果提供

みたいなことやってた。
今考えると、一銭にもならんことにようあんな労力つぎ込んでたなあという感じ...面白かったけど。

で、地図配信もやってたんだけど、もちろん地図も持ってるわけないので無許可パクリ、最初はMapFanを使ってて、この記事にも書いた

5-6年前I社さん（今は仲良し）に「地図を安うで使わせてもらえんじゃろうか」とお願いしたところ、「判りました、1ヶ月1000アクセスで2万円でどうでしょうか」と言われて貧乏サラリーマンが涙を呑んだことがあったのですが

の出来事以降は、ちず丸に乗り換えてパクってました。
当然ケータイの数字キーで地図の東西南北移動、拡大縮小できたわけですけども、ケータイは機種毎に画面サイズが異なるので、移動距離を機種問わず固定にしてると使い勝手が悪くて仕方がない。
でも、ケータイの画面にあわせて移動量を変えようと思うと、1ピクセルあたりの経緯度の変異量のテーブルを持たないと無理なので、各縮尺毎に地図画像を少し動かしては、何ピクセルずれたか調べてピクセルあたりの経緯度の変異量を求めたりとかもしてました。
ちず丸さんは地図画像URLに埋め込まれた経緯度情報を暗号化（といっても、せいぜいスクランブルしてた程度ですけど）されてたりもしたので、それも解析したりとか...色々苦労しました。

後、いろいろインタフェースとかの妙な実験もやってたなあ...地図を移動するのに、数字キーでの上下左右じゃ細かい位置の特定がとてもできないので、地図上に縦横それぞれに0から9までの座標を振って、2桁の数字を入力させて細かい場所を特定させるインタフェースを作ったりとか。

▲ 詳細位置取得I/Fの例 ▲
例えば横浜駅のあたりなら「87」

後は方角を特定し易いように、太陽や月が出ている時間帯にはその場所での太陽・月の方位を求めて、地図中心からの方向をプロットしたりとか。

▲ 方角取得I/Fの例 ▲
右下のオレンジの丸が太陽の方角なので、
太陽を背にして立ちつつ、画面上の太陽と中心点を結ぶ線が
自分の向いている方向と重なるようにケータイを持てば、ケータイの
上部が向いている方向が北、という仕組み

位置・画像投稿可能な掲示板とか、位置・時間でフィルタリングした広告配信実験とか、色々やってたなあ。

後、ケータイ版ここギコの画像で忘れてはいけないのが、これ。
といっても、配信はPC版でされていた画像だけど、

▲ au版アンテナ奪取のアンテナ分布地図、2003年7月頃 ▲

今は「日本縦断アンテナDASH」に引き継がれている、アンテナ奪取ゲームの、2003年7月頃のアンテナ分布図。
残念ながら、au版しか見つからなかったけど、私自身も久しぶりに見る画面で、すごく感慨深い。

これはマニアック。

地球上の最短コース（大圏コース）が取得できるAPI

こんな感じで、北朝鮮からアメリカだって攻撃できちゃいます。
残念ながら日本は、メルカトル症候群の人がのたまうような、アメリカの盾にはなれまへん。

大きな地図で見る

これだけ見ると、マニアックで面白いけど、どう使おう？と思えるAPIですけど、でも最近のALPSLABの傾向はおおむね、正しい方向性じゃないかと個人的には感じてます。
なんだかんだ言って、地図の多様性や地図情報の囲い込みの危険性を説いたところで、普通の大多数のユーザ、地図では単に場所が特定できればよくて、メルカトル図法で何にも困らないようなユーザにとっては、Google Maps (或いは好みによってYahooやMSN地図)で全然困らないわけです。
かくいう私ですら、MapServerとか調べ始めた大元のモチベーションは、無料で使える地図が欲しくてだったわけですけども、Google Maps等が出てからはその大元のモチベーションが失われた状況なので、話題をキャッチアップする程度にしか追ってなかったりする始末ですし。
そういう状況ですから、もちろんオープンソースツールとしてのOpenLayersや、オープンデータとしてのOpenStreetMapは必要なわけですけども、それをGoogle Mapsの対抗馬として世に問うたところで、極々一般のユーザの心には全く刺さらないんじゃないかと個人的には思ってます。
だったらもう、表記が画一的、メルカトル図法、北が上の地図で満足できる層はGoogle Mapsに全部任せてしまって、他はそうじゃない方向を目指すべきなんじゃないかなとか最近考えてます。

たとえば、ベクターデータ。
地図って、本当に画一でいいんでしょうか？
得たい情報によって表記情報の粒度を変えるべきかもしれませんし、自社のイメージにあわせてサイトのhtmlデザインを変えるように、地図だって配色やフォント等を変えるべきかもしれません。
我が社に訪れるお客さんがいつも迷ってしまわれるのは、もしかすると駅出口付近が方角が掴みにくい地形で、北が上の地図だと迷われてしまうからかもしれません。
そういう、ニーズによる地図情報粒度の細かな加工、デザインの変更、方角の回転等は、Google Maps方式のラスタ画像地図では実現できず、ベクタデータでしかできません。

或いは、地図図法。
地図を使った色分けによる比較データを表そうと思えば、面積の正確な地図が要りますし、方角を正確に表現しようと思えば、方角の正確な地図が必要になります。
こういった用途には、メルカトル図法は利用できません。
そういった用途に用いるために、メルカトル図法以外による地図サービスというのは、アリなのではないかなとか最近思ってます。

で、ALPSLABの動きを見てると、ALPSLAB略地図は用途にあわせて地図の情報粒度を落とすサービスだし、ALPSLAB designは用途にあわせて地図のデザインや方角を変更しようという取り組みです。
ALPSLAB ぷるぷるMAPも、ベクタデータならではのもの。
ALPSLAB白地図の統計なんかも、地図を使って統計を行うという、GISでは当たり前の概念ながら、Google Mapsで位置を表す事しか知らない層に対しては新しい提案ですし、今回の大圏コースAPIも、Google Mapsのメルカトル図法に慣れた層には、新しいインパクトだと思います。

そういうわけで、ALPSLABの方向性は、非常に面白く、かつ正しい方向性じゃないかと、個人的に思ってます。

「性同一性障害による内定取り消し違法」静岡の女性が会社提訴

この1件に関する個人判断はちょっと保留、というかわかんない。
性別詐称（と言えるかは別として）以外の理由（保証人うんちゃら）も挙がってるし。

でも、ニュー速あたりでそりゃもうアレな意見が飛び交ってたので、ちょっと性同一性障害（GID）周りの空気について考えてみた。

私の脳内前提。
完全に主観だけど、男女の性差（社会的役割、ジェンダー）についてうるさくいう人ほど、GIDについて理解がないような印象を感じてる。
いや、判らない、完全に思い込みで存在しない影とシャドーボクシングしているだけかもしれないんだけど。
仮にそういう属性の人たちがいたら、と言う話で以下読んでほしい。
もしそんなの思い込みだったんなら、それはそれで「そんな人いなくてよかった」、というアレで。

考えたのは、ジェンダーについてうるさくいう事と、GIDについて理解を持たないことが、論理的に共存しうるか、ということ。
まずジェンダーを強調する立場から考えてみる。
男は男らしく、とか、女は女らしく、とか、男は社会に出ろ、女は家庭を守れ、みたいなのは、本質的に男女に生まれ持った差があるという考えを受け入れているものと考えられる。
まあ男女差と言うのは体力とかいろいろあるけど、社会的役割を論じる場合は思考・精神的な差が大きく影響するはずなので、要するに男女の脳に器質的な差がある、という見解を受け入れていると思われる。
本当に男女の脳に器質的差があるのかどうかは知らないけど、ジェンダーをうるさくいう立場の人間なら、その考えを受け入れていると判断できるだろう。

でも、器質的な差が存在するなら、それが先天的障碍などで本来備わるべき器質と異なるものが備わってしまうことも当然考えられるわけで。
人間の、いや生物の設計図なんて、精巧とも言えるけどある意味いい加減なもんなんだから、内臓の配置が左右逆な人等、一般的な設計図と異なる体を持って生まれる人は必ず一定数出てくるはず。
男女に脳の器質的差があることを受け入れるなら、その器質が誤って顕在化してしまう可能性も一緒に受け入れざるを得ないはずで、そう考えるとジェンダーについてうるさくいう人はGIDについて理解がないとおかしい、と言う気がする。

逆に、GIDを理解しない立場から考えるとどうなるか。
GIDを理解しないということは、そのような取り違えが起こるはずがないと考えているわけだから、男女間に脳の器質差がある、という前提を受け入れていない、と考えていいと思う。
だって、器質差が存在するなら、取り違えが発生する可能性は必ず存在するのだから（もっとも性差を代表すると言える生殖器ですら、ふたなりみたいな事例もあるのだし）。
でも、脳の器質差が存在しないなら、ジェンダーを固定しなきゃいけないような論理的根拠なんてなくなっちゃうんじゃないのだろうか？
同じ脳を持っているなら、同じ役割果たせて当たり前じゃないか。

というわけで、ちょっと考えてみた結果、ジェンダーをうるさく言うのならばGIDについて理解があってしかるべきだし、GIDを理解しようとしないのならばジェンダーフリーな発想をもってないとおかしいんじゃないの？という結論になった。
なので、もし、私の脳内妄想だけでなく、本当にジェンダーにうるさくGIDにも理解がないような人がもし、仮にいたら、その人はバカでアホ、マヌケで(ry なのだなあ、と思われる。

私？
私個人的には男女の脳の器質的差は多分存在するんじゃないかなあとは思うのだけど、別に社会的役割への適合性が男女間に存在する何らかの閾値で完全に分けられるようなものじゃなく、その他の性格や人格、経験等のファクターによっても重層的構造になるようなものだろうから、ジェンダーとか関係なく客観的にその立場に適した資質を持つ奴がその立場につけばええやん、という感覚。
器質的差はあるんじゃね？と思ってるので、当然GIDも理解できる（といっても、現象として存在することを理解できるだけで、GIDの人の心が理解できるとか、問題を受け止められるとかそんなんじゃないけど。GIDの人は近くにいないので、そのレベルでは判らない。ゲイの友人ならいるけど）。

余談だが、先日息子の幼稚園の公開保育に参加したところ、もち付き大会の思い出の絵を描く課題だったんだけど、見事に

• 男の子
• • 一人しか登場人物を描かない　背景なしだが、近景しか描かず背景は省略と言う感覚？　（7-8人）
  • 複数人の存在を描く子も、一人が突出して大きく、残りの人は背景　（2人）
  • 人物は一人だけ、壁・窓等の背景あり　（1人）
• 女の子
• • 複数人を描き、全員が同等の大きさ　背景なし　（4-5人）
  • 一人だけ描き、背景なし　（1人）

という感じで、一部例外はあるものの見事に「男の子は立体的、女の子は平面的」という、よく言われる子供の絵の男女差の俗説の傾向がそのまま出ていて面白かった。

今日、自分のauケータイのオフィシャルメニューをなんとなく見ていて凍りついた。驚愕した。

Wiki検索...もちろん内容はWikipedia検索。

これはもう、ダメかもわからんね...。

これはすごい。

ブログ同士で“SNS”が作れる，Googleが「Social Graph API」サービス公開

これで本当に、インターネット全体がSNS化して、既存のクローズドSNSは過去いずれ単なるID提供とソーシャルなアプリケーション（コミュニティとか、信頼されたメッセージングとか）を提供するだけの存在になるだろう。
かつてのパソコン通信とインターネットの関係のように（その他の過去記事１、２）。

はてブを見ると、

julajp ...でも(仮定)シークレットのアドバンテージもある
ukyooo 「Social Graph」は良いと思うけど、SNSってクローズドだからこその価値があると思うんだけど。

みたいなことが書かれているけど、違うんだって、ここからこれまで基本オープンな情報しかなかった公開Webが、クローズドな要素も含んだものになっていくんだって。
これまでも、完全クローズドなMixiのようなSNSから、NowaやVoXのような半分オープン、半分クローズドなものまであったわけだけど、それらをクローズドたらしめていたものは何か？というと、以前も書いたけど単に個人特定のためのログインの機能であるわけ。
後は、誰にクローズドなデータを見せて、誰には見せないかと言う承認を制御するための、ソーシャルグラフ。
この2つがあれば、ログインにより今見てる相手が誰か判っているので、それをソーシャルグラフに照らし合わせて、このコンテンツはこの人には見せない、この人には見せる、ということが制御できるので、それをしているのが今のクローズド/半クローズドSNS。
今はログインという機能もソーシャルグラフと言うデータも、SNSサービス側がガメっているので今のような形態しかとれないけど、逆に言うと、このオープンな場でも使えるこの2つの機能さえあれば、普通のブログ/Wikiサービスや、個人サーバ上のブログやWikiなんかでも、今クローズドなSNSで実現しているような情報の流通制御はできてしまう。

で、今オープンな場でのログイン機能というと、OpenIDのような仕様は既に出てきてる。
さすがにまだ、今のISPにログインすると後は意識せずにインターネットどこでも行ける、といったレベルまでは洗練されておらず、いちいち新しいサイトに行く度にログインを意識しないといけないレベルでしかないけど、いずれはブラウザがネイティブにOpenIDに対応して、ユーザに意識させず（かつセキュアに）ログインを要するサイトには自動ログインしてくれるような形になるだろう。
で、そうなると後は必要なのはソーシャルグラフだけ。
今までもFOAFとかはあったので、アトミックなソーシャルグラフは存在し、FOAFベースで個人サイトの情報流通制御とかは可能だったわけだけど、飽くまで切れっ端のソーシャルグラフだったので、Mixiみたいな「友達の友達まで公開」みたいなことはできなかった。
いや、やろうと思えばできたのだけど、そのためには自前でクローラ走らせて、自分の友達のFOAFを追って...みたいなことをしないといけなかった。
その辺をGoogleがクロールしてくれて、API一発で自分の友達の友達が誰か、といったところまで取得できるようになった（今一応APIドキュメント斜め読みした限りでは、そのレベルまでの情報が取れそうな感じ）ことで、Mixiでできることはオープンでもできる素地が整ったと言っていい。

というか、SNSを実現させるに必要な2つの要素、ログインとソーシャルグラフの双方について、オープンな仕様が同じ人（Brad Fitzpatrick氏）から出てきた、ということにもっと注意が向けられるべきだろう。

もちろん、実際にはもう一つ要素が必要で、ログイン情報とソーシャルグラフをつき合わせて情報を出すか出さないかを判断するロジックが必要なわけだけど、それは動的なコンテンツでは今でも可能だろうし、静的なコンテンツでは今すぐには無理だけど、Apacheモジュールとかで対応すれば技術的には可能なはず。
（むしろ、見せ方をどうするか、の方が問題かも。見せたくない相手には見せたくない記事の存在すら知られたくないんじゃないかと思うので、そうなるとインデックスページは動的に生成するしかないのか、とか）
というわけで、はてブコメントにあった、

t-murachi なんだ? この API を使うと、友だち以外には見られないように記事単位でのアクセス制限でもできるようになるのか?

というのに関しては、これ自体がアクセス制限機能を提供してくれるわけではないけれど、これをOpenID等と組み合わせれば、書かれているようなことも可能になる、というのが正しいですね。

雪が降るー -hogemanのコアダンプ（´皿｀;）-

明日ぐらいハチ北とかいっとこかな。

ハチ北ナツカシス。元兵庫県民なので高校・大学時代はよく行った。結婚してからは、嫁が寒いところキライ＆スポーツキライなのでスキー自体行ってないけど。

GoogleMapsでみてみるとこんな感じ。
『HAKUBA47 WINTER SPORTS PRAK』？ よく見ると実にはくそっぽい名前にされてますが大丈夫でしょうか。

はくそワロタ。地図データ元のZENRINでも同じ表記になってますな。当たり前っちゃあ当たり前ですが。

地図は表現が勝負

最近話題のヤフーが、最近話題のアルプス社のデータを使って出してる地図ではこういう見た目。
ラベルは『HAKUBA47ウインタースポーツパーク』。等高線のおかげで地形がよくわかり、GoogleMapsよりも紙地図的な見やすいビジュアルです。シンボルの位置もゲレンデ的に自然な場所になってます。

ですねー。
Google Mapsの方は、草原なんだか何なんだか、傾きがあるのかないのかも判らない。
まあ、だからこそ地形レイヤーが作られた、というのもあるのかもしれませんが。

うちの記事ではデータの多様性というかそういう面から複数地図配給元があることの意義を以前書いたけど、こういう地図表現や地図目的の視点からも、様々な地図があることの意義がもっと知られて欲しいですね。

ヤフー地図のステキさが出てるのをもう一枚。
ホテルのラベルも縦書きとかで位置調整してる。交差点名は足を出して処理。紙地図的でじつに素晴らしい。

ちなみにMicrosoftのLive Search Mapsだとこう。
建物形状あり、建物立体感ありで、字面上のスペックは上なんだけど、うーむ。

やはり元データのZENRINでも、アノテーションは全て横書きなので、日本人が作った日本地図だから表記にこだわっている、GoogleやMSNは外国企業だからこだわってない、というのではなく、地図会社毎のこだわり場所の違いなんでしょうね。
ZENRINは住宅地図会社らしく詳細度にこだわり、アルプスは紙地図会社らしく表記にこだわってるみたいで、詳細度では今のところ負けているのでZENRINが持て囃されている感じですが、Yahooと一体化しての梃入れで調査力が増せば、見た目へのこだわりがあるだけに巻き返しはあるのかもしれないですね。

Yahooのホテル付近の例みたいな凝ったラベル位置調整を、汎用的なデータ（ラベルの表示位置を調整するような属性がほとんど入ってないもの）から、それらしく自動生成できるようなアルゴリズムとか暇ができたら考えてみよう。あと建物形状の中に表札を（計算で）綺麗に収めるようなアルゴリズムとか。そういうのの需要がある代表はやっぱり日本のような気がする。

ALPSLAB designでベクトル地図を回転させてみれば判ります（通常の北を上にした描画だと綺麗にアノテーションが重ならないが、回すと途端にアノテーションがぐちゃぐちゃになる）が、アルプスの美麗なアノテーションも、アルゴリズム（少なくともリアルタイムに処理し得るアルゴリズム）の産物ではなく、ある程度何らかのロジックの助けはあるだろうにせよ、最終的には職人技みたいですからねえ。
Google Maps以来のラスタータイル地図ブームが一息つけば、次の技術的ブレークスルーはベクトル地図だと思うので、hogemanさんが書かれているような処理をリアルタイムにも処理できるようなアルゴリズムは、今後必要になってくるのでしょうね。

テラ忙しい。
平日ブログとか書いてる暇がない。というか暇があっても仕事してる。
Subversionにはまってしまった。
前から使ってたけど何ちゃって使用で、あんまし意義とか判ってなかった。
まあ今だって何ちゃってで、見よう見まねでtrunkとかtagとかbranchとか切ってみたんだけど、そしたらすげえリビジョン上げるのが楽しくなって。
リビジョン上げたいがためにリファクタしてみたり...いや別に無駄な仕事してるわけではないのだけれど。
初めてbranchからtrunkにマージした時は感動した！

平日躁な感じでまさにハッスル状態でつっ走ってたら、週末になってさあブログでも書くかと思ってた途端うつ状態に。
まさに（精神的に、自覚している範囲では）何の原因もないうつで、多分ブーストして疲れたまってたから精神に来ただけだろうと思うのだけど、久々に思いうつで全く気力が出ずマイッタ。
今日は月に1回の狂言の練習もサボって家で寝てた。
何とか夜くらいからマシになったので、明日の練習（京都から師匠が来てるので、月1回、週末に2日ある）は多分行けるだろう。

みたいな感じの近況です。
ブログに書きたいことはあるのだけれど、中々たまっていく一方で...。
ちょっとマシになっているので、今から余裕ある限り消化していきます。

発行されるIDが長くて覚えられねーとか言ってる人がいるんだけど、そもそも人間が覚えるものではない。
OpenID 2.0だとOpenIDのログインフォームにyahoo.comとかyahoo.co.jpと入れるだけでログインできる。

すげー。
アイデンティティ飲み会とか行ってたくせに全然知らんかった。

で、それならと、スクリプトキディの私としては、新しいプロトコルを勉強するより先に、早速OpenID2.0対応のモジュールを探してみたわけなのですが、PHP、Python、Rubyならここにあるみたいなのだけど、Perl版はない。
Google Codeにopenid4perlというのがあるみたいだけど、最終更新が1年以上前なので、最新の仕様で動くのかどうかよく判らない。

色々探してたら、SixApartの中の人が、CPANにも上がっているNet::OpenID::Consumerを、branch切ってOpenID2.0対応させてるみたい。
見つけた情報元（検索に引っ掛かったけど、忘れた）では、まだ最後のとこでうまくいってない、みたいな感じで書いてあったけど、DLしてむりやりCatalyst::Plugin::Authentication::Credential::OpenIDと連携させてみた。

そしたら、OpenID1.1までのURL型IDを入れるはずのテキストボックスに、「yahoo.co.jp」みたいなIdPのアドレスを入れてやると、flatladderと同じ感じで、ちゃんとYahoo JapanのOpenID認証用ID/PW認証ページが表示された。
で、その後OpenIDをテストページに通知してよいかの確認ページを経て、テストページに遷移。
が、そこでエラー。

確かめてみると、「bogus_delegation」というエラーが出ており、調べてみると 、Net::OpenID::Consumerの540行目からのところで、

# if openid.delegate was used, check that it was done correctly
if ($a_ident ne $real_ident) {
    my $delegate = $claimed_identity->delegated_url;
    return $self->_fail("bogus_delegation") unless $delegate eq $a_ident;
    $self->_debug("verified_identity: verified delegate $delegate for $real_ident");
}

みたいな感じで、$a_ident（IdPからの、openid.identityとしての戻り値）と$real_ident（よく判らないが、OpenID1.1ではoic.identityとしての戻り値、OpenID2.0ではopenid.claimed_idとしての戻り値を入れているみたい）の値が異なればopenid.delegateの処理がおかしかったとして扱っているみたい。
で、openid.claimed_idが存在しないので空文字列になっており、絶対ここでひっかかるようになってたので、試しにここだけコメントアウトしてみると...動いた。

普通にyahoo.co.jpと入れてやれば、最終的にYahoo Japan発行のOpenID2.0 IDが受け取れるようになった。

実際には、上記コメントアウトした部分はOpenID1.1では必須な処理なのだろうと思うので、導入するならコメントアウトではなくプロトコルバージョンで分岐するべきなのでしょうし、というかそもそもOpenID2.0でも必要な処理なのかもしれません（現状コードでは動かないだけで）。
また、動作はしているものの、いくつかの変な点も見つかります。

• flatladderでのページ遷移のシーケンスを追っていると、yahoo.co.jp等と入れた後ID認証のページが表示されるまでの間、flatladderとYahooの間を何度かリダイレクトしているようなのだけど、このテストコードではリダイレクトは1回だけしか行われない
• テストページからYahooへ遷移し、ユーザがID入力を行っている間に、裏でYahooサーバからテストページに対し、クエリストリングも何もつかないただのGETリクエストが来ており、エラーが出ている

といった変な？ところがあるので、正常に動いているのかどうかはよく判りません。
私は中身全然判ってないので、一応上記で動いたよというレポートだけで、これで動かしても問題がないのかどうかは全く判断つきませんので、自己責任でよろしくお願いします。

マピオン、「PlaceEngine」を利用した位置情報取得に対応

ちょっと亀な情報ですが、マピオンがPlaceEngineに対応しています。
これまで、ALPSLABや駅探ラボといったラボ的サイト、また「ココから周辺情報検索」のようなガジェットの形ではPlaceEngine対応のサイトも多数ありましたが、地図ポータルの正規トップページが対応したと言うのは恐らく初ではないでしょうか。
また、これまでのPlaceEngine対応サイトでは、「位置を教える」場合はPlaceEngineの公式サイト地図に誘導されて位置を教える形でしたが、MapionではMapionサイト内で位置を教えられるようになっており、これも初めての実装ではないかと思います。

▲ Mapion地図面でのPlaceEngine画面。 ▲
右上の「位置を教える」を押すと...

▲ 画面がブラックアウトして、位置を教える専用UIに。 ▲
これまでPlaceEngine公式の地図一体型UIに慣れていたので戸惑うが、
位置を教えているとはっきり判るのでこれはこれでよいのかも。
ただ、「位置を教える」を完了した後は、このUIは自動で閉じた方がよいかも。

今のところ、ノートPC等での利用中心となると思うので、出先の喫茶店やカンファレンスなんかでPCを広げたりする際に、簡易に位置取得するデバイスとしての使い方になるかと思う。
でも、MapionにはiPod Touchの発売時に話題を呼んだ、Mapion Touchという直感地図サイトがあって、またちょうど最近、PlaceEngineもiPod Touchに対応するという発表が出たので、iPod上でMapion×PlaceEngineが連携すると、ちょっと面白いことになりそうな感じも。

地図のアルプス社が4月1日で解散、ヤフーに吸収合併

マジっすか。

ヤフーではアルプス社の吸収合併により、地図関連サービスのさらなる強化を図るとしている。

せっかく火が点いてきているALPSLABとかどうなるんだろう。
最近では、「ベクトル地図を使える、持っている」という強みを活かして、ALPSLABデザインとかALPSLAB略地図、ボツったみたいだけどぷるぷる立体地図とか、Googleでもやってない、できない（もちろんデータを持ってないから、だけなので、金さえ積めばできるのだろうけど、ZENRINがぞこまで出すかな？）取り組みをいろいろやってるだけに、その火が消えなければいいなあ。
Yahoo地図情報APIのチームあたりと合流して、今地図の回転可能だけどラスタ地図ベースなのでアノテーションも傾いてしまうFlash版APIを、ALPSLABデザインのベクタ地図技術と合流させて自然な地図回転ができるAPIにバージョンアップさせるとか、そういう方向に行って欲しい。

この合併で、アルプスの地図って調査力不足？で細かい地物の網羅性が弱いのだけど、Yahooと合流することで、それこそYahoo!!BBで勧誘アルバイト大量投入してシェア取ったような勢いで、地図の詳細化が進めばいいなあ、とか思ったり。
地図って、結局作るのは地道な調査だから、地域によってどこの会社が強いとか調査時期的にこっちの方が情報が新しい、とかがあったりするので、ZENRINが一番詳しいしGoogleにも採用されているのだから、他は知らないしいらないよ、潰れてもいいよみたいなことにはならないんだよね...。
実際以前も、どこだったかは忘れたけど、完成してから1年近く経ってる北陸の方の幹線道路にできた大きな橋が、Google（ZENRIN含む）等の他社地図では反映されていなかったにも関わらず、アルプスでだけ反映されてた、みたいなこともあったし。

アルプス社の名前がなくなってしまうのは悲しいですが、事業の火は消えることなく、これまで以上に発展して欲しいと切に願います。