geo Archive

OpenStreetMapへGPSログをアップするには、GPXという形式でないといけないらしいのですが、iPhoneアプリのOSMTrackを使うと、とっても簡単にOpenStreetMapへアップロードすることができます。
使い方はとっても簡単で、アプリを起動して「Start」ボタンを押すだけ

　記録を終了するには、画面下部の矢印をスライドさせます。
最後に「OSM」ボタンでOpenStreetMapへのアップロードが完了します。

　アップロードを行うには、あらかじめOpenStreetMapのアカウントを取っておく必要があります。 アップロード時にログの名称を設定できるのですが、ここで名称を入れないままアップロードすると、OSMのページに反映されない不具合があるようです。

　1１5円の有料アプリですが、非常に簡単に使えるのでなかなかおすすめです。

Google Mapsのマッシュアップでも有名なGOGAさんが、メッシュデータ表示システムの開発提供をはじめたようです。

　かつてスタンドアロンなGISな世界では、地図の上に重ねるものといえばメッシュデータだったような気がします。自分が学生時代に初めてGISを触ったときには、土地利用のメッシュデータを使っていたし、社会人になってから最初に作ったプログラムも、標高のメッシュデータを扱うものでした。

　いつしかGISの最前線がWebになってから、地図の上に重ねるデータといえば、こんな感じのピンが主流になっていました。
　メッシュをWebで扱いにくい理由はいろいろとあるのですが、一番大きいと思うのが、万人が見て意味のある表現をガチっと決めることが難しい点。
　スタンドアロンなGISの場合、メッシュデータを読み込んで、色区分の設定をあーでもないこーでもないと何度もいじることができるのですが、こういう計算機を目一杯使うようなやり方はWebには向かないわけですね。
　なので万人向けのWebサービスみたいなものは作りにくくて、先のGOGAさんのように個別なシステム開発になりがちなのかなと思ったりします。

　とはいえ、統計データを扱ったマーケティング分析みたいな分野のビジネスは、GISの黎明期から存在するわけですから、ある種の定石となるパターンみたいなものも、あるところでは確立していたりするのでは？
　その手のノウハウがある人なんかは、Web上での地理情報と統計情報をマッシュアップしたレポーティングサービスなんて立ち上げたりすると、クラウドなこれからの時代には需要があったりしないかなと思ったりするのです。

GeoRSSというのは、RSS/ATOMといったフィードに対して位置情報を追加することができる拡張仕様のことで、ブログなどの記事ごとに位置情報を関連づけて通知することができるようになります。
　すでに多くのサイトがGeoRSSに対応していますが、大きなところだとFlickrのGeoTag付き写真のRSS、ワイワイマップのRSS、GoogleマイマップのRSSなどがあげられます。
GeoRSSに対応しておくと、次のような良いことがあります。

1. 各種地図APIで、簡単に読み込むことができる
2. 各種地図サイト（ソフトウェア）上で読み込むことができる
3. Google Mapsの検索結果に表示されるかもしれない

1.と2.については、既にいろいろなブログで解説がされているので、そちらを参照していただければと思います。

• RSSに位置情報を格納できるGeoRSSをGoogle Maps APIがサポート - F.Ko-Jiの「一秒後は未来」
• Flickr GeoRSS + Google Maps - Tagchan's Blog
• MAKE: Japan: GeoRSSを使ったGoogleのMyMaps

今回は「3.Google Mapsの検索結果に表示される」について書いてみようと思います。
Googleは一般サイトのKMLやGeoRSSをクロールしていて、その情報はGoogle Mapsの検索結果に、↓こんな感じで表示されます。

この例では、Flickrやジオクリといったサイトの情報がユーザーコンテンツとして表示されているようです。

　サイトにGeoRSSやKMLを正しく設置しておくと、Web検索におけるSitemap.xmlと同じような効果を期待することができます。サイトに設置されたKMLやGeoRSSを、Googleがクロールしに来てくれて、Google Mapsの検索結果にコンテンツが表示されることを期待することができるようになるわけです。つまりはGoogle Maps向けのSEO対策ということになります。

