Convivial-Web

WEBを共に愉しむ。

2ページ目 (12ページ中)

位置情報を含むRSS/ATOMを吐くサイトは、いますぐGeoRSSに対応すべき

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

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

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

今回は「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に対応しておくと良いことがあるかもしれません!

ワイワイマップのスポットをPipesでまとめてGoogleMapsに出力する

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

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

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

 
大きな地図で見る

作り方はこちら、、、

続きを読む

地域情報サイトは質より量が大事?

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

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

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

OpenStreetMapに参加するにはGPSが無くても良いらしい

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

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

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

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

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

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

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

WMS(Web Map Service)はまだまだこれからかもね

一部の界隈で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 なり)にもなっていくと思います。

 このエントリ書かれてるの、丸1年以上前なんですねー。SVGのタイリング配信は一部のビューワーでは実装されてるみたいだし、Google Mapsなんかもベクトルタイリングに移行していくかもしれないです。
 ただ、タイリングにも問題点があって、世界中をGoogleMaps並みの縮尺でタイル画像を用意しようとすると、数百テラ単位でディスクが必要だったり、世界中が一枚でつながる投影法を採用せざるをえなかったり、レイヤを選べなかったり、レンダリングが固定されてしまったり、とGISな人には許しがたいような制約もいろいろとあったりするので、WMSにも生き残る道はちゃんとあるような気がしています。
 GMLがKMLに乗っ取られてしまった今、OGCの規約でまともに使われているのって、これくらいですよね?

京都通り名を検索できるジオコーダーAPI「ジオどす」

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

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

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

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

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

ジオどすAPIの仕様と使い方 | 『ジオどす』 京都通り名ジオコーダーAPI
グーグルマップスAPI(JavaScript )をお使いの方に朗報。ジオコーダの宣言部分を一箇所変更するだけで、GClientGeocoder.getLatLng()関数が京都対応に!
3.Yahoo!ローカルサーチ・プロキシ「ジオ櫛Yどす」
Yahoo!ローカルサーチAPIと全く同じインプット・アウトプット仕様です。京都市の住所かつ「ジオどす」で検出できた場合は、ヤフー・ローカルサーチの結果の先頭アイテムにとして「ジオどす」のデータを挿入します。既存のマッシュアップアプリを1行変更するだけ!URLドメインのみ要変更

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

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

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

京都通り名マップ

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

OpenStreetMapを表示するMappletを作った

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-osm-1.jpg
mapplet-osm-2.jpg
Mapplet版のGTileLayerがAPI版と微妙に仕様が違ったりして少し戸惑いましたが、OSMのURL仕様がGoogleとまったく同じになっていたので簡単に実装できました。
逆にいままで無かった方が意外な気がします。

2008年のまとめと2009年に向けて

 昨年中は大変お世話になりました。今年もよろしくお願いいたします。

 今の会社での立ち振る舞いもだいぶわかってきて、この世界でどういったことができるのか、どうすれば実現できるのか、なんとなくわかってきた気がします。
 Webの世界でどっぷりやってみようという、最初の目標はいちおうクリアできたかなと思います。
 その一方でやるべきことが膨大にあることもわかってきて、昨年の後半から年末にかけては不完全燃焼感が漂っていたのも事実。

 今年はどこまで行けるかわかりませんが、着実にひとつずづ片付けていきます。

Google Friend Connectに対応してみました。

 このブログにGoogle Friend Connectのガジェットを追加してみました。
右下の窓からJoinして、このサイトの読者同士でつながることができるようになります。

 設置方法ですが、ウィザードに従って、
・認証用のファイルをアップロード 
・生成されたJavaScriptコードを貼付ける
だけでOKです。
解説は、マイコミジャーナルの記事が参考になりました。

 こういうJavaScript+Htmlだけで機能提供できるガジェット方式は、簡単お手軽で良いですね。いままではWebAPIをプログラムから叩いてマッシュアップする形式が主流でしたが、今後はこういうアプローチが増えてくるんですかね。

 FacebookもFacebook Connectという似たような機能を提供しているので、そのうち試してみようと思います。そういえば、Yahoo!も ログールという似たような、、、、

Google Native ClientはActiveXの再来か?

Webブラウザ上でネイティブなプログラムを実行する「Native Client」という技術が、Googleから発表されました。

Webにたいして、こういうアプローチができるGoogleという会社は素直にすごいなあと思います。
いままでも、Flashについては渋々使っていることを公言していましたが、こういう回答を用意していたわけですね。
ローカルリソースへのアクセスはかなり厳しくなるんでしょうが、そのぶんGoogleのクラウドを存分に使えるんでしょうね。きっと。。。

« Older posts Newer posts »

© 2024 Convivial-Web

Theme by Anders Noren上へ ↑