convivial-weblog

Google MapsのStreet View と Location Viewの比較表が公開されていました。

- http://www.locaview.com/top/aboutlv.html

なんとなく同じようなサービスと思ってしまいますが、よく見るといろいろと違うものです。

プライバシー絡みで何かと話題になっている撮影視点についてですが、ロケーションビューはほぼ人間の目線から、Ｇｏｏｇｌｅは若干高めの2.5ｍとなっています。

高木氏の記事によると、ロケーションビューはプライバシーの観点からこのようにしているようです。

「LOCATION VIEW」のプライバシーへの配慮状況

各車両でカメラまでの地上高がほぼ同じになるように設定しています。その地上高に関してはカメラの性能、有効な撮影範囲（画角）などの観点から実証実験を行った上で決定しています。その中にはブログのご指摘にもあるとおりプライバシーに配慮して目線の高さに近いという点も含まれています。

ロケーションビューは測量会社が新しい地図をつくるというコンセプトを掲げてるだけあって、カバーエリア・撮影ピッチ・撮影時期など様々な面での網羅率が高くなっています。
一方のストリートビューは、ＧｏｏｇｌｅＭａｐｓ上でのコンテンツという点に割り切って非常に効率的に（ただし粗めに）データ収集を行っているなあという印象です。

こういったサービスの宣伝文句としては、「行ったことのない場所を観光できます！」というものになるのですが、いきなりそういうところを見はじめる人はあんまりいません。
まず最初は自分の馴染みの場所（自宅や職場）を見る人がほとんどです。
普段行かないような場所を楽しめるに足るサービスとなっているかどうかは、やはり普段行っているところを見てから判断するのです。

地上からの撮影画像は、私たちが普段目にしてる風景そのものです。
航空写真が鳥の目線を与えてくれるのとは、その点で大きな違いがあります。
Ｇｏｏｇｌｅは日常よりも少し高い目線から撮影を行う事により、日常の風景に少しだけ非日常的な要素を与えることができました。
その非日常的な少しの興奮が、バーチャルな空間での旅を楽しんでみようという気にさせるのでしょう。（その一方で嫌悪感を抱いてしまう人もいるのですが。。。）

そういった点は良くも悪くもＧｏｏｇｌｅは話題づくりがうまいなあと感じます。
一方のロケーションビューは、お役所仕事も視野に入れてるだけあって、うまく逃げているなあということでしょうか。

Flickrのマップ表示が、中国の北京付近だけOpen Street Mapに変わっているようです。
http://www.flickr.com/map?&fLat=39.912&fLon=116.3783&zl=4

スクロールしていくと、通常のYahoo!USの地図に戻ってしまうようです。
日本もOpen Street Mapにしてくれればよいのに。

ネタ元はこちらです。
Flickr uses OpenStreetMap « thinkwhere

出る出るとは言われていましたが、Google Maps の Street Viewが日本対応しました。
すでに海外で公開されていたので機能は予想通りですが、あらためて馴染みの場所を見ると、画像も綺麗で面白いですね。APIも使えるのでマッシュアップ的にも今後が楽しみです。
日本では類似のサービスとして、ロケーションビューが先行して公開をしていたわけですが、Tagchan's blogでは国内は2大ストリートビューの時代へ というエントリーで両者を比較していて大変興味深いです。

Tagchan's blogでも書かれていますが、ストリートビューは撮影箇所を表す青いラインと、背景の地図が重ならないところがけっこうあります。それどころか線がつながっていないところも所々見かけます。
車両搭載のGPSから撮影ラインを描いているのでしょうが、既存の道路ネットワークデータとの照合処理をあんまり真面目にやってないんですかね。それと細い道路などはけっこう省略しているみたいです。

おそらく次はVirtualEarthが斜め写真の日本版を出してくると予想しているのですが、そこをさらにハイブリッドに推し進めて、ストリートビューのカメラを使った空撮なんてしたら面白いコンテンツになりませんかね？　こんな感じで。

第2回ジオメディアサミットへ行ってきました。

前回は仕事が忙しくて行けませんでしたが、今回は懇親会も含めて参加することができました！
すでにいろいろな方がリポートされているとおり、来場者の数もさることながら、その顔ぶれをみても名だたる方ばかりで、まさにサミットという名前にふさわしい催しになったのではないでしょうか！？

なかでも印象に残ったのは、やはりグーグルさんの講演。内容は既知のことがほとんどではありましたが、「皆さん一緒にやりましょう」というテーマを掲げて、懇親会にも登場されたのはいろんな意味でカルチャーショックをうけました（笑）