地理情報コンテンツを Google へ送信する - KML - Google Code
Google Earth、Google マップ、またはモバイル Google マップに表示する KML コンテンツを作成したら、Google 検索でその KML ファイルが検索されるようにします。同様に、GeoRSS フィードを作成した場合も、Google 検索で目的のコンテンツが表示されるようにします。

　例えば六本木経済新聞というサイトでは、地図上にニュースを表示するページを持っていて、さらにRSSの中へ記事ごとの緯度経度を含めるというところまでやっているのですが、惜しいことにGeoRSSの形式になっていないのです。こいつをGeoRSS形式にしてあげれば、Google Maps内での検索結果や、各種マッシュアップサイトからの誘導が見込めるようになるというわけです。

　というわけで、RSSを吐いていて、コンテンツに緯度経度を持つような情報を持っているサイトは、今すぐにGeoRSSに対応しておくと良いことがあるかもしれません！

いまさらですがYahoo!Pipesをいじくりはじめて、いろいろと作り始めています。
前回のエントリーで触れた、六本木でランチなディレクターさんに触発されて、ワイワイマップから六本木でランチなスポットをぶっこ抜いてきて、GoogleMapsに表示してやるというのをやってみました。

できあがりはこんな感じです。。。

Google Mapsに貼付けるとこんな感じになります。。。

　
大きな地図で見る

作り方はこちら、、、

続きを読む

　自分の勤め先のディクレターでパーカーな人が、おもしろい罰ゲームをやらされてます。
「六本木 ランチ」というキーワードでSEOの順位をどこまであげられるかということらしいのですが、、、
　Google My Mapを貼付けたり、ワイワイマップのフィードを取り込もうとしていたりと、地域情報サイトを作る上でも面白げなことにチャレンジしてくれていたりします。プログラムを書けない人でもこれくらいのサイトなら作れる時代がもう来ているわけですね。。。

　cnetに、地方からの情報アウトプットが少ないという記事がありました。

情報こそが現代の通貨である:Going Local：地域ポータルとネット上の格差社会 - CNET Japan:
しかしながら、地域情報サイトを運営している私の立場から分析すると、ネット上において「地方」の情報は圧倒的に少なく、かつ良質のものも少ない、ということが言えると思います。

　上の企画で作られたような、六本木　ランチなWebサイトが、日本中で量産されるようになったら、地域間の情報格差にも違った未来が見えてくるのでしょうか？

SourceForge.JPに「誰でもできるOpenStreetMapへの貢献法」 という記事が上がっておりました。この記事によると、GPSを持っていなくても下記のような方法で、OSMへ貢献できるらしい。 　

1. 国などの他機関が整備した地図をインポートする（もしくはインポートされたデータを修正する
2. 他の人がアップしたGPSデータの編集作業をする
3. Yahoo!(US)の航空写真を背景にして、道路地図を描く
4. POI情報を追加する

1.は主要な道路や鉄道データなんかは、日本国内もこの方法でインポートされている？
２.はそれほど（すくなくとも自宅周辺には）GPSデータが上がっている気配がないです。
3.は日本国内の写真は道路地図を描くほどの精度がない
4.が一番敷居が低そうですが、下記のような制約があるようです。

POI情報は登録することが最終的な目的ではなく、あくまでナビゲーション用の目印なので、その登録にあたっては、ユーザを目的地に誘導する際に役立つであろう地図上で目立つ特徴的なオブジェクトを選ばなくてはならない。

けっきょくGPSがないと、楽しめそうにないです。

POIの制限を緩くしてあげて、地域の情報発信プラットフォームみたいに使えると良いかもと思いました。商店街の人とか、自分たちの商店街の地図を異様に詳しく作って、地域活性化につなげるとか。

