WEBを共に愉しむ。
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.と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に対応しておくと良いことがあるかもしれません！
自分の勤め先のディクレターでパーカーな人が、おもしろい罰ゲームをやらされてます。
「六本木 ランチ」というキーワードでSEOの順位をどこまであげられるかということらしいのですが、、、
Google My Mapを貼付けたり、ワイワイマップのフィードを取り込もうとしていたりと、地域情報サイトを作る上でも面白げなことにチャレンジしてくれていたりします。プログラムを書けない人でもこれくらいのサイトなら作れる時代がもう来ているわけですね。。。
cnetに、地方からの情報アウトプットが少ないという記事がありました。
情報こそが現代の通貨である:Going Local：地域ポータルとネット上の格差社会 – CNET Japan:
しかしながら、地域情報サイトを運営している私の立場から分析すると、ネット上において「地方」の情報は圧倒的に少なく、かつ良質のものも少ない、ということが言えると思います。
上の企画で作られたような、六本木 ランチなWebサイトが、日本中で量産されるようになったら、地域間の情報格差にも違った未来が見えてくるのでしょうか？
SourceForge.JPに「誰でもできるOpenStreetMapへの貢献法」 という記事が上がっておりました。この記事によると、GPSを持っていなくても下記のような方法で、OSMへ貢献できるらしい。
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ドメインのみ要変更
開発裏話がおもしろいです。相当な苦労をして、データ集め、ロジックの検証をされているようですね。
開発にはジオコーダー界の重鎮であるジオセンス小林さんが関わられているようです。通り名データにはこちらのものが使われているのかも？
そもそも日本の住所体系をもう少し考え直した方がよいんじゃないかと思ったりもしますが、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、日本語のメニューでは外観図と表示されています。
外観図という呼び方はいまいちピンとこない気もしますが、斜め写真の特性をうまく表現しているとも言えます。
真上から撮影された航空写真や、地上から撮影されたStreet Viewと比べて、斜め写真は街の表情を把握しやすいという特徴があります。
Street Viewは道路上から撮影しているため、どうしても表示できる視点や範囲が限られてしまいます。そのため画面上で表示できる範囲は、意外と建物の一部分だけだったりしてしまうのです。
一方の垂直写真では、建物の屋上しか見えないため、地上で見る建物の姿とは全く異なったものであることが多いです。
斜め写真であれば、建物の側面を見ることができ、建物の色や高さを把握することもできるのです。
マイクロソフトのLive Search MapsはVirtual Earthというエンジンをもとに作られていて、このVirtual EarthはSDKも公開されているので、マッシュアップすることが可能です。
StreetViewとVirtual Earthをマッシュアップすると、Dual Mapsという究極の地図サービスができてしまいます。
こんな感じで埋め込むこともできるようです。
© 2024 Convivial-Web
Theme by Anders Noren — 上へ ↑
最近のコメント