ロケーションビューは順調に撮影範囲を拡げているようで、なんともとにかく前に進んでいるようでよかったです。プレゼンもすごく受けてました！

それから会場横側のスクリーンにTimelogというサービスを使って、リアルタイムツッコミが展開されていましたが、あれは面白いですねー。会場で講演を聴きながら、ついついちら見してしまいました。

懇親会ではいろいろな方とお話させていただくことができました。

マップコンシェルジュの古橋さんとは初めてお会いすることができましたが、ブログやGISNEXTの記事を拝見していたため、特徴的な名刺を見てすぐにご本人だとわかることができました！

株式会社コニットさんには、熱心に事業内容を語っていただきました。Adobe Airに参入したところとにかく仕事がいっぱいくるようになり、うれしい悲鳴をあげているようです。

MTLの高見さんとは北海道に続いての再開でした。次回は是非リクルート新社屋での開催を期待してます！

ロカポの上田さんとも久しぶりにお会いできました。なんでもロケーションビューの中山さんに講演のお誘いをしたのが上田さんだったらしいのですが、そのお二人を最初に引き合わせたのは実は自分だったことを思い出し、いろんなところでつながってくるもんだなぁと改めて感心してしまいました。

ここギコさんは相変わらずの存在感でしたが、いろいろと思うところがあるようで、、、ブログもなかなか更新されないですねえ。。。

オークニーの森さんもお見えになっていて、「ブログ拝見してますよ」と言われドキッとさせられましたが（笑）光栄な限りです。次回はぜひ森さんの講演もお聞きしたいです。

ゴーガの小山さんも、もちろんいらっしゃっていましたが、Googleさんを連れてきた立役者だったとは、、、さすがにGoogle Maps API Expertを擁するだけのことはありますねえ。

そしてなんといってもこんなにすごいイベントを開催されたシリウスラボさん、運営スタッフのみなさん、本当にありがとうございました。次回も期待しています！！

※追記
CNETでも記事になっていました。

　スゴイ地図が終わってしまうらしい。
アフィレットも出して、今後も新たな展開があるものと期待をしていましたが、、、

スゴイ地図サービス終了のお知らせ：ドコイク？編集部ブログ

２００６年９月以来、地域情報に関する情報を提供してまいりました 『スゴイ地図』でございますが、残念ながら２００８年８月７日をもちまして、 サービスを終了することとなりました。

　リクルートはWebと地図の可能性にいち早く気づいた企業の一つでした。
だからこそゼンリンデータコムに出資し、ドコイクを立ち上げ、出版社のノウハウを活かしたスゴイ地図が誕生したのだと思っていました。
　Mashup Awardが開催されたのもちょうど同じころで、IT界でのリクルートが一気に存在感を獲得した時期でもあったように思います。

　スゴイ地図のサービス終了が、何かの終わりではなく、何かの始まりであることを期待しています。

　KMLがOGCに正式に承認され、どうやら位置情報フォーマットのオープンスタンダードとしての位置を確立したような大勢になってきましたが、同じようなことを考えていたのはGoogleだけではありませんでした。
　GISの世界でも一時期OpenGISという言葉が流行ったりして、ベンダーやアプリ、プラットフォームに縛られずに位置情報を流通すべきだよねっていう考え方が主流になりつつありました。その結果、様々な団体によってたくさんの位置情報フォーマットが生まれてきました。
　そんな位置情報フォーマットたちを懐かしがりながら、私見を交えて紹介してみたいと思います。

　独立行政法人・農業環境技術研究所が、120年前の明治時代に作成された関東地方の地図をネットで閲覧できるようにするらしいです。

120年前の関東地図をネット公開　Google Earthで里山の変化実感も - ITmedia News via kwout

　これは最近の古地図ブームにのったものなのか？もしかして、「地理空間情報活用推進基本法」の流れなのか？このタイミングでの企画の真意はわかりませんが、技術的におもしろいポイントもいくつかあります。

　一つ目は、サイト上のビューワシステムで地図を閲覧できるだけでなく、WMS形式での配信も行っている点です。そのため、GoogleEarthや各種GISツールなどで読み込むことができます。もちろんGoogleMapsとマッシュアップすることも可能です。
　こういった古地図は眺めているだけでも楽しかったりすのですが、上に現代の地物を重ねることで意外な面白さを発見できたりするので侮れません。WMSサポートは地図系マッシュアップエンジニアにとって、大変な素晴らしいプレゼントであります。