それからGIS NEXTの今月号はOpenStreetMapの特集らしいです。この雑誌は通販のみなので、購入するのに敷居が高いのですが、普通の専門誌並みの値段でしっかりした作りの紙面なので、なかなかおすすめです。

一部の界隈でWMS(Web Map Service)が脚光を浴びているようです。
ことの発端は基盤地図情報25000 WMS配信サービスがリリースされたことによるのですが、これを歓迎するエントリーが次々とアップされています。

無料のGISソフトで閲覧するインターネット上の地図 - Tagchan's Blog
MAPconcierge Blog.: 基盤地図をWMS配信するサーバー
QGIS 1.0リリースと基盤地図情報WMS公開 - 横浜スローライフ -- My slow life in Yokohama

　その中で、岩崎さんのエントリーでは、新たなWMSサービスの開始を歓迎するとともに、WMSの問題点について言及しています。

WMSが普及しなかった理由？ - 日々是戯言・Geo出張版 一つは，大手さんが自分の所のソフト以外でも使えるということを，ちゃんといわなかった点。 ... もう一つは，「データはローカルにあるもの」というレガシーなGIS屋の迷信。

でこれに対して、自分のはてぶで

レガシーなGIS屋が受け付けなかったというのもあるにはあると思うけど、この方式だとサーバの負荷が高すぎて使い物にならないことが多いんですよね。

　と独り言を書いてたのですが、なんとこれに返信のエントリーをあげてくださいました。

WMSの話の続き - 日々是戯言・Geo出張版 これはデータを利用する側にとっては，端的に「遅い」ということになるのですが，データを提供する側にとっても，私のようにTomcat+GeoServerで動かしていたりすると，サーバーがいつ落ちるかとビクビクしなくてはいけないので，悩みの種の一つです。

で、ほとんど問題点は指摘されてしまったのですが、自分はWMSをWebサイトで活用したい人なので、その視点からの補足をしてみたいと思います。
と思ったのですが、すでに自分が問題と思っていた点について、的確な指摘がされているエントリーがあったので、そちらを引用させていただきます。

モデル重視・実装軽視であった地理情報技術業界のこれからについて - Geographic/Photogrammetric/Cartographic

Google Maps の立ち上げ当時の成功は、OGC WMS を結果的に完全に黙殺し、運用に適したタイルベース・リソース指向の設計を貫徹させることによって、他社サービスにはない運用スピードを実現させたところにも要因があると思っています。

結局のところWMSって、旧来のインターネット地図サービスの仕様に引きづられていただけのような気もします。で、タイルベースのスクロール地図っていう新しい手法をGoogleが編み出したもんだから、一気に時代遅れになってしまったのだと思います。でも地図の見せ方ってそれだけじゃないよね？と思ったら、同じ方がこんなエントリもあげていました。

今、 Web 絡みの地理情報技術者に必要だと私が思っている技術 - Geographic/Photogrammetric/Cartographic

「OGC WMS の問題点」は、そのうち常識となり、WMS は 電子国土, Google Maps, Google Earth, ka-Map, OpenLayers など（つまり、一般ユーザに提供されている地図サービス）が提供している「タイルマッピングサービス」の層の後ろに回ることになるのでしょう*1。また、受け渡されるデータは、必要な所では、画像データからだんだんベクトルデータ（SVG なり WFS でいう GML なり）にもなっていくと思います。

　このエントリ書かれてるの、丸１年以上前なんですねー。SVGのタイリング配信は一部のビューワーでは実装されてるみたいだし、Google Mapsなんかもベクトルタイリングに移行していくかもしれないです。

　ただ、タイリングにも問題点があって、世界中をGoogleMaps並みの縮尺でタイル画像を用意しようとすると、数百テラ単位でディスクが必要だったり、世界中が一枚でつながる投影法を採用せざるをえなかったり、レイヤを選べなかったり、レンダリングが固定されてしまったり、とGISな人には許しがたいような制約もいろいろとあったりするので、WMSにも生き残る道はちゃんとあるような気がしています。

　GMLがKMLに乗っ取られてしまった今、OGCの規約でまともに使われているのって、これくらいですよね？

　ロカポの上田さんより、なんともユニークなジオコーダAPIが発表されました。

ロカポ ブログ: 京都通り名ジオコーダーAPI『ジオどす』を公開しました。
これまでほとんどの地図サイトで検索できなかった、京都市内独特の住所表記「○○通○○東入ル」等の住所からおよその緯度経度を取得する京都通り名ジオコーダ『ジオどす』を公開しました。

　京都で使われている特殊な住所表記、通称「京都の通り名」。他の地域に住んでいるとなかなか馴染みがないのですが、要するに京都では、一カ所の地点に対して複数の呼び方（住所）が存在するようなのです。

京都の通り名について | 『ジオどす』　京都通り名ジオコーダーAPI
京都の通り名表記は動きを基にした一種のナビゲーションであって、「そのとおりに動けばとおりのどちら側かに見つかる」というもので、一点を表すものではありません。
ある程度の範囲は特定できますが、厳密な位置の指定は不可能です。

　APIのインタフェースを、GoogleとYahoo!に合わせてしまったというのも、なんとも潔いマッシュアッパーらしい発想です。

ジオどすAPIの仕様と使い方 | 『ジオどす』　京都通り名ジオコーダーAPI グーグルマップスAPI（JavaScript ）をお使いの方に朗報。ジオコーダの宣言部分を一箇所変更するだけで、GClientGeocoder.getLatLng()関数が京都対応に！

３．Yahoo!ローカルサーチ・プロキシ「ジオ櫛Ｙどす」
Yahoo!ローカルサーチAPIと全く同じインプット･アウトプット仕様です。京都市の住所かつ「ジオどす」で検出できた場合は、ヤフー・ローカルサーチの結果の先頭アイテムにとして「ジオどす」のデータを挿入します。既存のマッシュアップアプリを1行変更するだけ！URLドメインのみ要変更

　開発裏話がおもしろいです。相当な苦労をして、データ集め、ロジックの検証をされているようですね。

開発裏話 | 『ジオどす』　京都通り名ジオコーダーAPI

　開発にはジオコーダー界の重鎮であるジオセンス小林さんが関わられているようです。通り名データにはこちらのものが使われているのかも？

京都通り名マップ

そもそも日本の住所体系をもう少し考え直した方がよいんじゃないかと思ったりもしますが、Web上でますます便利に地図を扱うことができるようになるのは喜ばしいことです。

OpenStreetMapをGoogleMaps上に表示するMappletを作ってみました。

下記のリンクをクリックすると、GoogleMapsへOSMのMappletを追加できます。

http://maps.google.com/ig/add?synd=mpl&pid=mpl&moduleurl=http://convivial-web.net/mapplet/osm.xml

Mapplet本体のURLはこちらです。
http://convivial-web.net/mapplet/osm.xml

Mapplet版のGTileLayerがAPI版と微妙に仕様が違ったりして少し戸惑いましたが、OSMのURL仕様がGoogleとまったく同じになっていたので簡単に実装できました。
逆にいままで無かった方が意外な気がします。

　マイクロソフトのLive Search Mapsに日本の斜め写真が追加されました。
英語では、Bird's Eye、日本語のメニューでは外観図と表示されています。

MSの「Live Search Maps」に東京の斜め視点航空写真など追加

　外観図という呼び方はいまいちピンとこない気もしますが、斜め写真の特性をうまく表現しているとも言えます。
　真上から撮影された航空写真や、地上から撮影されたStreet Viewと比べて、斜め写真は街の表情を把握しやすいという特徴があります。
　Street Viewは道路上から撮影しているため、どうしても表示できる視点や範囲が限られてしまいます。そのため画面上で表示できる範囲は、意外と建物の一部分だけだったりしてしまうのです。
　一方の垂直写真では、建物の屋上しか見えないため、地上で見る建物の姿とは全く異なったものであることが多いです。
　斜め写真であれば、建物の側面を見ることができ、建物の色や高さを把握することもできるのです。