　もう一つのポイントは、FOOS4Gと呼ばれるオープンソースのGISツールをふんだんに使用している点です。Internet Watchの記事によると、オープンソースソフトの「GeoServer」「GeoWebCache」「Open Layers」を利用しているとあります。
　「GeoServer」は上にも書きましたWMS形式の画像を生成するサーバアプリケーションです。Javaで書かれているようで、公式サイトをみるとOGCの規格をかなり意識しているように見受けられます。　国内ではオークニーさんのMapServerががんばっていたイメージがあり、まだGeoServerの使用例はほとんど聞いたことがないのですが、どの程度のパフォーマンスをみせてくれるのかとても楽しみです。
　Ajaxのフリースクロール地図部分には、OpenLayersが使われています。こちらはOpenStreetMapで採用されるなど、すでに一定の地位を確立してきたかのように思えます。（まだまだ不安定になってしまうこともあるのですが、、、）
　WMS（GeoServer）＋OpenLayersによる構成はとてもシンプルでキレイなアーキテクチャではあるのですが、まともにやってしまうとまったくパフォーマンスがでなくなります。そこで普通はタイル画像をはくことになるのですが、これもまともにやろうとするとけっこうな手間だったりします。「GeoWebCache」というこちらもJavaなサーバシステムはWMSをバックエンドにし、クライアントとの間に入ってキャッシュ機能を提供してくれるようです。こちらも公式サイトをのぞいてい見ると、なにやらGoogleMapsやVirtualEarthのレイヤ形式をサポートしているような、、、ということは、いちいちWMSのハックとかしなくても、いきなりGTileLayerが使えるのかもしれません。

　つらつらと書いてきましたが、つまりはFOOS4Gを使ったお手本のようなサイトになっていそうということで、自前の地図アプリを作ろうとしている人にとっては、かなり参考になるのではないでしょうか。
　そういった意味も踏まえて、「実はサーバをケチっていた」→「サイト激重」→「オープンソース使えねえ」　みたいなことにだけはならないで欲しいものです。

Dual Mapsというマッシュアップサイトをみつけました。
Google Maps、Google StreetView、VirtualEarthのBird’sEyeを並べた画面を生成してくれます。
生成した画面はこんな感じになります。→Dual Maps

真上から描かれた地図、地上から撮影した写真、空中から撮影した斜め写真、を並べて表示するだけなのですが、これが想像以上に良い感じになります。
会社やお店の紹介などに使うとよいのかも。（今のところUSでしか使えませんが）

あとは、地図と斜め写真が回転できれば最高なんですが。
地図はFlashにすれば回転できますが、斜め写真はなんとかならないものか。
斜め写真もStreeｔViewのように、全周囲カメラで撮ったらおもしろいかも。

　GoogleやYahoo！ に代表される地図APIの普及によって、地図を使ったWebサイトを作ることが本当に簡単になりました。しかしながら、昔ながらのGISをやってきた人間からすると、やはり出来合いの完成された地図の上に情報を載せるだけというのは、なんだか物足りなくなさを感じてきてしまうものです。

　かといって、自前で地図を持とうとすると、信じられない桁のお金が必要となってしまいます。
そんな時代がもう何年も続いてきましたが、いよいよ地図データを自由に使える時代がやってくるかもしれません。

　そんな期待をさせてくれるのだが、Open Street Mapと基盤地図情報です。

　OpenStreetMapは、いわばWikipediaの地図版といえるもので、ユーザーの手によって世界中の地図を完成させてしまおうという壮大なプロジェクトです。
　GPSのログからデータをトレースするというのが、ちょっとライトユーザーには敷居が高い気もします。
ベースになる航空写真だけでもなんとか用意してやって、簡易図化ができるような仕組みを用意してやると、ゲーム感覚で地図を作れるようになり、爆発的にデータが増えていったりしないかなとか思ったりします。

　もうひとつの基盤地図情報ですが、これはもうだいぶ前から騒がれていましたが「地理空間情報活用推進基本法」に基づいて公開される、国や地方自治体が整備した地図情報ということのようです。最初はかなり限定された地域のみの公開のようですが、これから果たしてどれくらい本気でデータを整備してくるのか、法律ができたからしょうがなくデータ整備しているだけなのか、今後が楽しみなところです。