　マイクロソフトのLive Search MapsはVirtual Earthというエンジンをもとに作られていて、このVirtual EarthはSDKも公開されているので、マッシュアップすることが可能です。

Virtual Earth Interactive SDK

　StreetViewとVirtual Earthをマッシュアップすると、Dual Mapsという究極の地図サービスができてしまいます。

こんな感じで埋め込むこともできるようです。

今回はOSGeoとの合同開催で、OFF4G^2 (オフフォージージジョウ)と呼ぶそうです。

ジオメディア忘年会2008 - シリウスラボ

場所はこちら

詳しい地図で見る

OpenLayersというキーワードで、このブログへやってくる人が急増中です。

先日のFOSS4Gで、講演やハンズオンセッションがあったのでその影響だと思います。
ちなみにOpenLayersの開発者で、先日のFOSS4Gで講演もされていたChristopher Schmidt氏は、なかなか良いキャラのようです。

24歳。マシンガンのようにしゃべるヤツ - 横浜スローライフ

自分のブログのOpenLayersの記事はどれも古いものばかりなので、 久々に使ってみて、また記事も書いてみようと思います。

　FOSS4G 2008 TOKYO というフリー&オープンなGISのイベントに行ってきました。
なんとなく、ジオメディアサミットの規模がイメージにあったため、それよりは人がまばらな印象でしたが、しばらく追っかけていない間にオープンソースGISは確実に進化していて、特にKMLやGoogle Maps等のタイル画像へ対応したソリューションが続々と出てきているのが印象的でした。

　そして今回一番の目当てであったOpenStreetMapのことをいろいろとお聞きできたのは、とても収穫でした。「自分たちの街のことは、自分たちが一番よく知っている、だから自分たちの街の地図は自分たちで作る」というテーマは、最近の地域系ソーシャルサービスにもつながるところがあるなぁと思ったり。
　自転車でGPSを背負ってデータを取ってくる話だとか、登山道とか整備できたら楽しいよね、みたいな話が出ていたので、matoyanさんのところのサイトのユーザーと、いろいろと一緒にできたら良いのかなと思ったり！？。

　農業環境技術研究所の岩崎さんからは、歴史的農業環境閲覧システムの迅速測図公開までの裏話的な話がありました。自分が勝手に懸念していたパフォーマンスの点もちゃんと考慮がされていて（しかもかなりの苦労をされて！）公開にこぎ着けたようで素晴らしかったです。
研究機関などでは、研究成果としてこういった地理データがいっぱい眠っているらしく、自分も以前から思っていはいるのですが、なんとかこういったデータをもっとわかりやすく、一般の人たちの目に触れるところで公開できるようにできないかなぁと思ったりしています。

　他にも、ポストマップの人がgogaの人になってたり、懇親会のライトニングトークで学生たちの活動がやたらと熱かったり、ジオメディアサミット忘年会の開催が決定？していたりと、 とても楽しいイベントでありました。

Googleから、Gears API というブラウザをオフラインで使用するための拡張機能が提供されています。その中の一つに、Geolocation APIという機能が用意されています。
このGeolocation API を使うと、GPS、WI-FI、IPアドレスといった情報から、ブラウザ利用者の位置を取得することができるようになります。

端末にGearsがインストールされている必要がありますが、位置取得のためのコードは、JavaScriptを使ってシンプルに書くことができます。

var geo = google.gears.factory.create('beta.geolocation');
geo.getCurrentPosition( function(pos) {
  alert('lat:' + pos.latitude + ',lon:' + pos.longitude);
});

一方Firefoxには、「Geode」という似たような機能をもつアドオンが提供されています。
こちらはWI-FIからの位置情報のみですが、JavaScriptを使って同じように記述することができます。