　というわけでふたつのプロジェクトとも、使えるデータという意味ではまだまだのようなのですが、うまく互いが共鳴し補完しあえるような方向にいってくれないかなと他人事ながら考えていたりします。

Google Maps API に StreetView の機能が追加されるかもしれないらしいです。
ネタ元はこちら。

上記記事のリンク先によると、Google Maps API のVersion 2.103にStreet View のAPI機能が追加されているらしいです。
http://econym.googlepages.com/reference.htm#GStreetviewClient

これはまたマッシュアップのやりがいがありそうな感じです。

国際航業が米国ピクトメトリー社と斜め写真取得の技術ライセンス締結をしたようです。

-http://www.kkc.co.jp/info/newsrelease/20080226/index.html 「ピクトメトリー多方向斜め画像取得システム」の日本での独占使用権と画像所有権、エンドユーザーへの使用許諾権を獲得すると同時に、ピクトメトリー社および他国のライセンシー社が保有する画像ライブラリの相互使用も可能となります。

斜め写真の何をいまさら海外から技術導入のするのかと思いきや、5台のカメラで同時に撮影するシステムの技術導入だそうです。
プレス内容の、
・「高さ、距離、面積などの計測が可能」や
・「ＧＩＳ（地理情報システム）ソフトとの連携が可能（ＥＳＲＩやＳＩＳ等）」
といった文面から推測するには、写真の撮影位置・方位の標定なんかもやってくれるのでしょう。

このピクトメトリーという会社を調べてみたら、マイクロソフトのLive Search Mapsに斜め写真を提供している会社なんですね。
ということは、日本国内の斜め写真を同サイトで見ることができる日も近いのかもしれません。

一つ前の記事に「サーバサイドで画像の加工処理をすると面白そう」という趣旨のことを書いたのですが、IPアドレスによる制限があるために現実的ではなさそうですね。

Google Static Maps API の表示制限 - Cirius Lab.

Google Static Maps API ですが、「1ユーザあたり1日1000ユニーク画像まで」という制限があります。
...
というわけで、1ユーザーというのは、1クライアントIPアドレスになるようです。

ちなみに、APIKeyによる制限はリファラーを見てるっぽいですね。

　Google Static Maps APIがリリースされていました。

JavaScriptでぐりぐり動くGoogle Maps APIと異なり、名前のとおり静止画像が返されます。
ですので、imgタグを使って地図画像を張ることができます。

これで何がうれしいのか？
JavaScriptに依存しないということは、使用できるプラットフォームの幅が大きく拡がります。

　第一に思いつくのがモバイルです。JavaScriptが使えないスタティックなWebサイト構築にも、Googleの地図を張り込むことができます。親切なことに、「maptype=mobile」なんてパラメータも用意されています。
　実は一部のマッシュアップサイトでは、このAPI相当のものを勝手に？使用しているケースがありました。こういったサイトも含めて、今後は大手を振ってサイト構築できることでしょう（笑）。

　さらには、スクリプト等のプログラム自体から画像を取得することができますので、この画像をさらに加工するという用途が思いつきます。
（※ただし、利用規約でこの使い方が許されているかは、まだ確認していません...）
　例えば画像の上に絵を描いたり、色調を変えてしまったりなどなど。これはGoogle Maps APIでも、タイルの仕様を解析すれば可能でしたが、より間単になったと思います。
　
　と思いましたが、画像4隅の座標を取得するには、メルカトル座標の計算とか必要なので、それなりに手間はかかりそうですね...

　地図のラベル位置を調整するのって、大変ですね。
というか手作業でがんばってるんですね。というお話。

地図は表現が勝負

シンボルの位置もゲレンデ的に自然な場所になってます。
ホテルのラベルも縦書きとかで位置調整してる。交差点名は足を出して処理。紙地図的でじつに素晴らしい。

　これを機械がやってくれたら、素敵ですね。というお話。

GIS的には

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

　簡単な建物形状の中に収めるくらいならできそうですね。
でも意外と変な形の建物ってたくさんあるものです。
そういったものに完全対応させるためには、かなり骨の折れるプログラムを書く必要がありそうです。

　GISアプリのほとんどが海外製であっためか、細やかなラベル処理を汎用的に実現したものは見たことがありません。
おきまりの方法は、ラベルが（他のラベルや地物と）重ならない程度に間引きするという程度のものだったと思います。
その道の研究テーマなどにはよくあがっていたと思いますので、需要は昔から確実にあったのでしょう。
　GoogleMapsやらでこの世界のいろいろなことがドラスティックに変わりましたが、なかなか変わらない部分もあるものです。
とはいえ、この手のことに取り組むエンジニアの量も幅も拡がってきているので、GISエンジニアとは違う視点から、あっさりと実現させられてびっくりするのかもしれません。

　先日書いたとおり、ジオメディア新年会へ行ってきました。
　この手の集まりへ参加するのはけっこう久しぶりでしたが、相変わらずの濃い面々からいろいろとネタを仕入れさせていただき、とっても有意義な時間を過ごせました。
　なかなか雰囲気の良いカフェが会場だったのですが、とにかく熱気と人の多さがすごかったです。50人くらいだったらしいですが、正直狭かったです（笑）

　ライトニングトークでは、ロカポさんの＜これはすごい＞な新しいサービス（近々発表予定？）や、シリウスラボさんからリリースされたついついツイッターの紹介などがありました。自分もさっそく使っている「ついついツイッター」ですが、日経産業新聞の一面（だったかな？）にも載ったらしいです。

　おなじみの面々が多かったですが、初めてお会いする方もけっこういらっしゃり、いろいろとサービスやアイデアの交換をさせていただきました。どこかしらで何か活かしていければなぁと思うしだいであります。
　
　こういった場を作っていただいたシリウスラボさん、Googa小山さん、ここギコさんには本当に感謝です。

　ジオメディア新年会という催しに参加してこようと思います。
位置情報とかのサービス開発をしている人たちで、飲みましょうという企画だそうです。
　－ジオメディア新年会開催のお知らせ!

　自分はここら辺に該当するかも
>「経緯度の話で酒が飲める」
>「GoogleMaps によって人生が変わった」

アルプスラボからリリースされました、ALPSLAB 白地図。
こいつはかなり遊べます。

こんな感じの行政界で区切ったこんな感じの色塗り図を簡単に作れてしまいます。

なんといってもAPIを公開しているのと、レスポンスが非常に早い点がすばらしいです。

同じようなものを、MapServer＋PostGIS＋国土数値情報を使って実装したことがありますが、、、
このAPIを使えばあっという間ですね。

あとは、緯度経度を指定して画像を切り出したり、
町丁目界くらいまで対応してくれると、もう言うことがなくなりますね。

しばらく見ないあいだに、住所パワーがいろいろバージョンアップしていました。住所に対するポイントが表示されるだけでなく、判定Aクラスとかでたり、コメントをいれたりできるようです。
そしてなんと、APIも公開されています。
これはいろいろ使えるだろうと思ったのですが、住所に対してポイントが返ってくるだけで、元になっている施設の情報などは取れないみたいですね。

日本中でポイント取得して、メッシュデータでも作ってみようかなぁ。。。

SDJさんのMapServerSolutionから、Mapserver開発キット「Nez（ネズ）」が発表されて、一年近くが経っています。
ブログをみると、かなり好調なようです。

MySQLライクなデュアルライセンスになっているので、ソースコードをダウンロードして見ることができるのですが、この構成がなかなかおもしろいです。

著名な地図関連オープンソースが綺麗に並んでいて、とてもセンスの良さを感じます。
この手のフリースクロール且つ図形の編集が可能なサイトを構築しようとした場合、
恐らく今一番妥当であると思える構成がピックアップされていると思います。
さらにそれらを連携する基本的な部分の実装がされていて、
地図データがあればすぐにサイト構築できるようになっています。

どんなオープンソースを使っているかというと、こんな感じです。
・MapServer + MapScript- 地図画像の生成
・Ka-Map - フリースクロールのインタフェース
・PostgreSQL+PostGIS - 編集可能な図形データの格納

これ以外にも上記のソフトから参照するライブラリなどがあるので、詳しくはこちらに記述があります。

あとは、数値地図、国土数値情報、街区レベル位置参照情報あたりから、適当なものをピックアップしてバンドルしておくと、地図データを持っていない人もうれしいのではないでしょうか。
さらに、PostLBSのpgRoutingとgeocoder.jaも取り入れると最強かも。

-ヤフーはオークション、Googleは検索--主要ポータル、利用時間構成で大きな差（CNET Japan）

ネットレイティングスは、2007年7月度のインターネット利用動向に関する結果をまとめ、発表した。「総利用時間」から主要ポータルの利用チャネルを見た場合、その利用時間構成比に大きな違いがあった。

ネットレイティングス社のレポート

こうやってみると、地図サービスの利用時間は全然少ないですね。
-Google Maps 2%
-goo Map 2%
-YahooとMSN は圏外