navigator.geolocation.getCurrentPosition(function(pos) {
  alert( pos.latitude + ", " + pos.longitude );
})

よーくみてもらうとわかるのですが、Geodeの位置情報取得コードは、GearsのGeolocationAPIとまったく同じ名称のオブジェクトとメソッドが使われています。

これはどういうことかというと、実はGeolocation API自体が、W3Cによって策定が進められているオープンな仕様なのです。
-Geolocation API Specification

さらにいうと、W3CのGeolocation API Specification策定には、GoogleのGeolocation API開発者が大きく関わっているようなのです。
このGeolocation API SpecificationはHTMLの次バージョンであるHTML5で標準化される方向に進んでいるようです。
※追記　GeolocationとHTML5は別物だとコメントをいただきました。

Gearsについては、Database APIとHTML5の「Client-side DB」が対応していたりと、HTML5のテクノロジープレビュー的な意味合いも持っているのかもしれません。

今のところは一部ブラウザのアドオン機能でしかないGeolocation APIではありますが、HTML5に採用されるようになると、ブラウザが標準で機能を提供するようになりますので、一気に広まることが期待されます。

特にiPhoneのSafariでは、HTML5のローカルキャッシュをすでに実装しているという流れもあり、HTML5準拠のGeolocation APIを実装してくることは、ほぼ間違いないように思います。

今までは、
携帯電話のGPSから位置情報の取得をキャリア別に実装したり、
PlaceEngineを使ってWI-FIから位置情報を特定したり、
IPアドレスから位置情報を割り出すデータベースを利用したり
様々な位置情報取得技術を個別で実装する必要がありました。
今後はこういった作業から開発者が解放され、位置情報を活用したサービスがますます増えていくことが期待されるのであります。

Googleの携帯プラットフォームAndroidでもSekai Camera のようなアプリが発表されたみたいです。
 Augmented reality on Android already available!

　フリー＆オープンソースGISの祭典、FOSS4G 2008が東京と大阪で開催されます。
- FOSS4G 2008 Tokyo
- FOSS4G 2008 OSAKA

　今回はオープンストリートマップジャパンとジオメディアサミット運営実行委員会が協賛となっていて、OSAKAの方ではジオメディアサミット関西の枠も設けられるようです。Googleからの発表もあるようで、プレイヤーは揃ったといった感があります。

　基調講演はそれぞれ、MapServer、PgRouting、OpenLayersという主要オープンソースプロダクトの関係者が務めるようです。これらのプロダクトのメンバーが来日するのでしょうか、ハンズオンセッションでは開発に携わっているメンバーから直接指導を受けられるようです。ハンズオンセッションは有料ですが、１セッション5千円からというのは、かなりお手ごろに思えます。

　OSGEO系は最近あまり追っていなかったのですが、ちょっとまたこちらの世界にも手を出していこうかと思っていたりします。

※ページ下のポスターには笑わせられましたｗ

東京会場はこちら
詳しい地図で見る

Sekai Camera というiPhone用のサービスが話題になっています。

- TC50―Sekai CameraはiPhoneからソーシャルタグで現実世界の情報を提供
- 【世界カメラ】iPhoneを電脳メガネにする「Sekai Camera」がすごい件【セカイカメラ】

これを見て直感的に思ったことは、旧来のGISエンジニアに「活躍のチャンス」があるのではないかということです。

　iPhone用のサービスといってもコンセプトが発表されただけのようで、実際にサービスが開始されているわけではありません。
　このサービスを実現しようとすると、かなり高精度な位置測地技術が必要になりそうなのですが、このあたりに何かブレイクスルーがあったのかどうかが気になるところです。

　これまでWeb系のサービスで位置情報が使用されるとき、旧来のGISやジオマティクスな分野ほどの精度を要求されることはほとんどありませんでした。むしろ精度のことを忘れて、その上のレイヤで勝負することがポイントでした。