ここに出ていないサイトの構成も気になるところです。
Livedoorなんかは、RSS ReaderやBlogなんかが強かったりするのでしょうか。

ポータルサイトといえば、
ニフティとか、プロバイダ系のポータルサイトがいろいろやりだしていておもしろいです。

これからは、Yahoo!がライバルです。（社長談）
http://www.nifty.com/yorn/

so-net web2.0 salon
http://www.so-net.ne.jp/web2/

地図表示範囲ないの不動産物件を表示するマプレットを作成してみました。
物件情報には、スマッチさんのAPIを使わせてもらっています。

Mappletの場所はこちらです。
http://convivial-web.com/mapplets/smatch.xml

登録方法はこちらに丁寧な解説がありました。
■Mapplet作った@速報ダム日和

Google MappletとGoogle Maps APIは、ほとんど同じといっても、
使えないクラスがあったり、GetCenterがGetCenterAsyncになっていたり、
微妙に異なる点があります。

使用できるクラス等のリファレンスは、こちらにまとまっていました。
Google Mapplets Reference

さらにopenInfoWindowHtmlで設定したHTMLがちゃんと反映されないぁと思っていたら、
こんな一覧もちゃんと用意されていました。
Content Allowed in Mapplet Info Windows

2007/6/6追記
たたみラボさんに紹介されました。
ありがとうございました。
一箇所にたくさん物件が存在するときにエラーになってしまったり、
まだ不具合だらけなので、時間をみつけて修正します。

GoogleMapsの新しいサービス「Street View」が大変な話題になっていますが、なんか例のあれみたいですね？
というのは置いておいて、今回の本命は「Mapplets」です。
これって、ここギコさんの予言していたそのものですよね。
今までいくつかマッシュアップを作ってきましたが、全部Mappletで置き換えてしまえそうです。
と思ってさっそく試してみているのですが、どうやらGTileLayerが使えないようです。
なので、ラスタ重ね合わせとかはちょっと無理っぽいのです。
GMarkerは使えそうなので、とりあえずスマッチWebサービスあたりから実装してみようと思います。

GoogleMapsを使ったマッシュアップというと、
ポイントデータを地図上に並べたものが大半かと思います。
ラインやポリゴンも一応は扱えますが、大量の図形を描画するのは難しいのが現状です。
そういった場合でも、ラスタ画像にしてしまえば、ちょっと気の利いた表現ができるようになります。

イギリスのサイトですが、不動産価格をラスタ画像にしてマッシュアップしています。
Sold House Prices in England
不動産の価格が高いところほど、地図上が赤く表示されます。
地図を拡大していくと、個別の不動産物件情報も表示できるようになっています。
単純に不動産価格を集計しているようですが、HEXで集計しているところはおもしろと思います。

もうひとつ、これもイギリスのサイトです。
Property hot spots - map of average house prices
こちらは地区ごとのポリゴンを、不動産価格で色分け表示しています。
この色分けレイヤは、GoogleMapsの上に半透明で表示されているのですが、
その透過率をユーザーが変更できるようになっています。
GoogleMapsの地図は、場所や縮尺によって色合いがバラついているので、
このようなインタフェースを設けているのだと思われます。

日本でも、スマッチWebサービスや、公示価格情報を使って、似たようなものが作れそうです。

急にMapServerのパフォーマンスが気になりだしてしまったので、
ちょっと調べていたら、同じような記事を見つけました。

MapServerとArcIMSの比較
ArcIMSは仕事でもいぢくったことがあるんだけど、なかなか性能の良いエンジンだった。それと同等？もしくは以上の性能が立証された？？？

DM SolutionのオフィシャルページにはArcIMS以上の性能と宣言されていました。

Performance

MapServer has been proven to be as efficient, if not more efficient than industry standard commercial software. Several comparisons have been done with ESRI ArcIMS demonstrating comparable if not faster map rendering speeds.

以下の記事では、ArcIMSとMapServerを競争させています。

ArcIMS vs. MapServer - Some Hard Data
MapServer
Total time: 7.47 min (467 sec 0.1566 sec/map (image), 385 maps/min)
Max delay for a map: 2.93 sec
Min delay for a map: 0.14 sec
Average for a map (with six simultaneous clients): 0.96 sec

ArcIMS
Total time: 12.08 min (728 sec 0.2426 sec/map (image), 247 maps/min)
Max delay for a map: 3.94sec
Min delay for a map: 0.12 sec
Average for a map (with six simultaneous clients): 1.49 sec

Windwos2000Serverで、200MBのShapeベクトルデータを読み込ませたところ、
MapServerの方が良い結果が出たようです。

これだけですべてを判断できるわけがなく、
・もっとたくさんの同時接続があるときは？
・RDBと連携したときは？
・ラスタデータの場合は？
など、いろいろと気になることはありますが...

MapServerのメーリングリストの中にこんな投稿がありました。

"Advantages of ArcIMS
- distribute applications over multiple machines
- Native integration with the Geography Network. MapServer can be
made to work within the geography network.
- Includes software to handle routine tasks like making the map
services (map files), designing web sites, etc.
- Supports more data formats - especially raster
- Better support for storing spatial data in RDBMS through SDE
- You don't have to try to sell a relatively unknown product
(MapServer) and philosophy (Open Source)

"Disadvantages of ArcIMS
- speed (even running mapserv as regular cgi it is much faster)
- resource hog
- limited OS (no Linux)
- less stable. My ArcIMS experience is on NT so that may be more a
reflection of the OS than ArcIMS.
- poorer support
- source code unavailable
- cost"

結局のところ、速さだけならMapServerの方が上のようです。
ちょっと強引ですが、「OracleよりもPostgreSQLのほうが速い」、みたいな感じでしょうか。

PSPといっても、Play Station Portableではありません。
Push-pin Service Providesの略で、オークニーの森さんが作った言葉です。

Where2.0雑感

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

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

上記のエントリは8ヶ月ほど前に書かれたものですが、最近日本ではクネヒトという会社がこんなプレスリリースを出しました。

クネヒトとチューリッヒ：業務提携発表と共同サービス・ローンチ 　本日、クネヒトとチューリッヒは業務提携にもとづいて、共同サービスをローンチいたしました。

プレスリリース ： クネヒト、事件・事故の可視化サービス「Knecht ハザードマップ」をチューリッヒ保険会社に導入

22才の大学生が、資本金1円でやっているとのことで、すごいの一言に尽きます。

※余談ですが、ローンチという言葉を初めて知りました。

　Web上で地図を扱う場合、(GoogleMapsのように)ベースとなる地図画像の上に、少量の図形を描画するという方法が一般的になってきています。
　具体的にどうやって図形をブラウザ上に表示しているかというと、ブラウザの種類に応じて様々な方法が試みられています。Firefox2では、SVGをサポートしているため、ラインやポリゴンはSVGに変換されてHTMLの中に埋め込まれています。IEではVMLという独自のベクトル描画の仕組みが使用されています。他にもHTMLとCSSを駆使して簡単な図形を描画したり、サーバサイドで画像を生成したりと、様々なテクニックがちりばめられています。出来る限り多くのブラウザで、出来る限り快適に地図を見るための工夫が随所が見ることができます。

GoogleMapsの中では単に図形描画のために使われているSVGですが、国内ではSVG自体を地理情報の標準フォーマットとして扱おうということになってきているようです。

地理情報システムにも「2.0」の流れ、“国産Google Maps”が実現するか!?

Google Maps上でのコンテンツ表示方法は、従来のGISからすると「非常にプア」なものになる。それまで築いてきたGIS資産をGoogle Maps上で提供すると情報量が低下してしまうことがあるとし、「Google Mapsだけで使えるデータにするのではなく、オープンスタンダードを採用したデータに移行していくことが重要だ」と訴えた。
...
国が提供するSVG地図と“マッシュアップ”したgコンテンツの流通が促進されることを狙い、まずはSVG電子地図ビューアを広く普及させたい考えだ。

「SVG Toolkitの開発」が財団法人日本情報処理開発協会事業で採択

　「SVG Toolkit」が想定するSVG電子地図表示ソフトウェアの動作形態は、現在デスクトップPC上でもっとも多く普及しているMicrosoft社製の Webブラウザ・ソフトウェアInternet Explorerのプラグインソフトウェアとして提供する予定です。また、Windows Vistaにも対応する予定です。

従来のGISと比べたら、GoogleMapsなんてしょぼ過ぎるので、なんとかして「大量のベクトルデータをオープンにWeb上で扱える仕組みを作りたい」ということなのでしょうか。SVG(XML)が交換・流通用フォーマットに適しているというのはよくわかります。
ですが、ブラウザでSVGを直接扱うというのはまた別の話です。
XMLをブラウザで直接扱うには、無駄が多く、あいまいな点が多いことがわかってきています。
無駄が多い点はJSONで解決され、あいまいな点は(GoogleMapAPIのような)ライブラリやフレームワークで吸収するという方法がとられています。