iPhoneのようなデバイスが誕生し、Sekai Cameraのようなコンセプトが出てきたことは大変興味深く、位置情報の精度に関して少し違ったトレンドへ向かっていく可能性が出てきました。

この分野のブレイクスルーに関して、GISやジオマティクスのエンジニアに出来ることがいろいろあるような気がします。

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

※追記
いつのまにか、東京もOSMになっている！
http://www.flickr.com/map?&fLat=35.6656&fLon=139.7546&zl=8

出る出るとは言われていましたが、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という言葉が流行ったりして、ベンダーやアプリ、プラットフォームに縛られずに位置情報を流通すべきだよねっていう考え方が主流になりつつありました。その結果、様々な団体によってたくさんの位置情報フォーマットが生まれてきました。
　そんな位置情報フォーマットたちを懐かしがりながら、私見を交えて紹介してみたいと思います。

続きを読む

これはGoogle版のOpen Street Mapでは？と思えるようなサービスが始まりました。

「Google Map Maker」公開、Wiki的手法で地図を編集

一部の国が対象で日本は対象外のようですが、書き込んだ内容が即座に反映され、モデレート機能でふるいにかけられた一部データについては、Google Map 本体へも反映されるようです。

対象国のひとつであるベトナムで見比べてみましたが、けっこうデータ投入されてますね。

-Google Maps

-Google Map Maker

少し試してみましたが、ベースがGoogle Mapなだけあって、基本的な編集作業は快適にできるようになっています。道路同士が重なった場合などの簡単なエラー処理も実装されているようです。

衛星写真を背景にして、道路データなどはどんどん描かれていくのでしょう。

こういった「皆さんどうぞ投稿してください」的なサービスを、Googleはまだ成功させていなかったと思います。果たして今回のこの試みはうまくいくのでしょうか。

もはや今さらですが、7月に発売されるiPhoneにはGPSが搭載されるらしいです。
Wi-Fiとの組み合わせで最強の位置情報端末になることは間違いありません。
加速度センサーも組み合わせるとおもしろそうです。

この端末から何か新しいことが生まれるのは、もはや決定的です。
どれくらい普及するのか、どんなサービスが出てくるのか、今から楽しみでなりません。

個人的には、スーパーボーナスの残り期間をどうするべきか、、、

確かに自分も意外に思いました。これもメルカトル症候群のひとつでしょうか。
-「台湾」と「九州」の面積はほぼ同じ

子供のころから世界地図といえばメルカトル図法。
Webの地図といえばメルカトル図法。
このいっけん常識と思えるところにヒントがあるような気がしてならない。

ラクチンでいいんですけどね、メルカトル。
横メルカトルはめんどくさいけど。
最初に地域（座標系）を選択していたあの頃には、もう戻れないのです。

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

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

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

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

　もう一つのポイントは、FOSS4Gと呼ばれるオープンソースの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が使えるのかもしれません。

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

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

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

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と組み合わせると、こんな事も出来てしまう見たいです。

OpenLayersというJavaScriptのライブラリが大変良くできています。

・WMS
・WFS
・GoogleMaps
・YahooMaps
・KaMaps
などに対して、共通のインタフェースでアプリケーション構築することができます。
その分、機能的にはまだ基本的なものしか用意されていませんが、
JavaScriptのライブラリとしては、珍しく?きれいな設計になっているので今後も期待が持てそうです。

しかし、やっぱり最強はGoogleMaps+WMSのような気が...

OGCが策定している「WMS(Web Map Service)」に準拠したサービスが徐々に公開されてきています。

ジオグラフィネットワークジャパンで検索を行うと、結構使えそうなWMSサービスが見つかります。

Google MapsとWMSの連携(Google Maps + WMS）はすでに有名ですが、JavaScriptでWMSのみを扱えるライブラリがあると便利かなと思っていたら、もうすでにありました。　

• quickWMS


• WMS JavaScript Library