今回開発されるIEプラグインが、GoogleMaps並みにぐりぐり動いて、FirefoxのSVG対応等とも互換性を保ちつつ開発ができるようなものになってくれると大変うれしいです。

2007/3/5追記
ここギコさんの記事によると、開発中のSVGビューワは神速らしい！

IE7.0対応　神速のSVGビューワ見てまいりました

前のエントリーでGoogleMapsAPIにポリゴンの描画機能が追加されたことを書きましたが、そのパフォーマンスがどの程度なのか、こんなページを作って調べてみました。

GPolylineと同じく、IEは「VML」、Firefoxは「SVG」を使って描画しているようです。(それ以外はPNG生成？)ですので、性能のほとんどはクライアント側のPCに依存していると思います。
自分のPC(Athlon64 3000+)では、100個くらいで地図描画がもたつく感じになりました。
どちらかというと、IEの方が少し軽いようです。

このようなお絵かきをブラウザ上で行うなんて、少し前までは考えられなかったのですが、今では
dojo、Walter Zorn、OpenLayersなどのライブラリ内で、似たような機能が実現されています。

そういえば、電子国土の非ActiveX版がSVG対応だという噂を聞いたような気がしたので、
見に行ってみたのですが、自分がインストールしているブラウザ(IE7とFirefox2.0)では、まったく見れませんでした。
しかも「Microsoft Windows」のみしか対応しないとは、いったい何のための非アクティブX対応なんでしょうか？

Google Maps APIにポリゴンの描画機能が追加されました。
これまでは、独自に描画する方法を作りこむ必要がありましたが、
ついに公式の機能へ追加されました。

Googolgon, Anyone?

大量に描画した際のパフォーマンスが気になりますが、
うまく使えば表現力を格段に高めることができます。
これでまた一歩、GoogleMapsがWebGISへ近づいたように思います。

Japanese Address and Placename Support Added to the
Google Maps APIのジオコーディングが、ついに日本の住所に対応しました。
商用利用ができないとはいえ、地図会社との関係で実現は難しかろうと言われていたので大変驚いています。

これはこれで大変うれしいニュースではあるのですが、
ますます位置情報開発がGoogleに染まってしまいそうな危機感もあります。

日本版ジオコーディングに関しては、Geocoder.jaもがんばって欲しいです。

OpenLayersのバージョンが上がって、2.2になっていました。

WMSレイヤの投影法を、ベースとなるレイヤの投影法に合わせることができるようになっています。
これで何がうれしいかというと、GoogleMapsとWMSの重ね合わせが出来るようになります。→サンプル

他には、
・MapServerのCGIに対応。
・静的な画像を表示可能。
・オーバービューマップコントロールの追加→サンプル
などが追加されているようです。

詳しくはこちら。

Google Maps APIのあるバージョンから、Markerを追加するときにエラー「Bd(a, b, true).push is not a function」が発生するようになってしまいました。いろいろ試してみた結果、Object.prototypeに独自関数を追加している場合に発生することがわかりました。→再現ページ

いわゆる、Object汚染というやつです。
以前はPrototype.jsのオブジェクト汚染(現バージョンでは解決済み)がよく話題になっていましたが、jsonとricoがいまだに、この問題を抱えています。
というわけで、上記2つのライブラリとGoogle Maps APIを同時に使用している場合は注意が必要です。

バージョン指定をしないでGoogle Maps APIを使っていると、今回のようなケースでいつの間にかアプリケーションが動かなくなってしまうことがあります。

組み込みのオブジェクトを勝手に拡張しているライブラリの方が悪いのだとは思いますが...

※追記1
この問題はFirefox2.0で発生します。
IE7では発生しないようです。

※追記2
v2.64以降で発生するようです。→Bd(a, b, true).push is not a function

0.1、0.2と頼りないバージョン番号が続いていたka-mapでしたが、
いつの間にかバージョン1.0が公開されていました。
(まだベータはついていますが...)

サンプルアプリを見てみると、なんだか機能も充実してきていて、かなり良い感じです。
サーバサイドがMapServerに固定されてしまいますが、理由あってGoogleMapsを使えないプロジェクト(且つお金のないプロジェクト)では、今後かなりの活躍が期待されると思います。

PostLBSと組み合わせると、こんな事