地図 Archive

最新の写真測量技術を使って、建物の３次元モデルを参加型で作成する試みがGoogleからはじまったので試してみた。豆腐のような壁面が無い３次元モデルではなく、壁面付きの３次元モデルが簡単に作成できる。

Googleビルディングメーカーでは、斜め写真などの大量の航空写真（空中写真）を使い、その写真から建物の3次元構造（輪郭線）がどのようになっているのかを、マウスを使って教えてあげるだけである。これらの航空写真を撮影したカメラは、どこでどの向きで撮影したのかは撮影時点で計測しているので、複数の写真で、特定の建物がどういう輪郭線であるのかをインプットすることで、建物の輪郭線が現実世界の３次元地理座標と対応をとることが可能となる。それによって、３次元モデルが作成可能となる。

以下が、建物の輪郭線が写真でどのように表現されているのかを示している様子である。直方体だけでなく、屋根のような形状との組み合わせも可能である。

このシステムでは、６枚から８枚くらいの航空写真を利用しているが、写真の枚数が多くなればなるほど、その３次元モデルの位置や高さの情報の誤差が少なくなる（もちろん、ユーザ次第で精度は変わるが、致命的なミスは減る）。また、斜め写真ということで、建物壁面の画像を切り出して、３次元モデルに貼り付けることが可能となる点が大きい。通常の地図作成の場合は、2枚の写真による立体視なので、壁面が写っていない場合も多いが、斜め写真を使うことで、その問題は解決する。

以下が、完成した３次元モデルである。かなりいい加減に作ったが、それっぽい表現になっていることがわかる。

斜め写真を複数撮影し、写真測量を行う技術としては、アメリカのピクトメトリー社という航空測量会社が国際航業と提携したことが知られている（リンク）。Googleがこの企業の技術を用いたかどうかは不明だが、この方法と大差無いだろう。

これにより、コストと時間をかけて正確な３次元モデルを作るアプローチ（従来型）と、質は劣るが大量にそれっぽい３次元モデルをユーザが作るアプローチ（参加型）の２種類によって３次元モデルが作成可能となったわけである。２つのアプローチを併用しつつ、広範囲で３次元の地球がサイバースペースで再現できるように、うまく進めて欲しいものである。

日本全国の地震動マップを推定して結果を公開するシステム「地震動マップ即時推定システム（QuiQuake: Quick estimation system for earthQuake map triggered by observed records）」が公開された。（個人的に）注目すべきは、WMSで配信していることである。専門家が配信するこのような地理空間情報を、WMS配信することで、複数のソフトウェアによってユーザが動的に表示して、他のデータと重ね合わせることが可能となる。

ウェブサイトの概要によると、データの種類は2つあり、震動による最大地動速度（PGV: Peak Ground Velocity）と計測震度がある。また、データはGeotiffでも公開している。データは、KMLで公開されているが、KMLからWMSを使ってGoogle Earthで表示することが可能である。しかし、WMSはGoogle Earthのみで閲覧するわけではないので、WMSのURLを調べてみた。

2009年10月18日時点でこのサービスで最新の地震のKMLをダウンロードしてみる。KMLをテキストエディタで開くと50行目に以下のようなURLがある。

http://carteb.geogrid.org/mapserv/qqm?LAYERS=PGV_20091011101200&TRANSPARENT=true&FORMAT=image%2Fpng%3B%20mode%3D24bit&SRS=EPSG%3A4326&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&WIDTH=1024&HEIGHT=1024&

「LAYERS=PGV_20091011101200」が、データのIDにあたり、2009年10月11日10時12分の地震ということをあらわす。この長いURLがWMSのURLであり、Quantum GISでも表示可能である。以前のブログで紹介した方法で、Quantum GISで表示してみた。凡例はこちら。

2つのマップを並べたが、同じエリアを切り出したものである。左側はGeography Network JapanでWMS配信している数値地図25000である。場所は、根室半島付近である。震源は、これより南東にあるのだが、必ずしも震源からの距離によって揺れが大きくなるわけではなく、地形によって変化する。地形から判断すると、湿地と推測される箇所が揺れやすくなっている。このように、地形による地震動の違いも判別できるデータである。ただし、WMSではPGVは見ることができたた、計測震度のデータは公開されていなかった。ぜひとも計測震度もWMSで配信して欲しいと思う。

上記のURLは、個別の地震だった。次に、リストから地震を選ぶようにしてみよう。以下のWMSのURLを入れて見る。

http://carteb.geogrid.org/mapserv/qqm?

すると、現時点で1996年以降の4992個の地震の地図がリスト表示されて、選ぶことができるようになっている。日付で選べるようになっており、大きな地震の日付と時間を調べておけば、その地震の地震動のマップが表示できる。以下のマップは、2009年8月11日早朝の最大震度6弱の地震の最大地動速度マップである。

自分の住んでいる地域と他の地域の最大地動速度を比較してみると、自分の住んでいる場所の揺れやすさが見えてくるかもしれない。

GDALのプログラム群のひとつである、gdalwarpを使うと、ラスター型（メッシュ）のGISデータの接合が簡単にできるので自分へのメモを兼ねて紹介したい。

国土地理院の基盤地図情報やASTER GDEMなどで公開されている地盤高データ（Digital Elevation Model; DEM）は、タイル状に分割されて公開されている。そのため、境界部を対象にする場合や、広域な利用を考える場合は、データを接合する必要がある。

基盤地図情報については、以前のエントリでラスター型GISデータへ変換できることを紹介した。先日公開がはじまったASTER GDEMはGeotiff形式のラスター型GISデータとして公開されている。これらのデータは、GDALのgdalwarpを使うことで、簡単に接合処理ができてしまう。

gdalwarp ファイル1 ファイル2 出力ファイル

ファイル1とファイル2をつなぎ合わせたものが出力ファイルに保存される。大量のファイルの場合は、アスタリスク"*"を使いワイルドカードによって大量のファイルを指定することができれば、大量のタイル状のファイルを接合することができる。つまり、

gdalwarp ワイルドカード付きのファイル 出力ファイル

とすることで、大量のタイルを接合することが可能となる。

今回、基盤地図情報の10mのDEMを以前エントリの方法でラスター型GISデータへ変換し、gdalwarpで接合した。以下に接合後のファイルを示した。

新しいGoogleストリートビューの新機能にパンケーキというものがある。これは、マウスカーソルが道路上では円なのだが、建物の壁面では、壁面の存在や向きを考慮したカーソルの形状となる。これは、ストリートビューが3次元空間を認識していることに他ならない。高度な処理を施している可能性があり、今後この技術と3次元情報が面白いことに活かされる可能性もある。

パンケーキについての説明は、以下が参考になる。

Google「ストリートビュー」で素早い移動が可能に (Internet Watch)

今回導入されたスマートナビゲーション機能では、マウスカーソルを画面の道路部分に乗せると、円盤状の図形が表示される。Googleではこれを"パンケーキ"と呼んでいる。パンケーキを自分の進みたい場所に動かし、そこでダブルクリックすると、即座にその場所にジャンプできる。パンケーキは道路のかなり先の方まで表示されるため、瞬時に移動できるようになった。

　さらに、道路の両側などにある建物にマウスカーソルを動かすと、パンケーキは四角形に変わる。そこをダブルクリックすると、建物の壁面をちょうど見やすいように表示してくれる。

実際に試してみた。道路上などの平面では円のマウスカーソルである。そして、建物にマウスカーソルを移動してみた。

建物壁面の向きを考慮して、マウスカーソルの形状が四角になって傾いている。そして、壁面の向きが変わると、それも考慮したマウスカーソルの形状となる。従って、道路に面した壁面とその側面となる壁面の位置と向きを認識していることがわかる。

これの意味するところは、Googleストリートビューの2次元画像から、3次元空間を関連付けることを可能にしているということであり、Googleストリートビューは3次元空間を認識しているということである。どうやっているのだろうか。おそらく、写真から3次元空間を構成させていると考えられる。

ストリートビューでは連続して写真撮影しており、複数の写真による立体視が可能であり、技術的には3次元空間を構成させることは不可能ではない。ただし、写真の枚数は膨大である。そのため、自動処理を行って2次元の画像を3次元として構成するための処理を行っていると推測される。様々な箇所でパンケーキを試してみたが、電線の部分で壁面と認識するミスがあったり、マウスカーソルの形状が変わる場所がずれている場合があった。これは自動処理を行っていることを示している。マシンビジョンや写真測量の分野では、写真を3次元計測する技術があり、Googleのエンジニアにそのような技術を持っている人がいてもおかしくない。

この技術の今後の展開としては、Google Earthの建物の3次元形状の壁面にこのストリートビューの撮影した写真が利用できる可能性がある。車の位置とカメラの向きが分かっているので、建物形状の3次元のデータがあれば、ストリートビューで撮影して、建物壁面の部分を抽出し、建物形状の3次元データと関連付けることができれば、墓石のような建物の3次元形状データの壁面に窓や壁面の色を入れることが可能となる。

これまでのエントリーでは、Quantum GISを使って地図画像に位置情報を与え、Google Earthに表示させた。今回は応用編として、自然災害の被害範囲を地図化したハザードマップを重ねてみることにしよう。

ハザードマップは市町村ごとに公開している。もちろん、作っていない場合や公開していない場合もある。まず、お住まいの市町村のホームページに公開されているか確認してみよう。私は現在、流山市南流山駅あたりに住んでいるので、流山市で探してみたところ、洪水ハザードマップが公開されていることがわかった。

流山市洪水ハザードマップ
http://www.city.nagareyama.chiba.jp/section/kasen/hazardmap/index.html

PDFで公開されている場合が多く、今までの方法を行う場合は、画像化する必要がある。Irfanviewでは、プラグインをインストールするとPDFを画像ファイルとして保存できる。

保存した画像をこれまで紹介してきた方法で位置情報を与える。問題はどの投影法なのかという点だが、建物の区画が明確に含まれているので、1/2500都市計画図であると判断し、世界測地系第9系とした。イメージオーバーレイまで完成した写真を以下に示す。

濃い青色は、江戸川が氾濫した場合に数メートル浸水する可能性があると記載されている。ちなみに、南流山駅は2.5mから5mが浸水可能性があるとのこと。そうなると、江戸川を渡って地下に入るつくばエクスプレスは、水没して不通になることは容易に想像できる。次に、少し拡大してみよう。

地形を強調表示している。黄色のあたりは0.5m以下か、浸水しないと予想されている。その場所は、地形がやや高まっていることがわかる。このように、地形と予想される被害の対応関係も理解することができる。

ハザードマップは役所のウェブサイトで公開されている場合が多い。自分の住んでいる場所はどのような自然災害が起こりうるのか、調べてみるのも良いだろう。今回は、洪水ハザードマップとしてが、地震に関するハザードマップも公開されている場合があるので、同じ方法で重ねてみても良いだろう。そうすることで、自分がどれくらい自然災害による被害を受けるリスクがあるのか、想像できるのではないだろうか。

さらに重要なのが、ハザードマップを用いて自分がどのようにこのような自然災害リスクを回避するべきか、ということを考えることである。今回のような洪水の場合は、被害が小さいと予想される場所はなぜそのようになっているのかを、Google Earthの3次元表現によって明確に理解できたわけだが、それによって江戸川が氾濫した場合に逃げる場所を容易に想定することができるようになる。さらに、避難所などの災害時に役に立ちそうな情報が地図上にレイヤーとしてプロットされていれば、避難のための想定が容易にできるようになるだろう。

こういうハザードマップが、Google Earthとかウェブ上の地図で容易に表示できるような仕組ができれば、防災にも少しは役に立つうだろうと思うのである。

だいぶ前のエントリーになってしまったが、Quantum GISを使って、画像に位置情報を与え、それを投影変換する方法を紹介した。今回は、投影変換した地図画像をGoogle Earthに重ねてみたい。

前提として、地図画像が等緯度経度に変換されている必要がある（前回までのエントリ参照）。前回、25000分の１地形図を等緯度経度の投影法に変換したので、これをそのまま利用する。まずは、この投影変換した画像の情報を見てみよう、gdalinfoコマンドを以下のように実行する。

gdalinfo <前回出力した等緯度経度の画像ファイル>

すると、以下のように出力される。

もう少し文字列が続くが、この文字列のCorner Coordinatesが重要なのである。Upper Left、Lower Left、Upper Right、Lower Rightの値が、地図画像の四隅の緯度経度をあらわしている。この情報が重要となる。以下はUpper Leftを示す。

Upper Left ( 139.8638810, 35.9339586) (139d51'49.97"E, 35d56'2.25"N)

Upper Leftは左上ということであり、 ( 139.8638810, 35.9339586)は経度、緯度の１０進数表示であり、 (139d51'49.97"E, 35d56'2.25"N)は経度、緯度の度分秒表示となっている。

次にGoogle Earthにうつる。上記出力画像は、JPEGにした方が良い。TIFFやPNGはうまく表示されないことがあったので。さて、Google Earthを起動し、追加>イメージオーバーレイを選ぶ。そして、リンクの部分でJPEG画像を選ぶようにする。そして場所タブをクリックしする。そうすると、東西南北それぞれに緯度または経度が入力できるようになる。

表示に沿って、北にはgdalinfoで表示させたUpper LeftまたはUpper Rightの緯度を入れる。ここで注意すべきことは、度分秒表記で入力することである。gdalinfoでは、度分秒表記を35d56'2.25"Nとしているが、Google Earthは35°56'2.25"Nとしている。違いがお分かりだろうか。これは、度にあたるdと°が違うのだ。なので、Google Earthに入力した後に、すぐにdを°に変換してやる必要があるのだ。そして、南はLower LeftまたはLower Rightの緯度を入力する。西にはLower LeftまたはUpper Leftの経度を入力し、東にはLower RightまたはUpper Rightの経度を入力する。そしてOKをクリックすると、Google Earth上には、航空写真とぴったりと重なるように、地図がオーバーレイできているはずである。

次は応用編ということで、ハザードマップのオーバーレイを行ってみたいと思う。

自分の行ってきた研究を，多くの人に平易な言葉で説明できるようにしたいと考えている。それは，研究成果の社会還元のために重要だと考えたからである。つい最近出版された自分の論文を紹介したいと思う。

1. やったことを一文で説明すると・・・

「これまで撮りためてきた航空写真（空中写真）を使って，過去40年間の森林の変化や成長が再現できることが明らかになった。」

2. 航空写真（空中写真）について

航空写真は，地図作りの目的のために，日本全国を戦後から定期的（森林域ではほぼ5年おき）に撮影してきた。そのため，航空写真は膨大な枚数の蓄積がある。この蓄積を生かすことできれば，新しい情報を生み出せる可能性がある。このような視点で航空写真を使うことはほとんどなかった。

3. 航空写真を使って立体視

航空写真は，先ほど書いたように地図作成を目的として撮影されている。そのため，等高線が必要であり，地形のデコボコを把握するために立体視ができるように撮影される。立体視とは，写真のような2次元の画像を複数枚使うことで，物を3次元（立体的）に見る方法である。そのため，同じ地点でも複数の航空写真で写るように撮影されている。

4. 樹木の凸凹の変化だけ抽出

森林や山の中を撮影した航空写真を使って立体視をすると，どんな凹凸が見えるだろうか。それは，「地形＋樹木」の凹凸である。樹木は，成長すると上に高くなっていく。つまり，同じ森林で，40年前に撮影された航空写真の凹凸と，最近撮影された航空写真の凹凸を比較すれば，地形の凹凸が変化していないとするならば，樹木の成長による凹凸の違い，要するに樹木が高くなっていくことが把握できるはずだ。



5. 樹木の凹凸を抽出

航空写真から，地図作成のために立体視をしてきたが，人の手によって行われてきた。しかし，これでは時間がかかる。最近では，コンピュータの発達や，この分野の発展により，半自動的に凹凸が抽出できる技術が確立しつつある。そのため，この技術を使って，8時期約40年間の航空写真を50枚以上使い，8時期の凹凸を抽出した。そして，地形の凹凸である地盤高のデータを使って，樹木の凹凸のみを抽出した。この樹高の凹凸の時系列変化を観察することで，森林の変化が把握できるのかを調べてみた。

6. どんな結果が得られたか？

最新の航空写真については，最新の測量技術であるレーザ測量の凹凸と比較して，樹木の凹凸は樹木の高さが十分に抽出できていることが確認された。

そして，8時期の樹木の凹凸を観察したところ，樹木の成長が把握できた。また，樹種や地形による成長の違いが把握できた。他にも，伐採されたところや，植林された所が把握できたり，倒れた被害の発生したところが，凹凸で表現されていた。

以下に樹木の凹凸を地図化したマップを示す。黒いほど樹木の高さが低く，白いほど高いことを示している。1960年代や1970年代は，南側は黒っぽいことがわかる。ちょうどこの頃に，植林が活発に行われ，その後は順調に成長していることがわかる。



7. どんないいことがあるの？

樹木の凹凸として樹木の高さが分かれば，林業を行っている森林では，木材の体積を知ることが重要であるが，これを時間変化として知ることができる。これまでも，森林のこのような情報を自治体が把握してきたが，精度に問題があるという指摘があった。そのため，航空写真を使えば，人間の調査が行けなかった場所でも，今回抽出できた情報を使うことで，精度を高められる可能性がある。また，伐採とか植林の確認もでき，倒木箇所の把握もできるので，森林管理の効率化に貢献できることが期待できる。

また，バイオマスや貯蔵されている炭素の量が分かるようになる。そして，時間変化がわかるので，その情報を使って，森林の将来の森林の予測を行うこともできる。そうなれば，温室効果気体である二酸化炭素の吸収量の予測や，炭素の貯蔵量の予測も高精度に行える可能性がある。

8. 掲載論文

田口仁，遠藤貴宏，古川邦明，沢田治雄，安岡善文，(2009)「多時期の空中写真から作成したDigital Canopy Modelによる森林キャノピーのモニタリング」写真測量とリモートセンシング, Vol. 48, No. 1, pp. 4-11.

というわけで，自分の研究成果を分かりやすく説明することを試みた。正直なところ，どんな書き方が良いのか模索している段階である。今後，いろいろと研究成果を発表していくと思うので，試行錯誤しながら，行ってきた研究を誰もが理解できる形で紹介できるようにしていきたいと思っている。

前回のエントリでは，Quantum GISを使って地図画像に地理座標を与えた。地理座標が定義できているので，地図投影法は自由に変えることが可能となる。今回は，希望の投影法に変換する手順を説明したい。

GDALは，ラスター（画像のようなメッシュ）形式のGISデータを処理するライブラリである。Linuxだけでなく，Windowsでも動作する。Windowsへのインストールは，まずOSGeo4Wで，OSGeo4W Installerをダウンロードし，実行させる。そして，GDALのみをチェックするとインストールできる。スタート > すべてのプログラム > OSGeo4W > OSGeo4W Shellを選択すると，コマンドプロンプトが出てきて，このプロンプトを通してGDALのライブラリが実行できる。コマンドプロンプトの使いかたについては，こちらのサイトが参考になりそうだ。

前回のエントリで行った，地理座標を与えた画像データがあるフォルダへ移動する。そして，前回の画像ファイルだが，Quantum GISによって座標はインプットされているのだが，投影法が画像ファイル自身には埋め込まれていないことが判明した。これは，gdalinfoコマンドで確認することができた。

gdalinfo <入力ファイル名>

投影法が定義されている場合には，投影法に関する記述が出てくるのだが，無いのである。なので，まずこれを定義することからはじめよう。定義するには，gdal_translateコマンドを使う。このコマンドは，画像の形式を変換することも可能な便利なコマンドである。

投影法の定義するためには，いろいろなパラメータが必要だが，コードで記述する方法が採用されている。それが，EPSGコードである。座標系と投影法の組み合わせで一つのEPSGコードが決まっている。なお，国内のEPSGコードについては，こちらのサイトで一覧が示されている。また，Google Earthと同じ，等緯度経度(Plate Caree)の場合のEPSGは4326，Google MapsはSpherical MercatorでEPSGが900913(または3785)である。

前回のエントリで扱った地図投影のEPSGコードはどうやって調べればよいかというと，前回のエントリの一つ目の画像が参考になる。WMSレイヤーを表示させるときに，基盤地図情報25000では，複数の投影法で表示させることが可能なことを記述したが，そこにEPSGのコードが出ている。それによると，25000分の1地形図の投影法はUTM図法のゾーン54の北側だったため，EPSGコードは3100である。それをgdal_translateでは以下のようにコマンドする。

gdal_translate -a_srs "EPSG:3100" <入力ファイル名> <出力ファイル名>

出力ファイルはtifとすると，Geotiffとなるため，今回は全て拡張子はtifで統一する。出力ファイルをgdalinfoコマンドで表示させると，ちゃんと投影法が定義されていることが分かるはずである。これで，投影変換を行う準備が整った。投影変換のコマンドは以下のようになる。

gdalwarp -t_srs "EPSG:xxxx" <入力ファイル名> <出力ファイル名>

-t_srs "EPSG:xxxx"のxxxxは変換先のEPSGコードである。なお，等緯度経度の場合はxxxxは4326となる。

実は，先ほどgdal_translateで元の画像のEPSGを定義したが，一気に変換することも可能である。その場合，EPSG:3100からEPSG:4326への変換となり，コマンドは以下のようになる。

gdalwarp -s_srs "EPSG:3100" -t_srs "EPSG:4326" <入力ファイル名> <出力ファイル名>

"-s_srs"の後のEPSGが，入力ファイル名のEPSGコードである。s_srsとt_srsのsとtの違いは，sourceとtargetの違いである。それでは，出力されたファイルを比較してみよう。まずは，EPSG:3100(UTM/54N/JGD2000)である。

次がEPSG:4326である。

等緯度経度(Plate Caree)であるため，ゆがみが大きくなる。そのため，等緯度経度である下の画像の方が，横に伸びたような画像となっているのが分かる。

以上で，Quantum GISで地図画像に地理座標を与え，GDALで任意の投影変換を行う流れまでできたことになる。せっかくなので，次のエントリでは，等緯度経度に投影変換した地図画像をGoogle Earthでぴったりと重ねることができることを示したいと思う。

前回は，地図画像に地理情報を与えるコンセプトを説明した。今回は実際にQuautumGISを用いて地理情報を与える方法を説明する。今回，例としてスキャンした25000分の1地形図（図葉名：流山）を使うことにする。

25000分の1地形図は，前のエントリで示したように，地図投影法はUTM図法(横メルカトル図法)である。なお，地形図の右側の凡例などが記載されている所の説明には，「ユニバーサル横メルカトル図法，座標体は第54帯，中央子午線は東経141°」と記されている。そのため，リファレンスに使用する地図もその投影法に合わせる必要がある。

以前のエントリで，WMSサーバを紹介したが，基盤地図情報25000は非常に便利である。なぜなら，多種多様な投影法に対応しているからである。では，次からは実際の手順の説明に移る。

QuantumGISを起動して，基盤地図情報25000のWMSレイヤを表示させる。方法については，基盤地図情報25000のサイトで詳しく紹介されている。ただ，ここで必要なプロセスがあり，「Add Layer(s) from a Server」ウィンドウの下にある，「Coordinate Reference System」のChangeをクリックする必要がある。表示されたウィンドウでは，以下のようなウィンドウが表示され，投影法を選択することができる。

上の図の通り，「UTM zone 54N」を選択する。そして，OKをクリックし，前のウィンドウに戻ってAddをクリックすると，地理情報を与えたい地形図と同じ投影法で基盤地図情報25000が表示される。

次に，メニューで プラグイン>Georeferencerを選択する。すると，「地理参照」というウィンドウが表示されるので，「...」を選択して，使用する地図画像のファイルを選択する。すると，「地理参照」と同時に表示されていた別のウィンドウである「Reference Points」ウィンドウに，地図画像の縮小版が表示される。なお，「地理参照」ウィンドウの「Arrange Plugin Window」をクリックすると，ウィンドウの配置が最適化される。なお，「地理参照」ウィンドウは消さないでほしい。

そして，基盤地図情報25000の方を，地形図のエリアにあわせるように移動させる。実はこれが結構難しいが，Google Mapsなども駆使して，なんとかエリアを特定しなければならない。それができれば，次に地形図と基盤地図情報25000の一致する対応点を設定していくことになる。以下にReference Pointsウィンドウを示す。

「Reference Points」ウィンドウの上側の左の4つのアイコンは，左から，拡大，縮小，全体表示，パンである。これを駆使して，地形図の画像を拡大させる。そしてあわせて，基盤地図情報25000も拡大させて，一致する箇所を見つけていく。以下の図は，地形図と基盤地図情報25000で，位置が同じと推測される箇所である（元は同じデータなので，見え方は似ている）。一致している地点の対応点を画像にクリックすることで特定する。

まず，Reference Pointsウィンドウの上にあるアイコンの右から2番目のアイコンをクリックする。そして，ウィンドウ内の一致している箇所として特定する点をクリックする。すると，以下のようなウィンドウが表示される。

このウィンドウの左下の「from map canvas」をクリックする。そして，マウスポインターが「＋」となり，基盤地図情報25000において，地形図で一致した点を慎重に特定し，クリックする。すると，XとYに地理座標がインプットされる。そして，了解をクリックすると，Reference Pointsウィンドウ内の地図に，点が与えられたことが示される。これを，あと4回ほど繰り返す。間違えた場合は，一番右のReference Pointsウィンドウのアイコンの一番右をクリックし，ウィンドウ内の消したい点をクリックすることで消すことができる。

対応点が4つか5つほどできたら，Reference Pointsウィンドウに戻り，「変形種別」を「ヘルマート」とし，「修正されたラスタ」として，補正後の画像ファイルの出力先を設定する。「世界ファイル」はそれによって自動的に設定される。なお，出力はGeotiff形式のみである。そして，「Create and Load Layer」をクリックする。その後，2つのウィンドウが出てくるが，両者とも了解でよい。

しばらく処理が行われる。たまにプログラムが落ちるが，処理が完成してから落ちることが多いようだ。処理が終了したら，「地理参照」ウィンドウを閉じると，Reference Pointsウィンドウも消える。そして，Add Raster Layerで，生成された画像ファイルを選択して表示させてみよう。基盤地図情報25000と重なることが確認できるはずである。

今回は，最新の地図どうしだったため，比較的容易に対応点が取れた。しかし，古地図となると，容易ではなくなる。その辺は，経験と慣れが必要な部分だろう。また，ソフトウェア自体が不安定な場合もあり，ソフトウェアが落ちることもたまにある。それは仕方が無いので，根気強くやってほしい。また，対応点は近場で固めるのではなく，地形図の4隅付近で対応点がちらばるようにすることが望ましい。

これで，地図画像に地理情報が与えることができたが，地理情報が定義できたということは，投影法の変換も自由自在に可能となることを意味する。次のエントリでは，GDALを使って，投影変換を行う方法を紹介しようと思う。

アナログでしか存在しない地図をデジタル化し，他のGISや地図と重ねられたら便利なことも多いだろう。では，それをどのように実現すれば良いのか？今回は，数回に分けてこれまで何度か紹介してきたQuantumGISを使って，デジタル化された地図画像に位置情報を与える方法を説明したい（世界地図よりは国内の地図を中心としています）。

まず調べておく必要があることは，どの地図投影法なのか，という点である。手書きで完全にオリジナルな地図であれば，残念ながら重ならない。もし，行政機関が出したような「ちゃんとした」地図が基となっていれば，投影法が定義された地図のはずであり，地理情報を与えることが可能だ。ちなみに，行政機関等の地図の投影法は以下のように決まっている。

ESRIジャパン株式会社 GISとは？ - 投影法について

もっともポピュラーな1/25000地形図は，UTM図法(横メルカトル図法)で投影されている。UTM図法については，日本地図センターのサイトの説明が詳しい。また，1/2500や1/5000などの大縮尺の地図の場合は，平面直角座標系による横メルカトル図法となる。この投影法についても，さきほどのサイトが詳しい。

地理情報を与えたい地図画像の投影法が分かったとして，次にどうやって地図画像を「地理情報付き地図画像」とすれば良いか。それは，画像上のある点が，どの地理座標に対応するのかを教えてあげれば良い。そのような点を複数（だいたい4点以上）を与えることができれば，他の画素の地理座標が推定できるようになる。

QuantumGISでは，このようなことができる。そのプラグインとして，Georeferencerという機能が付いている。このプラグインでは，先ほど述べた，画像上の点と地理座標を対応させて，画像に地理情報を与え，「地理情報付き地図画像」を作成する機能が付いている。

では，どの情報を参考に地理座標を取得すればよいだろうか。そこで，WMSが利用できる。WMSを利用することで，自前でGISデータや地図を用意しなくても良い。そのため，地図画像がデジタル化されており，インターネットに接続されていれば，地図画像を「地理情報付き地図画像」へ簡単に変換できる。

QuantumGISでの具体的な方法については，次のエントリで紹介したいと思う。

最近のエントリでは，Web Mapping Service (WMS)に注目してきた。国内を中心に代表的なWMSをリストアップしていきたい。なお，Quantum GISでのWMSの使い方は，こちらのサイトが参考になる。下記のWMSのURLを，Quantum GISのURLに入力することになる。

1. 基盤地図情報25000

• 配信元：独立行政法人農業・食品産業技術総合研究機構 近畿中国四国農業研究センター
• 縮尺： 1/25000
• サイトのURL
  http://refits.cgk.affrc.go.jp/tsrv/jpmap/kibansrv/index.html
  http://refits.cgk.affrc.go.jp/tsrv/jpmap/kibansrv/srvinfo.html
• WMSのURL
  http://refits.cgk.affrc.go.jp/tsrv/jpmap/kibansrv/kiban25000wms.cgi?
• 投影法
  等緯度経度(Geographic) 測地系：JGD2000(世界測地系), WGS84, Tokyo(旧測地系)
  UTMゾーン51～55 測地系：JGD2000, WGS84, Tokyo
  平面直角座標系第1～19系 測地系：JGD2000, Tokyo
  
• 備考
  必要な情報はこちらにまとめられている。地理空間情報活用推進基本法により，登場したデータ。縮尺1/25000の地図として基本的なデータである。

2. 地すべり地形分布図データベース

• 配信元：独立行政法人防災科学技術研究所
• 縮尺： 1/50000
• サイトのURL
  http://lsweb1.ess.bosai.go.jp/jisuberi/jisuberi_mini/index.asp
• WMSのURL
  http://lsweb1.ess.bosai.go.jp/wmsconnector/com.esri.wms.Esrimap?
• 凡例
  http://lsweb1.ess.bosai.go.jp/lsweb_jp_new/gis/Legend.htm
• 投影法
  等緯度経度(Geographic) 測地系：WGS84
• 備考
  縮尺1/25000の地形図の等高線が表示されるため，地形がわかる。崖や土砂が移動したところが表示される。断層関係はうまく表示されてないようだ。

3. オルソ化空中写真ダウンロードシステム

• 配信元：国土交通省国土計画局
• 写真の縮尺： 1/8000～1/15000
  
• サイトのURL
  http://orthophoto.mlit.go.jp/
• WMSのURL
  http://orthophoto.mlit.go.jp:8888/wms/service/wmsRasterTileMap?
• 投影法
  等緯度経度(Geographic) 測地系：JGD2000
• 備考
地図に投影された空中写真（オルソ化空中写真）である。詳しい説明は以前のエントリに書いた。

4. OnEarth, JPL WMS Server

• 配信元：NASA/JPL
• サイトのURL
  http://onearth.jpl.nasa.gov/
• WMSのURL
  http://wms.jpl.nasa.gov/wms.cgi
• 投影法
  等緯度経度(Geographic) 測地系：WGS84
• 備考
  NASAが打ち上げた衛星画像がたくさん収録されている。解像度はかなり粗く，マニアックなものも多い。大陸~全球スケールの画像であれば，IDが91がおすすめ。市町村一個程度のスケールであれば，IDが2，5，10がおすすめ。

5. 国土地理院数値地図50mメッシュ（標高）

• 配信元：Geography Network Japan (ESRIジャパン)
• サイトのURL
  http://www.geographynetwork.ne.jp/
• WMSのURL
  http://www.geographynetwork.ne.jp/ogc/wms?ServiceName=50m_mesh_wms
• 投影法
  等緯度経度(Geographic) 測地系：WGS84
• 備考
  縮尺が1/25000の地形図の等高線を用いて50m四方のメッシュの平均値を計算したデータ。標高によって色分けされており，陰影図もある。

6. 国土地理院空間データ基盤25000

• 配信元：Geography Network Japan (ESRIジャパン)
• 縮尺： 1/25000
• サイトのURL
  http://www.geographynetwork.ne.jp/
• WMSのURL
  http://www.geographynetwork.ne.jp/ogc/wms?ServiceName=basemap_wms
• 投影法
  等緯度経度(Geographic) 測地系：WGS84
• 備考
  上記の基盤地図情報が出る以前から発行されている数値地図である。基盤地図情報よりは，表示されるレイヤーは多いようだ。ID1と2をチェックしないで表示すると良い。

7. ESRI World Vegetation

• 配信元：Geography Network Japan (ESRIジャパン)
• 縮尺： 1:15000000
• サイトのURL
  http://www.geographynetwork.ne.jp/
• WMSのURL
  http://www.geographynetwork.com/servlet/com.esri.wms.Esrimap?ServiceName=ESRI_Veg&
• 投影法
  等緯度経度(Geographic) 測地系：WGS84
• 備考
  世界スケールの植生分布図。凡例が良くわからない。

8. World Temperature Zones (Annual)

• 配信元：Geography Network Japan (ESRIジャパン)
• 縮尺： 1:15000000
• サイトのURL
  http://www.geographynetwork.ne.jp/
• WMSのURL
  http://www.geographynetwork.com/servlet/com.esri.wms.Esrimap?ServiceName=ESRI_Temp_Yr&
• 投影法
  等緯度経度(Geographic) 測地系：WGS84
• 備考
  世界スケールの温度帯分布図。凡例が良くわからない。

9. World Precipitation Zones

• 配信元：Geography Network Japan (ESRIジャパン)
• 縮尺： 1:15000000
• サイトのURL
  http://www.geographynetwork.ne.jp/
• WMSのURL
  http://www.geographynetwork.com/servlet/com.esri.wms.Esrimap?ServiceName=ESRI_Precip_Yr&
• 投影法
  等緯度経度(Geographic) 測地系：WGS84
• 備考
  世界スケールの降水量のクラスの分布図。凡例が良くわからない。

10. Digital Chart of the World

• 配信元：Demis
• 縮尺： 1:1000000
• サイトのURL
  http://www2.demis.nl/mapserver/mapper.asp
• WMSのURL
  http://www2.demis.nl/mapserver/wms.asp?
• 投影法
  等緯度経度(Geographic) 測地系：WGS84
• 備考
  世界のベクター型データベース。元サイトはこちら。今後は更新の見込みが無いので，使わないほうが良いかもしれない。

11. World Basemap

• 配信元：Geography Network Japan (ESRIジャパン)
• 縮尺： 1:1000000
• サイトのURL
  http://www.geographynetwork.ne.jp/
• WMSのURL
  http://www.geographynetwork.com/servlet/com.esri.wms.Esrimap?ServiceName=ESRI_World&
• 投影法
  等緯度経度(Geographic) 測地系：WGS84
• 備考
  ESRIが出しているベースマップ。ただ，東京を拡大すると微妙な感じでした。

海外のサイトで，いくつかWMSのリンク集を発見した。とても検索がしづらいが，掘り出し物がみつかるかも。

• geopole.org
  http://www.geopole.org/wms
• WMS Sites
  http://wms-sites.com/
• OGC WMS Server List / Skylab Mobilesystems Ltd.
  http://www.skylab-mobilesystems.com/en/wms_serverlist.html

良いサイトやサービスを発見したら，教えていただけると助かります。

このエントリーでは，基盤地図情報の地形データをGISソフト等で解析できる形に変換し，無料のGISソフトで表示する方法を紹介する。

基盤地図情報について

基盤地図情報とは，国や地方公共団体が整備したデジタル化された地理情報である（詳細）。　なお，国は基盤地図情報を無償でインターネット上で公開することが法律で定められている。ただし，使用には著作権者の許可が必要である（国土地理院の地図についてはこちら）。

今回は特に地形データ（DEM）に注目してみたい。5mメッシュ（正方形のメッシュで，一辺の長さが5mという意味）の地形データは2008年3月から公開されており，範囲を広げてきている。また，10mメッシュについては，2008年10月に四国が整備されて公開され，2009年2月1日からは全国が整備されてダウンロード可能となった。国土地理院が発行している，全国で整備された地形データは50mメッシュしかなかったため，10mとなったことで大幅に解像度が向上した。

5mおよび10mメッシュの地形データは，今後は研究用途でも利用が広がる可能性がある。そこで，公開されいているデータ形式から，プログラムによってGISソフトで読み込みやすい形に変換することを試み，無料のGISソフトであるQuantum GISで表示させてみることにした。

プログラムについて

作成したプログラムはCygwin上で開発して動作確認を行っており，LinuxまたはCygwin上で動くプログラムである（Macでも動く？）。Cプログラムを含むため，Cygwinを使う場合はgccがインストールされている必要がある。Cygwinのインストール方法はウェブ上にたくさんあるので参照されたい。変換プログラムはこちらである。zipファイルを解凍するとフォルダが出てくるので，フォルダごと実行するディレクトリへ移動する。

地形データのダウンロード

今回は10mメッシュの地形データをダウンロードしよう。基盤地図情報のダウンロードサイトへ移動し，「JPGIS 2.0 (GML) 形式」をクリックする。そして画面が切り替わり，ページ下部の「10mメッシュ（標高）」の右にある「地図から選択」をクリックする。そのページの説明に従って，必要なメッシュの箇所を選択し，ダウンロードして解凍する。すると，xml形式のテキストデータが出てくる。そのファイルを，先ほどのプログラムを解凍した時に出てきたフォルダへ移動する。なお，同じ別の箇所を選択してDLして解凍したxmlファイルであれば，先ほどのフォルダへ移動すると，バッチ処理で変換を行うことが可能である。

プログラム実行

データのダウンロード，解凍，移動が完了したら，プログラムのフォルダへ移動し，dem.cshを実行する（一応，Cプログラムのexeファイルはあるが，コンパイルした方が良いかもしれない）。最初にメッシュサイズが10mか5mか聞かれるが，「10m」を入力すると，処理がxmlファイルがある分だけ繰り返し実行される。

このGML形式のファイルは，タイル状になっており，データの格納順番は，北西からx軸の正方向（西→東の順）へ進み，東端に達すると、y軸の負方向（北→南の順）に進み，南東端に至るという順序であり，それがテキストで記載されている。なお，このデータは等緯度経度の投影法である。これをその順番のとおりに浮動小数点(Float)のバイナリデータに変換していく。それを，今回のようなラスタデータの変換が容易なGDALというプログラムで読み込めるように，位置情報を付加しれたヘッダーファイルを生成している（厳密にはENVIフォーマットにしている）。

なお，このプログラムは個々のxmlファイルで変換を行うことが可能である。しかし，データどうしを接合（モザイク）をすることはできない。GDALでは，gdal_merge.pyでできるらしい。

【2009年2月14日追記】
どうやら，gdalwarpでもできるようです。

Quantum GISの表示方法

処理が完了すると，個々のファイルには「ファイル名.bin」と「ファイル名.bin.hdr」という拡張子が付いたファイルができ，これらは本体とヘッダーファイルとなっておりセットとして扱う。これでQuantum GISで読み込むことが可能となる。

Quantum GISを起動し，ラスターレイヤーを追加を選択し，ファイルの種類を一番したの項目を選択し，.binのファイルを選択すると，Quantum GIS上に表示されるはずである。

表示結果例

Quantum GISで表示した例を紹介する。なお，カラーマップは「原色」にして表示した。また，地形データは接合を行っている。

全体的な地形表現は同じである。なお，同じデータ内の色の違いには意味があるが，2つのデータ間の色に違いは意味がないので注意が必要である。2つのデータの地形の表現を観察すると，詳細さがまったく異なっているのが分かる。

以前に紹介したWMSのレイヤーを重ねてみよう。基盤地図情報25000のレイヤーを重ねてみた。なお，オルソ空中写真も容易に重ねることができた。

地形データの作成方法について

10m地形データの作成方法はメタデータでの表記で以下のように示されている。25000分の1地形図の等高線からメッシュデータに変換したデータである。

作成方法（全国の2万5千分1地形図の等高線データ等から不規則三角網(以下、「TIN」という。)を作成して、地表を緯度経度ともに0.4秒(約10ｍ)間隔で区切った方眼（メッシュ）の中心点の標高を記録した。）

http://fgd.gsi.go.jp/metadata/fmdid0-5.xml

一方，5m地形データの作成方法はメタデータでの表記で以下のように示されている。こちらは，空中写真やレーザ測量から直接作成したデータである。

この標高データは、地表を５ｍ間隔で区切った方眼（メッシュ）中心点の標高を、航空レーザスキャナ測量によって取得したデータをもとに、家屋や橋、樹木等を取り除いた地表面データとして作成した高精度な数値標高モデル（DEM)です。

http://fgd.gsi.go.jp/metadata/fmdid0-6.xml

この標高データは、地表0.2秒間隔で区切った方眼（メッシュ）中心点の標高を、写真測量によって取得したデータをもとに、家屋や橋、樹木を取り除いた地表面データとして作成したものです。なお、一部山地等の森林部については表層面データとなっています。

http://fgd.gsi.go.jp/metadata/fmdid0-7.xml

10m地形データは，人によって引かれた等高線から作成しており，1ステップ介していることになる。等高線を作成した時点で詳細な地形表現は削ぎ落とされている。一方，5m地形データは，直接作成している（半自動）ので，空間解像度も高いことも要因だが，より詳細な地形が表現できる。また，空中写真とレーザ測量では，レーザ測量のほうが詳細な地形が表現できる。

Google Earth 5.0がリリースされた。一番の目玉がGoogle Oceanといわれるように，海底地形や海に関するコンテンツが充実したことである。その辺は，多くの方々が取り上げるだろうから，このエントリーでは特に言及しない。私が注目したいのが，過去の航空写真や衛星写真が表示される機能が搭載されたことである。

過去のデータに注目してきた私としては，今回の機能に注目している。これまでの過去の地図や航空写真関連のエントリは以下のとおりである。
明治時代の「迅速測図」がウェブで公開
goo地図に昭和38年の空中写真が登場
Yahoo! Japanによる昭和30年代の地図の閲覧サービス
横浜市の1/3000地形図がkmlで公開

さて，実際に見てみることにする。Google Earth 5.0をインストールして起動すると，メニューアイコンのところに，時計のようなアイコンがある。そこをクリックすると，スライダが登場し，過去の航空写真や衛星写真が切り替え可能となる。

試しに，東京23区で表示してみよう。
まずは，1997年から。23区内は高解像度なものに整備されている。周囲の画像は，解像度が粗い衛星画像であると考えられ，未整備と解釈できる。

2002年。新しいデータがある部分は，新しい画像に更新されている。

2005年。表示範囲の全域は，高解像度の画像となっている。

2007年。画像の色が変わっている部分があり，更新されているところがあることが分かる。

次に，ミッドタウンを拡大してみよう。以前は防衛庁本庁舎檜町庁舎だった。そこを更地にし，建築されていく様子がわかる。なお，以下の画像の日付は，Google Earthの左下に表示されていたものである。年までしか表示されていないものは空中写真，月日まで表示されているものは衛星写真だろうか。

地図や衛星写真は最新のデータであるという暗黙の了解があるが，データの新鮮さを意識できる意味で，時系列を意識させるこの機能は重要である。今回のようなな航空写真や衛星写真だけでなく，あらゆる地図や位置情報が，過去にさかのぼることが可能な形で公開されることを希望したい。

前回のエントリでは，Quantum GISを用いて基盤地図情報25000を表示するところまで行った。今回は，別のWMSの地図を表示することを試みたい。なお，前回のエントリの方法で表示したJGD2000の投影法で，新宿副都心付近を表示したところから説明を進めることにする。

使用する地図は，いわゆる地図ではなく航空写真である。つまり，写真地図である。業界では空中写真と呼んでいる。今回，国土交通省のオルソ化空中写真ダウンロードシステムを使用する。このサービスでは，空中写真の地図をWMSで配信するサービスである。「オルソ」の意味は，地図と重なる形で，空中写真が幾何的な補正がされた写真のことである（正射投影されたということ）。これからは，このような写真地図をオルソ空中写真と呼ぶことにする。

このサービスのサイト上でも，オルソ空中写真を見ることが可能だが，Quantum GISを使用すると，他のGISデータと重ねることができるため，今後有用となる可能性がある。

このサービスの提供範囲は，こちらに示されている。昭和50年前後は広域にカバーされているが，そのほかの年代は，残念ながら都心のみに限られている。今後拡大するかもしれない。

Quantum GISのメニューにて，「レイヤ > Add WMS Layerを」選択する。「Add Layer(s) from a Server」というウィンドウが表示される。そして，Server Connectionsの中の「新規」ボタンをクリックする。そして，出てくるウィンドウに以下のように入力する。

• 名称　オルソ空中写真
• URL http://orthophoto.mlit.go.jp:8888/wms/service/wmsRasterTileMap?

「Add Layer(s) from a Server」に戻るので，Server Connectionsの上側の項目を，「オルソ空中写真」とする。そして，「Connect」をクリックする。すると，以下に示すような表示になる。

「レイヤ」のところに，4つのリストが表示されるのがわかるだろう。これは，提供範囲で示したオルソ空中写真の撮影時期に対応している。ID，名称は次のように対応している。

• ID: 1 ORTHO → 第１期（昭和49年～昭和53年）撮影分
• ID: 2 ORTHO01 → 第２期（昭和54年～昭和58年）撮影分
• ID: 3 ORTHO02 → 第３期（昭和59年～昭和61年）撮影分
• ID: 4 ORTHO03 → 第４期（昭和62年～平成 2年）撮影分

リストのうち，ID1だけクリックして，色を反転させてみよう。そして，「Add」をクリックすると，WMSの画像がダウンロードされ，オルソ空中写真がオーバーレイされる。これによって，第1期のオルソ空中写真が表示された。

上記画面の左側には，表示されたデータの項目が示されている。そこにある「オルソ空中写真」の左の「×」をクリックし，チェックをはずしてみよう。すると，先ほどの基盤地図25000が表示される。そして，また同じ「×」をクリックすると，オルソ空中写真が表示される。つまり，これは基盤地図25000の上に，オルソ空中写真が重なって表示されているのだ。そして，この左側のデータの項目は，上ほど優先的に表示されるのである。

表示を何度か切り替えてみると，基盤地図とオルソ空中写真がほぼぴったり重なっていることがわかる。昭和50年代は，新宿副都心の高層ビル群は，まだ立てられていないビルがあることが見て分かり，興味深い。

先ほどの左側の項目のところにある，「オルソ空中写真」をダブルクリックし，ラスタレイヤプロパティを表示させる。そして，「一般」タブをクリックし，表示名を「第１期（昭和49年～昭和53年）撮影分」としておこう。

さらにオルソ空中写真を追加していこう。再び「レイヤ > Add WMS Layerを」選択し，「Add Layer(s) from a Server」ウィンドウで「オルソ空中写真」を選択して，Connectする。そして，ID 2のみをクリックして色を反転させて，Addをクリック。すると，同じように第２期（昭和54年～昭和58年）撮影分が表示されるようになる。これを，先ほどと同様にラスタレイヤプロパティにて表示名を「第２期（昭和54年～昭和58年）撮影分」としよう。

上記の作業を，第3期，第4期と繰り返してみよう。すると以下のように，4時期のオルソ空中写真が表示される環境が整う。

左側の項目の「×」の切り替えによって，表示を切り替えてみよう。副都心の高層ビル群の見え方の違いや，空き地だったのが高層ビル群に変わったりと，さまざまな変化が観察でき，非常におもしろい。

今回のエントリで，WMSを表示する方法がなんとなく分かっていただけたと思う。次のエントリでは，Quantum GISで表示できる他のWMSを紹介したい。

追記：歴史的農業環境閲覧システムにはWMSはないのかな・・・。

デジタルの地図データを見る方法は2つある。1つ目は，Google Mapsなどのウェブブラウザ経由で地図を見る方法である。2つ目は，Google Earthのように，ソフトウェア経由で地図を見る方法である。後者の方は，Google Earthが出るかなり昔からソフトウェアが存在しており，GISソフトウェアと呼ばれている。このようなソフトウェアは，有料なものがほとんどであり，ほとんどが高価である（Googleに買収される前のGoogle Earth (Keyhole)は有料だった。）。

ただし，GISソフトウェアもフリーのものが多く出てきている。GE Maniacsさんでは，フリーのGISソフトウェアを紹介している。その中で，Quantum GISについて紹介したい。Quantum GISは，既存のデジタルGISデータ（ラスターやベクターを問わず）の表示が可能な数少ない無料のソフトウェアである。オープンソースであり，着実にバージョンアップしている。2009年1月24日に，Ver1.0になった。使ってみると，以前より安定した動作となっており，今後の改良に期待が持てる。Quantum GISの情報は，GITmonsterさんのサイトでマニュアルの日本語訳を含めて詳しく説明されている。Quantum GISにはいろいろな機能があるのだが，その中でインターネット上で配信されている地図を閲覧できる機能に注目してみよう。

インターネットで地図を配信するためには，できるだけ統一することが望ましい。そうすることで，誰もがさまざまな地図を同じ画面上に見られるようになるというメリットがある。そのため，統一規格がOGCという機関で定められている。その規格の1つとしてWMS(Web Map Service)がある。WMSでは，あるフォーマットに沿った形でURLを指定すると，地図を画像として返してくれる（表示例 by 歴史的農業環境閲覧システム）。

1. Quantum GISのインストール

こちらからインストーラーをダウンロードする。実行し，いくつか「次へ」をクリックすると，「Select Packages」というウィンドウが出てくる。そこの「QGIS」をチェックして「次へ」とすると，Quantum GISがインストールされる。これでインストールは完了である。簡単である。起動すると，まっさらな画面が表示されるはずである。

2. WMSによる基盤地図情報25000の表示

今回，基盤地図情報25000のWMSを表示してみる。また，Quantum GISでの表示方法については，こちらに説明がある。なお，表示できるレイヤは10種類あり，こちらに説明がある。

また，最後にAddをクリックする前に，Addボタンの真上のChangeをクリックして欲しい。新たなウィンドウが表示される。これは地図投影法の設定画面である。このウィンドウの下部のSearchのEPSG IDを4612として，OKする。

これによって，地図の投影法をJGD2000（世界測地系）と呼ばれる測地系(地球の楕円体のモデル)で，緯度経度が同じ間隔となるように投影させることを選択したことになる。これは後に追加する空中写真のデータと重ね合わせるためである。

山手線全体が表示されるくらいの縮尺だとこのようの表示される。

さらに拡大して，新宿副都心を表示させた場合は，以下のようになる。

表示される縮尺によって，表示のされ方が異なっているのがわかる。

次にエントリーでは，他のWMSのレイヤーの表示を試みる。WMSのサーバーは，インターネット上にたくさんあるので，各種地図データを紹介したいと考えている。

写真にジオタグ（位置情報）を与える手段はいくつかあって，以前のエントリでも紹介した。iPhoneは自動的にジオタグが付くのだが，一般的なデジカメで撮影した写真にはジオタグには付いていない。そのため，ジオタグを付ける簡便な方法を見つけたいと考えていた。

便利な方法の1つとして，タイトルのように，PicasaによるGoogle Earthを利用したジオタグを付ける機能と，iPhoneの位置情報が付いた写真を組み合わせ，位置情報の付いていない写真にジオタグを付ける簡便な方法を紹介する。

今回は，厳密な位置を特定することは想定せず，だいたいの撮影場所（数十メートルや数百メートルの誤差は含まれる程度）を記録する場合を想定している。

1. 撮影
デジタル一眼レフやコンパクトデジカメで撮影をする。あわせて，撮影の合間にiPhoneで同じような写真を撮影しておく。当然のことながら，iPhoneの写真では位置情報が自動的に付く。
2. 写真の管理
Picasaで写真を管理する。iPhoneの写真もダウンリンクしておいて，ローカルに保存しておく。今回撮影した写真を特定のフォルダに保存しておき，Picasaに表示されるようにしておく。
3. ジオタグを付ける
Picasaで「ツール＞ジオタグ＞Google Earthでジオタグを付ける」を選択。Google Earthが起動する。すると，ジオタグされた写真は勝手に表示されるため，iPhoneで撮影された先ほどの写真は自動的に画面上にプロットされているのである。それを参考に，写真にジオタグを付けることができる。

この方法では，一眼レフやデジカメ等で撮影している合間に，iPhoneでも撮影しておけば良く，iPhoneアプリを使わないため，非常にシンプルな方法である。また，この方法は土地勘の働かない，海外では特に有効だと考えられる。iPhoneは基地局の電波を使わなくても，単独で測位ができるため，海外でも位置情報が取得可能である。

この方法の欠点としては，室内での撮影は良好な精度がでないことである。これはGPSの原理上仕方が無い。この問題の解決方法としては，BrightkiteとFlickrの組み合わせが有効な可能性がある。詳細な方法は省略するが，BrightkiteはFlickrへ自動アップデート機能がある。また，Brightkiteでは「チェックイン」という機能があり，iPhoneのGPSから商業施設等の選ぶことができ，その位置情報を利用して，Flickrへ位置情報を送ることができる。FlickrはKMLを配信しているため，そのKMLをGoogle Earthに表示することができる。

はじめに

Flickrは，写真をアップロードして公開する世界的にも最大のサイトである。そのため，半永久的に写真を蓄積してくれるだろうと楽観的に考えている。なので，ライフログとしてどんどん写真をアップロードしたいと考えている。私は，2つのアカウントを取得しており，用途によって使い分けている。一つ目のアカウントは一眼レフの写真アルバムとして，二つ目のアカウントはiPhoneで撮影した普段の写真をアップするためである。今回は，特にiPhoneからFlickrへ写真をアップロードする方法をまとめてみたい。

iPhoneからFlickrへ写真をアップロードする方法はいくつかあるが，特に位置情報の観点からまとめてみたいと考えている。というのも，Flickrは位置情報（ジオタグ）が付いた写真の取り扱いにも力を入れており，位置情報が与えられたライフログの蓄積に最適だからである。FlickrはKMLを配信しており，APIでは緯度経度を抽出することが可能である。そして，iPhoneのGPSで取得された位置情報は，Flickrでも当然のことながら活用することができる。

理想としては，撮影された位置情報が正しくFlickrに送られて反映され，KMLやAPI等で利用できることが望ましい。そのような観点に基づき，各手段の特徴をまとめてみた。

結論としては，写真撮影直後にアップロードする場合，後に紹介する既存のアプリを使うことが有効だが，リアルタイムでない過去の写真をアップロードする場合は，直接メールを送ることが有効である。そうすることで，写真が撮影された位置情報がFlickrへ正確に反映させることが可能となる。

各種手段の整理

1. アプリ「Twitxr」

このアプリは以前のエントリで紹介した。Twitxrにサインインするための登録が必要である。

アップロードを開始したときのiPhoneの位置情報は，Flickrの「Tags」に「geo:lat=35661691」という形でタグが付く。しかし，Flickrにはそれがジオタグとして認識されていない。そのため，FlickrのAPIにも位置情報が付かない。なお，このアプリではライブラリーも，新規撮影も対応している。

なお，Twitxr自体はTwitterと連携したサービスであり，Twitxrのポストには位置情報は反映されているので，Twitxr APIを使うことで位置情報を取得することは可能である。

2. アプリ「Klick」

「Klick」は，以前のエントリで紹介した。アップロードを開始したときのiPhoneの位置情報がFlickrへ送られるが，Klickのオリジナルな点は，アプリ上で手動で修正をすることが可能なことである。そして位置情報はFlickr上ではちゃんと認識されている。なお，このアプリではライブラリーも，新規撮影も対応している。

3. アプリ「Mobile Fotos」，「AirMe」

「Mobile Fotos」と「AirMe」は，アップロードを開始したときのiPhoneの位置情報をFlickrへ送ることができる（アプリ上での修正は不可）。そしてFlickrでは，その位置情報はちゃんと認識されている。なお，Mobile Fotosはライブラリーと新規撮影の両方に対応しているが，AirMeは新規撮影のみしかアプリ上では扱っていない。

4. アプリ「Brightkite」

このアプリおよびサービスは以前のエントリで紹介した。Brightkiteへサインインするための登録が必要である。

Check inという概念があり，iPhoneのGPSを使ってある場所にチェックインする。そのチェックインした上で撮影した場合は，Check inした場所の位置情報がFlickrへ送られる。そして，その位置情報はFlickr上ではちゃんと認識される。

5. メールで直接送る

iPhoneのSafariからFlickrのサイトを訪れ，Sign inした場合，写真をアップロードするためのアドレスが表示される。それをメモしておき，iPhoneで撮影し，写真をメールに添付して送ることでアップロードすることが可能である。そして，iPhoneの撮影時にExifのヘッダーにジオタグが付くわけだが，そのジオタグの位置情報はFlickrでちゃんと認識されている。

考察

TwitxrはFlickrに位置情報が認識されていないため，以前のエントリで紹介したブックマークレットによる位置情報の付与を事後に行う必要があり，手間がかかるという問題点がある。また，TwitxrやBrightkiteは新たにサービスに登録する必要があるため，手間がかかる。

２，３，４の手段は，リアルタイムに写真をアップするケースに特化している。これらのアプリは，写真撮影時に取得されたジオタグの位置情報を送るのではなく，アップロード時の位置情報をアプリが取得し，それをFlickrへ送っている。つまり，写真を送るタイミングを逃し，別の場所で写真をアップロードする場合，実際に写真が撮影された場所の位置情報は送られないという問題点が発生する。したがって，写真を送るタイミングを逃してアップロードする場合は，一番単純な「メールで直接送る」ｌことが有効となる。

なお，写真の撮影時間が正確にFlickrへ送られているか，同様に調べてみた。「Mobile Foto」は写真のヘッダーに付与されている撮影時間をFlickrへ送っており，Flickr上で認識されている。一方，「Klick」，「AirMe」，「Brightkite」はアップロードしている時間がFlickr上では撮影時間として認識されることがわかった。

まとめ

TwitxrはそもそもFlickrに位置情報がちゃんと認識されないという問題があるため，使用しない方が良いだろう。アプリである「Klick」，「AirMe」，「Mobile Fotos」は，リアルタイムに写真をアップロードする場合には有効である。Brightkiteは，位置情報SNSであるため，Brightkiteユーザには有効であり，リアルタイムに写真をアップロードする場合に有効となる。一方，リアルタイムではない過去の写真で位置情報をちゃんと対応させてFlickrへ送りたい場合は「メールで直接送る」ことが唯一の有効な手段である。というわけで，リアルタイムと過去の写真では，アップロードを使い分ける必要がある。

Flickrへアップロードできるアプリについては，過去の写真についても送ることができる機能が付いてるものの，その写真のジオタグの位置情報を反映してFlickrにアップロードできる機能を実装するべきである。なお，私は上記以外のアプリを使用していないため，写真のジオタグの位置情報が正確にアップロードできるアプリがあれば，教えていただけると幸いである。

位置情報や空間情報の可能性に長年注目してきた私であるが，「位置情報」のSNSとして登場したBrightkiteには非常に魅力を感じている。Brightkiteについては，やや古いがCnetの記事が詳しい。

私は，iPhoneが登場した2008年7月から，Brightkiteを使ってきた。当初はウェブインターフェイスのみだったが，10月にはiPhoneアプリが登場し，GPSを使えるようになった。まだ，使いこなせたとは言えないが，Brightkiteを半年ほど使ってきたので，ここで魅力について整理してみようと思う。私は3つの可能性を感じている。

• 位置情報という新しい軸で繋がる

Mixiであればコミュニティーやマイミクシーで繋がり，TwitterではBio（自己紹介）でMixiよりも緩やかに繋がる。しかし，Brightkiteは「位置情報」という別の軸で繋がることができる。これは，iPhoneやGPS付き携帯電話の登場のおかげである。いまやこの手のサービスは，PCの前ではなく，外（フィールド）で歩きながらでも繋がることができるようになり，SNSとしてのメリットをさらに引き出すものであると考えている。ソーシャルネットワーキングサービスは位置情報として拡張していくのは正しい流れだと思う。

• TwitterとFlickrへのポストが可能

単独サービスではなく，Twitterへポストできる。また，Twitterへポストする際には，緯度経度などを入れることができ，カスタマイズが可能となっている。また，12月23日にはFlickrへアップロードできるようになった。写真をポストすると同時にジオタグが付与された形でFlickrへアップされる。

このようなメジャーなサービスの連携は，ユーザの裾野を広げるために非常に重要である。色々な似たようなサービスであるが，同じ作業をするのは煩雑である。Brightkiteの場合は「位置情報」という別の軸を持っているので，こういう連携を行っても共存が可能なのであろう。うまく連携しながら成長する可能性は十分にあるだろう。

• ライフログとしての活用可能性

ある場所でポストした文章や写真は，自分のライフログと捉えることもできる。そして，ログである文章や写真に位置情報を与えるだけで，その文章や写真の背景を知る手がかりとなるのではないだろうか。そういう観点で考えると，Brightkiteが位置情報を付けてTwitterやFlickrにポストできる機能は，ライフログへ発展する可能性を秘めている。また，Brightkiteの機能として，プライベート用ポストが可能な機能が提供されているので，公開できない個人的なポストについても記録することができ，まさしくライフログのための機能である。

位置情報系SNSは，loc8orやPocket Lifeなど続々と登場してきている。2009年は位置情報SNSがブレークする可能性は十分にある。

いつの間にか，Google Maps APIで逆ジオコードができるようになっていた。ジオコードは，住所から緯度経度を求めるが，逆ジオコードは，緯度経度から住所を求める。今まではジオコードは多かったが，逆ジオコードはあまりなかった。

今後，緯度経度（ジオタグ）が付与された写真やいろいろなデータが増加していくことが予想されるが，データの管理としては，やはり緯度経度の情報で扱われる可能性が高いだろう。それを，何かのサービスやアプリケーションで使う場合は，処理においては数字を使うことなるが，ユーザインターフェイスの観点からは人間の見た目で位置を瞬時に把握するために，住所として表現されることは非常に重要である。そういう意味で，気軽に逆ジオコードによって住所が取得できることの意義は大きいと思う。

さて，Google Maps APIで実際に逆ジオコードを行ってみる。RESTサービスで取得可能でありJSONでの出力に対応している。以下にサンプルを示す。

http://maps.google.com/maps/geo?oe=utf-8&ll=35.620519%2C139.438892&key=ABQIAAAANb5JuD4i3v_Isz_A_z4ipxTrwmVSgF6tOzG2piSiw3F-ORmacRQGqjoiQ55HzLvszowcXYUDT1mXwA&output=json&callback=gmap

コールバック関数はgmapとしている。結果は以下の通りである。

gmap && gmap({
  "name": "35.620519,139.438892",
  "Status": {
    "code": 200,
    "request": "geocode"
  },
  "Placemark": [ {
    "id": "p1",
    "address": "日本東京都多摩市貝取２丁目９−１",
    "AddressDetails": {"Country": {"CountryNameCode": "JP","CountryName": "日本","AdministrativeArea": {"AdministrativeAreaName": "東京都","Locality": {"LocalityName": "多摩市","DependentLocality": {"DependentLocalityName": "貝取","Thoroughfare":{"ThoroughfareName": "９−１ ２丁目"}}}}},"Accuracy": 8},
    "Point": {
      "coordinates": [ 139.4391663, 35.6206892, 0 ]
    }
  }, {
    "id": "p2",
    "address": "日本東京都多摩市貝取２丁目９",
    "AddressDetails": {"Country": {"CountryNameCode": "JP","CountryName": "日本","AdministrativeArea": {"AdministrativeAreaName": "東京都","Locality": {"LocalityName": "多摩市","DependentLocality": {"DependentLocalityName": "貝取","Thoroughfare":{"ThoroughfareName": "９ ２丁目"}}}}},"Accuracy": 7},
    "Point": {
      "coordinates": [ 139.4386358, 35.6205225, 0 ]
    }
  }, {
    "id": "p3",
    "address": "日本東京都多摩市貝取２丁目",
    "AddressDetails": {"Country": {"CountryNameCode": "JP","CountryName": "日本","AdministrativeArea": {"AdministrativeAreaName": "東京都","Locality": {"LocalityName": "多摩市","DependentLocality": {"DependentLocalityName": "貝取","Thoroughfare":{"ThoroughfareName": "２丁目"}}}}},"Accuracy": 4},
    "Point": {
      "coordinates": [ 139.4399301, 35.6219557, 0 ]
    }
  }, {
    "id": "p4",
    "address": "日本東京都多摩市貝取",
    "AddressDetails": {"Country": {"CountryNameCode": "JP","CountryName": "日本","AdministrativeArea": {"AdministrativeAreaName": "東京都","Locality": {"LocalityName": "多摩市","DependentLocality": {"DependentLocalityName": "貝取"}}}},"Accuracy": 4},
    "Point": {
      "coordinates": [ 139.4381358, 35.6235749, 0 ]
    }
  }, {
    "id": "p5",
    "address": "日本東京都多摩市",
    "AddressDetails": {"Country": {"CountryNameCode": "JP","CountryName": "日本","AdministrativeArea": {"AdministrativeAreaName": "東京都","Locality": {"LocalityName": "多摩市"}}},"Accuracy": 4},
    "Point": {
      "coordinates": [ 139.4463069, 35.6370041, 0 ]
    }
  }, {
    "id": "p6",
    "address": "日本東京",
    "AddressDetails": {"Country": {"CountryNameCode": "JP","CountryName": "日本","AddressLine":["東京"]},"Accuracy": 2},
    "Point": {
      "coordinates": [ 139.4872858, 35.6837135, 0 ]
    }
  }, {
    "id": "p7",
    "address": "日本東京都",
    "AddressDetails": {"Country": {"CountryNameCode": "JP","CountryName": "日本","AdministrativeArea": {"AdministrativeAreaName": "東京都"}},"Accuracy": 2},
    "Point": {
      "coordinates": [ 139.6917064, 35.6894875, 0 ]
    }
  }, {
    "id": "p8",
    "address": "日本Honshu",
    "AddressDetails": {"Country": {"CountryNameCode": "JP","CountryName": "日本","AddressLine":["Honshu"]},"Accuracy": 1},
    "Point": {
      "coordinates": [ 138.0803529, 36.0786279, 0 ]
    }
  }, {
    "id": "p9",
    "address": "日本",
    "AddressDetails": {"Country": {"CountryNameCode": "JP","CountryName": "日本"},"Accuracy": 1},
    "Point": {
      "coordinates": [ 138.2529240, 36.2048240, 0 ]
    }
  }, {
    "id": "p10",
    "address": "アジア",
    "AddressDetails": {"AddressLine":["アジア"],"Accuracy": 0},
    "Point": {
      "coordinates": [ 108.3307000, 34.3644390, 0 ]
    }
  } ]
}
)

この緯度経度に意味は無く適当に入れた数字である。Placemarkの配列が後になるほど，空間的にカバーする範囲が広くなる。しまいには，アジアなんていうのもあり，これはこれでおもしろい。

このAPIを活用することにした。先日，Brightkite APIで自分の位置を示すブログパーツを作成したが，これに応用してみる。Brightkiteでは，ある位置に「チェックインする」という概念を用いている。iPhoneのBrightkiteアプリでは，GPSを使って，その位置に気軽にチェックインできるのだ。しかし，国内では，日本語の住所が出てこない。そのため，例えば，下北沢の付近のある地点は「Yoyogi-sanyachō, , Japan」と表示され，大変分かりづらい。

そこで，APIで出力される緯度経度を用いて，上記の逆ジオコードAPIによって，代わりに日本語住所を表記させるようにしてみた。先日のエントリで示したbrightkite.jsは，既にこれに対応して書き換えられている。

モバイルSNS＆位置情報SNSであるBrightkiteに注目している。注目している理由については稿を改めたいが，APIを公開しているので，それを使ってBrightkiteユーザが「今ココ」を表示できる，簡単なブログパーツを作ってみたので紹介する。

私のウェブサイトのトップページの左に表示してある地図の部分が，そのブログパーツである。内容は，Google Static Maps APIで画像を表示させ，時間と位置を表示するだけの，至ってシンプル作りである。

必要なのは，このbrightkite.jsというファイル。JSONPのコールバック関数を呼び出して，HTMLを作成する。このjsファイル内の，Google Static Mapsには自分のAPIキーを入力する必要がある。 そして，以下のソースを貼り付ければ完成。tagchan.jsonのところを自分のユーザ名に変える必要がある。

<script type="text/javascript" src="http://www.tagchan.net/brightkite.js"></script> <span id="ima_koko"></span> <script type="text/javascript" src="http://brightkite.com/people/tagchan.json?callback=BKFeed"></script>

Brightkiteユーザの方々で，よろしければご自由にお使いくださいませ。

また，BrightkiteのiPhoneアプリが登場したので，最近はユーザがかなり増えている印象。Brightkiteの招待も可能ですよ。

Brightkite - Tagchan
http://brightkite.com/people/tagchan/friendstream

前回のエントリから間が空いてしまった。一応，無事に生きており，学位論文の執筆で忙しいため，ブログエントリを書く余裕が無い。

しかし，日々iPhoneを使い倒している。そして色々なアプリを使っては消しているのだが，iPhone写真による位置情報付きライフログの取得の方法はklickからTwitxr（ツイッチャ）に移ってしまった。Twitxを選ぶことにした理由を，以下に列挙しよう。

• TwitxrもFlickrに写真をアップロードできるが，klickはアップロードに時間がかかる。Wifiだとアップロード時間はそんなに違わないのだが，3Gのときはklickだと数分かかる場合がある。電池の消耗が激しいのだ。Twitxrは写真のサイズを落としてアップロードしてくれるので，アップロード時間はそれほどかからない。
• Twitxrは，名称からも推測できるようにTwitterと連携している。Twitxrは，Twitxrで独自アカウントを設定しなければならないものの，アップしたらTwitterに自動的にポストしてくれるので便利である。
• ポストしたときのiPhoneの位置情報がTwitxrのサーバへ送信される。さらに，Twitxr自身がAPIを持っており，API経由で位置情報が取得可能であり，今後の拡張性がある。

ただ，問題点もあって，Flickrに写真を送られるものの，ジオタグが付かないために，Flickrでは撮影時に取得された位置情報が認識されない。ここはなんとかして欲しいところだ。また，撮影場所の編集ができないため，アップロード時と撮影時で場所が異なる場合は，修正できない。

いろいろと新しいアプリやサービスが登場するので，非常におもしろいiPhoneだが，色々な要求も同時に出てくる。それならいいっそ自分で開発すれば良いと思えなくもない。それは博士論文が終わる来春以降に考えるとするか・・・。

Tagchan's photo_log　(Flickr)
http://www.flickr.com/photos/tagchan_stream/

Tagchan (Twitxr)
http://www.twitxr.com/tagchan/

過去の自分の行動を顧みることは，いろいろな場面で重要だ。これまでは日記帳を利用することが多かったわけだが，ITによって，テキストデータだけでなく音声，動画，写真を，「ライフログ」として記録することも技術的に可能となった。Googleで「ライフログ」を検索すると，ライフログに関する話題も多く，注目している人が多いと実感する。

特に，位置情報はライフログにとっては有効である。ライフログに位置情報が与えられると，膨大なライフログが蓄積された後に，そのログを検索するための重要なキーワードとなる。また，位置情報があることで，地図と重ねることが可能となるため，そのログの背景や経緯を思い出しやすくなるというメリットもある。

今回は，特に写真のライフログについて考えてみる。ライフログということで，気軽に撮影できることが必須の要件である。また，そこそこのクオリティで写真撮影ができ，位置情報を付けやすい端末が望ましい。そのように考えると，iPhoneが最適である。また，撮影した写真は，インターネット上にアップロードし，蓄積させて検索やタグ付けが容易な，写真共有サイトを利用することが望ましい。そのようなことをiPhoneのアプリで気軽に行える方法を発見したので紹介する。

Klickは，iPhoneで撮影した写真をFlickrにアップロードすることができる無料のアプリである。機能の詳細については，こちらに説明がある。Klickを使うと，アプリ内で撮影し，タグ・タイトル・説明文・公開レベルを設定することが可能である。そして，その場所のGPSの位置情報がジオタグとして与えられ，Flickrへアップロードされる。また，過去の撮影した写真をアップロードする場合や，GPSが取得できない場合は，地図を利用して撮影位置をマニュアルで特定することができる。

ライフログとは別の話になるが，Klickには位置情報に関連した機能が充実しており，位置情報を使ってFlickrで近くの場所で撮影された他人の写真も見ることができる。

iPhoneでFlickrを手軽に楽しめるオールインワン-Klick (iPhone研究室)

GPSと連携して現在地の近くで撮影された画像を表示するだけでなく、Klick内でGoogle Mapの地図を表示することが可能で、地図上に表示されたピンをタップすると吹き出しの中で画像を表示します。同じ場所の写真が数枚ある場合は、吹き出しの中で切り替えることもできます。

Flickrでは，KMLで配信可能なので，Google Earthで表示もできる。また，GeoRSSもあるので，Google Mapsにも表示可能だ(リンク)。さらに，位置情報付きのJSONで配信されるので，マッシュアップが容易である。以前，私が行ったFlickr＋Google Mapsも容易である（公開できる写真であればの話）。このように，とても気軽に写真のライフログ＋位置情報が実現できることから，当面はiPhone + Klick + Flickrによる写真のライフログを継続していこうと思っている。

TagPhotoLog
http://www.flickr.com/photos/tagchan_stream/

このエントリーと関連していると考えられる他の方のエントリーを紹介する。参考にさせていただいた。
・iPhoneで撮った写真をグーグルマップやグーグルアースに表示する iPhone・iPod touchラボ
・iPhoneでPhotoShareを使いながら実現するライフログの形 北の大地から送る物欲日記

先週のエントリでは，トラッキングのiPhoneアプリを紹介したが，おかげさまでかなりのアクセス数となった。このエントリを公開した後，日経BPで林氏が同じような記事を書いた。この記事では，iTrailとPath Trackerを紹介していた。Path Trackerについては，ノーマークだったので，Path Trackerを購入し，同様にトラッキングログを取得してみた。なお，Path Trackerは115円だった。

Path Trackerを起動すると，まずGPSで位置を取得しようと試みる。もし，失敗したら緯度経度が0度のところ（アフリカの西の海上）に勝手に設定される。iボタンで設定画面に移動する。

はじめに，アカウントを作る必要がある。メールアドレスとパスワードを入力する。そうすると，アカウントが作成され，Path Trackerのサイトでログインすることができる。ログイン画面については後ほど説明する。「新規パスを開始」をタップし，完了をタップしてメインに画面に戻る。そして，トラッキングが開始される。

iTrailやGPS Trackerとは違って，Path Trackerはメイン画面で地図が表示される。これは個人的にはうれしい。メイン画面では位置，高度，経過時間，平均速度，移動距離が表示されるが，この辺はiTrailの方が詳細である。

トラッキングを終える場合は，iをタップして設定画面へ移動し，停止をタップする。ログは，PathTracks.comへ送信をタップすることで，サーバーにアップし，Path Trackerのサイトで見ることが可能となる。

先ほどのメールアドレスとパスワードでログインすると，過去のトラッキングのログが表示される。Viewをクリックすると，選択したトラッキングがGoogle Maps上に表示される。表示されたトラッキングのデータは，KML形式やGPX形式でダウンロード可能である。また，「Share it」または「Share this path」をクリックすると，このサイトへ誰でもアクセスできるようになる。ちなみに，上記画像のサイトはこちらである。東林間駅からコメダ珈琲つきみ野店までのトラッキングログである。

Shareによる共有の設定後は，Googleのサイト上のGoogle Mapsにて表示可能である。上記のパスが表示されているサイトにKMLのリンクがあるが，このURLをコピーし，Google Mapsの検索フォームに入力して検索を行うと，パスが表示される。これをマイマップに保存すれば，パスの微調整もできるはずである。しかし，今回は「Unsupported encoding Shift_JIS 」となって保存ができなかった。なお，Googleのサイト上のGoogle Mapsにて表示することは，Google Documentへ保存可能なiTrailでも可能である。

先日のエントリとあわせて3つのトラッキングアプリを使用してみたわけだが，Path Trackerの良い点は，トラッキング中のメイン画面で地図表示されている点である。ただし，表示の詳細さや使い勝手はiTrailの方が上である。また，アプリ提供のサーバーにアップする点はGPS Trackerと同じであるが，GPS Trackerのようなリアルタイム性はない。サイトが公開できるが，GPS Trackerのようなiframeによるブログパーツになるわけではない。

Path Trackerは，iTrailやGPS Trackerと比べて特に卓越した機能があるわけではないことが分かった。今回のエントリと先日のエントリを参考にしつつ，購入の判断材料に用いてもらえると幸いである。

今後これらのアプリはアップデートされていくと予想されるので，使い勝手がよくなったり，おもしろい機能が搭載されることを期待したい。で，早速iTrailはアップデートされて日本語表記が対応した。また，GPSの信号が弱いとか強いなども表示されており，使い勝手がさらに良くなった。

写真に位置情報を与える方法はいくつかあって，以前のエントリーでいくつか紹介した。そこで紹介したのは，Garmin等のGPS端末でトラッキングし続け，あとで撮影時間によって写真と関連付けてEXIFに書き込む方法である。他にも，事後的にソフトウェア上で位置を特定する方法や，ウェブサービスによって位置を特定する方法だった。携帯電話の写真については，以前からGPSつきの携帯電話で一手間かけながら位置情報を与えることが可能であり，それを活用したサービスも考えた（リンク）。そして，iPhoneの登場によって，携帯写真に位置情報を無意識的につけることが可能となった。

そして，今月になってカメラ大手のNikonがデジカメとGPSを連携させる方向に動きはじめた。8月上旬に，コンパクトデジカメのカテゴリに入ると思われるCOOLPIX P6000が発表され，GPSを内蔵するということで非常に驚いた。

ニコンデジタルカメラ「COOLPIX P6000」の発売について
http://www.nikon.co.jp/main/jpn/whatsnew/2008/0807_p6000_02.htm

GPS（Global Positioning System : 全地球測位システム）を内蔵し、Geotag（写真が撮影された位置情報／緯度・経度［測地系：WGS-84］）を画像に付加することができます。 ViewNX、「my Picturetown」において撮影した画像の位置情報と地図との連携をサポート、写真の閲覧・整理・保存において新たな楽しみを提供します。

コンパクトデジカメでGPS内蔵というデジカメはいままで登場していなかったのではないだろうか。以前，RICOHがGPS内蔵カメラを出していたが，工事現場等での使用を想定していた雰囲気がある（リンク）。しかし，P6000はそういう雰囲気ではなさそうだ。他にも，ランサーテクノロジーがGPSカメラを発売していたが（リンク），内蔵ではなくケーブルでの接続だった。

そしてさらに，D80の後継機であるD90の発表と同時に，Nikonの純正GPSユニットが発表され，D90の他，上位機種で使用可能となることが発表された。

ニコン、動画も撮影できるデジタル一眼レフカメラ「D90」発表--新レンズも
http://journal.mycom.co.jp/news/2008/08/27/052/

撮影時の位置情報などを記録するGPSユニット「GP-1」が用意される。撮影時の緯度、経度、標高、日時が記録できる。地図情報と連携させて、画像つきのオリジナルマップ作成などが可能。「GP-1」はD90のほか、D3、D700、D300、D2シリーズ、D200でも使用できる。2008年11月発売予定。価格は未定。

使用イメージは，Nikonのウェブサイトで見ることができる。フラッシュの部分の上に取り付けるような形になるようだ（リンク，画像）。私はD80を所有しているので，このGPSユニットは使用できない可能性が高い。非常に残念である。

以前は，デジタル一眼レフとGPSを連携する方法は，Garmin等の別のGPS端末を専用ケーブルで接続する方法だった（リンク）。私自身は経験は無いが，2つのバッテリーを考慮する必要があることや，接続時の不具合等が発生しやすいと想定されるので，面倒な作業になることが想像できる。しかし，今回は純正であり，上部に取り付けることができるため，GPSユニットが邪魔にならない。また，純正なので，カメラのディスプレイで位置情報を確認したり，何らかの設定ができるかもしれない。そうなると，Garminで接続していたときと比べてかなり敷居が低く，手軽に写真に位置情報を付けることができるのではないだろうか。

というわけで，今後は他社もGPS内蔵のデジカメを発表し，カメラ＋GPSがデフォルトとなるようにして欲しい。また，希望としては，位置情報が分かるようになるのだから，今度はデジタルコンパスによって撮影方位が分かるようになって欲しい。次はGPS＋デジタルコンパス内蔵のデジカメの登場を期待したい。

前回のエントリでは，iPhoneのGPSの感想を述べたが，今回はAppStoreでアプリを利用して，GPSのトラッキングログの取得を試みた。私自身は，現地調査に行く際や，旅行に行く際に，GarminのGPSでトラッキングをとっており，後にデジカメで撮影した写真と時間を基に関連付ける作業を行う場合があることから，iPhoneを使ってGPSのトラッキングを試みたいと前々から思っていたのである。

GPSでトラッキングできるソフトウェアとしては，現時点（2008年8月24日現在）で3つあることを確認している。GPS Tracker(無料)，GPS kit (1200円)，iTrail(350円)である。

【2008年8月1626日追記】
Path Trackerというソフトもあるんですね（参考）。こちらも注目してみたいと思います。

GPS kitとiTrailは，よくあるハンディGPSとなっており，移動軌跡ログの取得，ウェイポイントの登録，速度，高度等が計測可能である。機能はGPS kitの方が多いらしいが，インターフェイスはGPS Trackerの方が良いというのが，ブログ界隈での印象となっている。一方，GPS Trackerは，ハンディGPSのような表示機能はないが，トラッキングに特化している。また，トラックのログは，アプリ提供会社のウェブサイトでユーザ登録することで，ログインページが作成され，アップロードされたログを閲覧したり，ダウンロードすることが可能となっている。というわけで今回は，トラッキングログをとる目的としたので，GPS kitと比較して値段が安いiTrail (Ver 1.3)と，GPS Tracker (Ver 1.0)を購入し，ログをとってみることにした。今回はこれらのソフトの使用レポートである。今回，車のダッシュボードにiPhoneを置いて，往復2時間のドライブを行った（自宅と慶應大学湘南藤沢キャンパスとの往復）。

• iTrail

iTrailは，イベントごとに軌跡（Trail）を分けて管理することができる。そのため，まず「New Trail」で新しい軌跡を作成することからはじめる。ファイル名と用途を選択する。作成できると，自動的にメイン画面に戻る。そして，startをタップすると，トラッキングを開始する。また，Settingのところで表示単位や位置を取得する頻度も変更できる。トラッキングしている様子は以下のような感じ。

緯度経度と標高が上段に表示され，その下にはトラッキング時間が表示されている。その下の段には速度と移動距離が表示されている。トラッキング中は速度が表示されるが，車の速度と比較してみると，だいたい合っていることは確認できた（車の速度メーターはアナログなので，厳密な比較はしてない。もちろん，運転中なので凝視はしていない）。そして，目的地に到着し，メイン画面のstopをタップしてトラッキングを終了させた。終了後，「My Trails」に移動すると，トラッキングログの情報を確認することができる。以下の図がその様子。

ここに，Speed graphとAltitude graphがあるが，速度の変化や標高の変化を移動距離ごと(要するに時系列)で確認できる。以下の図がそのグラフである。

また，Google Mapsとあるが，ここをタップするとGoogle Mapsが表示され，通ったルートが地図上にオーバーレイされるのだ。

Export Dataでは，Googleのアカウントを持っていれば，Google Docsにデータをアップロードしてくれる。形式はKMLとGPXの2種類である。Google Docsであれば共有もできるので，ローカルに保存するより便利かもしれない。

• GPS Tracker

GPS Trackerはどちらかというと，リアルタイムに現在位置を確認する用途を想定している。アプリ購入後は，配布元のウェブサイトでユーザ登録する必要がある。登録するとデバイスIDが配布されるので，その番号をiPhoneのGPS Trackerアプリのフォームへ入力する。そうすることで，トラッキングのログが3Gの回線で配布もとのサーバーへ送られ，ログが蓄積させることができるのだろう。GPS Trackerの画面はとてもシンプルである。

方位が分かるものの，距離の単位がフィート，速度の単位はマイルとなっていた。また，単位は変更できなかった。このソフトはログを3Gの回線で定期的にアップロードしているようだ。

ログをとったあと，先ほどのウェブサイトにログインすると，軌跡をGoogle Mapsで確認することができる。もちろん，データをエクスポートすることもできる。

さらに注目すべきところは，軌跡を公開することができるのだ。ブログに貼り付けることも想定しており，コードを貼り付けるだけで以下のような表示ができてしまう。また，APIもあるようなので，拡張性もありそうだ。

GPS tracking powered by InstaMapper.com

• まとめ

今回は，iPhone GPSと，iTrailとGPS Trackerというアプリを使ってトラッキングログの取得を試みた。iTrailは，トラッキング後に軌跡をiPhone上で地図と重ねて確認でき，Google DocsにKMLやGPXの形式でエクスポートが可能だった。一方，GPS TrackerはiPhoneアプリ上ではシンプルな表示だが，軌跡を定期的にサーバーにアップロードしており，リアルタイムで軌跡を把握することが容易な仕組みだった。また，APIに対応しており，ブログに貼り付け可能なコードもあるため，拡張性があることがわかった。

以前は，Garmin GPSのトラックログをカシミール３Dで接続し，ダウンロードしなければならなかった。iPhoneの登場によって，GPSでトラッキングログをとる敷居が非常に低くなったことを実感できた。また，2つのソフトは，トラッキングログを取得することは同じだが，それぞれの特徴を生かして，用途によって使い分けると良いと思われる。

iPhoneを使ってだいたい1ヶ月となる。iPhoneのGPSには期待していたわけなので（リンク），GPSについて感想を述べてみる。AppStoreのソフトウェアについては別エントリーで述べることにするので，今回は「マップ」のみの感想とする。また，他のブログで既出となっている内容が多いかもしれないが，自分へのメモや感想ということで了承をいただきたい。

空が開けていてもGPSによる測位ができないときがある

室内というわけではなく，空が開けている状態で測位しても，位置情報が取得できないことがある。これには，かなり悩んだ。今のところの解決としては，測位できるはずなのに測位できない場合，電源をオフにして再起動するとすんなり測位できる可能性が高い。できないときは本当にGPS衛星の位置が悪かったと諦めるしかない。

GPSによる測位の速度について

条件が良い場合，すぐにあっさりと位置情報を取得できる。Garminの数年前のGPSと測位の速さを隣に並べて比較してみたが，iPhoneの方が早かった。一度きりしか試していないので，どのくらい早いのかどうかは不明だが，測位の速度は従来の専用のGPS端末と比較しても遜色ないのではないかと思う。

室内でも位置情報が取得可能（ただし，場所による）

GPSで測位する場合，空が開けている状態でなければ，GPS衛星の電波を拾うことができないため測位ができない。しかし，室内でも測位できる場合がある。しかし，かなり精度は低く数百メートル程度である。これは，GPSではなく基地局による簡易位置情報と推測される。ただし，場所によっては測位ができない。私の場合，自宅ではこれによる測位はできない。しかし，駒場の大学の室内では測位ができる。これは，基地局の位置情報対応の有無によるのだろうか。この辺については，事情がわからない。

圏外でも単独によるGPSの測位が可能

先日，遠出をして標高の高いところに行った。山岳地なので，3Gの電波は当然のことながら入らなかった。従来の携帯電話の場合，圏外だとGPSによる測位はできなかった。しかし，試しに測位してみたところ，位置情報が取得できた。これには驚いた。ただし圏外なので，Google Mapsのレイヤは表示されなかったので，自分がどこにいるのかを地図からの文脈で判断することができなかった。ということは，地図を自前に用意できるようなアプリがあれば，圏外でもGPSが使い物になる可能性がある。また，ログをとるようなソフトには役に立つだろうと思う。

移動体に乗っているときに測位すると現在地が移動する

電車の窓の近くにiPhoneを置いて測位しておくと，数秒おきに現在地が移動していくのがわかる。特に，新幹線に乗った場合は，当然のことながら移動が早い。拡大しすぎていると，地図表示が間に合わなくなった。また，現在位置がマップの表示範囲を外となった場合，勝手に視点が移動してくれることはなく，自分で移動してあげる必要があった。

要望：GPSによる測位の状況が知りたい

現状では，iPhone GPSによる位置情報の取得がブラックボックスである。もちろん，ブラックボックスであることは意識しないで位置情報を取得可能という観点から重要だ。しかし，個人的にはある程度はGPS測位の状況を知りたい。GarminのGPSではGPSの配置が確認できる（例）。GPSは衛星の数と空での配置が重要となるので，測位が可能か不可能かを判断するためにも，こういう測位の状況を知る手段があるとうれしい。

とうとう，Google MapsのStreet Viewが日本に対応した。Google Mapsに「ストリートビュー」というレイヤーが登場し，カバーしている範囲が表示される。今のところ，札幌，函館，仙台，関東，大阪，神戸，京都，奈良が範囲のようだ。名古屋や福岡はまだのようだ。ただ，どんどん拡大して撮影しているようなので（リンク），範囲は順次拡大していくのだろう。私の住んでいる相模原は今回の公開範囲に入っており，自宅周辺をストリートビューで見ることができた。ベランダの洗濯物まで確認できてしまった。

午前8時半ころ，TwitterでGoogle Street Viewの開始を知り，小1時間見ていたのだが，整備してある道路の青い線が航空写真とかなりずれており，関西に至っては，海に青い線が引かれている状態となっていた。また，視点となる人形のアイコンが道路より外となっていて，どの道路のストリートビューなのかわからない場合もあった。しかし，夜になって修正されたことを確認した。当日に改善されるというのは，それはそれですごいことである。

先日，第2回ジオメディアサミットが開催され，Google Mapsの日本チームが参加していた。Googleのプレゼンのときの質問で，いつころサービスがはじまるのか，という質問があった。しかし，彼らは時期を明言しなかった。そのため，サービス開始は秋以降だろうと思っていたのだが，唐突にサービスが開始されたので，寝耳に水といった状況である。

今回のGoogleのStreet Viewによって，国内のストリートビューができるサービスは2つとなった。もう1つはLocation Viewである。第2回ジオメディアサミットでも紹介され，完成度はかなり高いという印象を持った。こちらは，アジア航測が撮影を行っているらしく，このLocation Viewの親会社(アイディーユー)がアジア航測と資本提携しているようだ。サミットでの話しを聞く限りでは，かなり消防など自治体向けに需要があるらしく，そちらの儲けで維持しているような印象を受けた。その辺はGoogleとはビジネスモデルが違っていて興味深い。Location Viewは，8月4日に範囲拡大を行っており，今後も拡充が期待される。

というわけで，国内は2つのストリートビューの時代となったわけだが，違いを見ていくことにしよう。同じストリートビューなのだが，アプローチが異なっている。

Location Viewの方は，「映像地図」ということもあり，車からの動画の撮影をサイト上に再現しようとしている点が特徴的である。Location Viewのサイトでは，右上に車が表示されている。そして，現在表示されている画面が，車のどの向きまたは方角であるのかを表示している。動画撮影を再現をしているため，もし撮影時の車の進行方向と逆に進みたい場合，車をバック（つまり動画を逆再生）させるように，ユーザが設定しなければならない。この辺はやや直感的ではない。利用者はその辺の制約は面倒に感じるだけである。

一方，Google Streer Viewは，人間の視点を想定して表現している。この点は，地図に表示されるアイコンが人間の人形であることからもわかる。Street Viewでは，ある一定間隔ごとに写真が撮影されており（撮影方向は11方向），Location Viewのような撮影した車の方向を考える必要はない。ただし，一部で撮影順序による影響で，つながっているはずの道路が回り道しなければならない場合があった。

というわけで，2つの違いについてみてきたが，どちらもブログに貼り付けられたり，URLでリンクが貼ることもできる。APIに関しては，将来的にGoogleが公開をはじめる可能性は高いが，Location Viewはやらない可能性が高い。拡張性や将来性はGoogleの方が上だろう。

今後，このサービスに関するプライバシーの問題は必ず付きまとうだろう。それでも，2つのストリートビューはそれぞれ特徴を出しつつ，日本全国を整備することを目標に，2大ストリートビューとして提供を続けて欲しい。

以前，gooやYahoo Japanが昭和30年代の地図や空中写真を公開して話題となった。今回，横浜市が昭和30年代の1/3000地形図をkml形式での公開を始めた。

横浜市三千分一地形図（昭和30年代）
http://www.city.yokohama.jp/me/machi/kikaku/cityplan/gis/3000-30s.html

昭和30年代を中心に（1954（昭和29）年から1965（昭和40）年）、三千分一地形図が新たに作成されました。この昭和30年代の三千分一地形図は、空中写真測量により作成され、縮尺は同じ3000分の1ですが、東西3,000m、南北2,000mの図郭で、当時の横浜市域を90図葉でカバーしています。

Google Earthを起動して見てみたが，1/3000という大縮尺であることから，建物の輪郭まで表現されており，とても詳細な地図であることが分かる。

昭和30年から一番変化が大きそうなみなとみらい地区を表示してみた。

画像真ん中あたりの白い建物がパシフィコ横浜である。このあたりは，昭和30年代は埋め立てられておらず，空白となっている。つまり海だった。また，パシフィコ横浜の南東にある島は，赤レンガ付近は存在しているが，新港パーク付近（地図）はまだ埋め立てられていなかったようだ。

さて，ちょっと細かいところに注目していこう。この地図は，上記引用によると写真測量に基づいて作成したと書いている。従って，この地図自体の位置精度は高いと予想される。しかし，Google Earthの航空写真とは厳密には重なっていないように見える。これは，地図自体の投影法の違いが原因である。

おそらく，この1/3000地形図は平面直角座標系によって投影されていると考えられる。この投影法は歪みを小さく抑えられることが可能である。一方，Google Earthは等緯度経度の投影である。この投影法では，高緯度ほど地図上の面積は大きく見えてしまうタイプである。なので，基本的に投影法が違うため，たとえ１点どこかで正確にあわせても，ほかの場所でずれが生じてしまうのだ。厳密には正確な幾何補正を実行する必要があるが，そこまで重ね合わせを行う必要はないのかな...。

iPhoneでGPSが搭載されることが発表され，携帯端末で地図を使う頻度が増えていくと思う。しかし，アナログ地図（紙地図等）だって侮ることはできない。先日，文庫判の東京と神奈川の地図を購入した。

ここで，文庫判の地図のメリットについて，携帯端末の地図と比較してみることにする。

（１）いつでも鞄に入れておくことができる携帯性

携帯性は携帯端末と同等である。しかし，雑に扱っても壊れないという点では文庫判地図に分がある。

（２）視点の切り替えの早さ

ページをパラパラとめくると，視点をすぐに変えることができる。携帯端末での視点の切り替えは，従来の携帯電話ではとても遅い。iPhoneやtouchはタッチパネルで多少は切り替えが早くなってはいるが，切り替えのスピードは文庫判地図に分がある。この点は文庫判に限らないことかも。

（３）取り入れることができる情報量

携帯端末のディスプレイのサイズと文庫判のサイズを比べると，文庫判の方が広い。また，視点の切り替えの早さを考えると，文庫判の地図から得られる情報量は多い。

一方，携帯端末の地図のメリットは，

（１）位置把握機能

GPSがある前提ではあるが，自分の位置を労せずに把握して地図上で確認することができる。

（２）ナビゲーション

ナビタイムや，EZナビウォークのようなサービスに代表されるナビゲーション機能がある。

もちろん，地図を使う目的によってメリットは変わってくるだろう。とにかく，アナログとデジタルの地図には色々と特徴があるわけで，両方の良いところを認識した上で両方の地図を活用してきたいものである。

文庫判 東京都市図 (文庫判)
posted with amazlet at 08.06.10

昭文社
売り上げランキング: 28902

Amazon.co.jp で詳細を見る





文庫判 神奈川都市図 (文庫判)
posted with amazlet at 08.06.10

昭文社
売り上げランキング: 105286

Amazon.co.jp で詳細を見る

ソフトバンクモバイルは2008年6月4日、「iPhone」を年内に国内で発売すると発表した。iPod touchユーザとしては，このインターフェイスが携帯電話で実現するということで，どこでもあの直感的なユーザインタフェイスでネット上をブラウジングできることに，今から非常に楽しみにしている。

iPhoneの日本の携帯市場へのインパクトについては，いろいろなところで論評されているので，その辺についてはコメントしないが，やはり位置情報の可能性を注目し続けている私にとって，期待したいのはGPSの搭載である。一部報道では，iPhoneにはGPSが付いていないのではないか，という噂もあるようだが，GPSの搭載は期待したいところである（6月10日は分かっているのだけど）。

以前のエントリで書いたように，どんな場所でも位置情報を取得でき，その位置情報をキーとしてネット上を検索し，必要な空間情報やテキスト情報等が可視化され，意思決定に使える情報にすることが重要と考えている。iPhoneを使い，GPSで位置情報を取得できることで，直感的なユーザインタフェイスでブラウジングし，位置情報から有益な情報を，携帯回線を通したインターネットから，取得できるようになるだろう。

あとは，位置情報をキーとして取得した情報の可視化をどうするのか，ということになる。その究極的な形としては，Google EarthのiPhoneへの搭載，ということになるかもしれない。既に技術的には可能なようで，iPhone earthというのが，Where 2.0で発表されて話題となったらしい。ブラウザ上でGoogle Earthが使えるようになったこともあり，今後はiPhoneのような高機能な携帯端末でも，3次元で地理空間情報が可視化されるソフトウェアが登場するだろう。そして，位置情報をキーとして情報の検索→バーチャルな3次元空間上への可視化，というサービスは，いつでもどこでも行えるようになるのは近いかもしれない。

とうとうGoogle Earthがブラウザで見られるようになった。これは，Googleの地理空間情報に関する戦略でターニングポイントかもしれない。

Google Earth APIはJavaScriptベース。サイトに組み込んだGoogle Earth上へのマーカーや線、3Dモデルなどの追加やカメラのコントロール、Google Skyモードへの切り替えなどが可能で、Google Earthを基にした3Dアプリケーションが自由に開発できるようになった。また、Google Maps API使用サイトのスクリプトに1行加えるだけで、サイトを簡単に3D化できるという。 「ブラウザ版Google Earth」が可能に――GoogleがAPI公開 ITmedia

GoogleがKeyholeを買収してGoogle Earthを公開した際，Google MapsとEarthの2つで地理空間情報のサービスを続けていくことに，違和感を覚えていた。というのも，Google Earthを利用するためには，ブラウザから離れて別アプリを起動する必要があり，一手間かかってしまうからである。また，独自ソフトウェアであったためAPIなどはなく，拡張性が無いことも，3次元の地理空間情報の可視化ソフトとしては優秀であっても，違和感を覚えたのである。しかし，今回のようなGoogle Earth APIの登場によって，すべてをブラウザベースで行うGoogleの戦略は一貫していることを実感した。

思うに将来は2D (Google Maps)はなくなり，3DのGoogle EarthのみがGoogleの地理空間情報サービスとなる時代が来るのではないだろうか。2次元の地図は，紙での表示しやすさや紙地図の携帯の容易さから，主流であるに過ぎないと思う。ただし，3次元の表示が可能なディスプレイ上であるならば，むしろ情報量が多く，視覚的に直感的である3次元の方が地理空間情報を用いて何らかの意思決定をするためには有効だと思う。

すぐにはGoogle EarthとMapsは統合することは無いだろうが，最終的にはブラウザ上で動くEarthへ統合されていくのではないかと思っている。

以前，MovaTwitterの位置情報とGoogle Mapsを組み合わせたブログパーツを作成した。

Twitter + Google Maps ウィジェット
http://www.tagchan.net/twitter_widget.html

今までは地図はGoogle Maps APIを使っていたが，今回はGoogle Static Maps APIを用いることにした。以下のURLでこの作品を紹介している。

Twitter + Google Static Maps ブログパーツ
http://www.tagchan.net/twitter_widget_v2.html

Google Mapsのときは，地図のアイコンはTwitterのアイコンを使用したが，Google Static Mapsでは，アイコンを使うことができないので，デフォルトのアイコンを使用している。

スクリプト自体はシンプルなので，改善しながら使っていただけると幸いである。

インターネット地図のカンファレンスである，Where2.0がアメリカのカリフォルニアで開催中だ。この内容については，マイコミジャーナルに詳しくレポートされており，参考になる。

Where 2.0 - 「Geowebの世界に自分の居場所を反映」が今年のテーマ
http://journal.mycom.co.jp/news/2008/05/15/007/

この記事によると，今年のテーマは「ユーザーのロケーション」なのだそうだ。パソコンのブラウザで地図サイトから検索するのではなく，ユーザのいるいろんな場所で，その場所に関連するユーザの一番欲しい情報を入手することを目指すのが，このテーマの意味するところなのだと思う。

その場所において，ユーザの欲しい情報を入手するためには，情報を必要としている人がどこにいて，その場所に関連した情報を，ユーザがいかに簡単かつ適切に探し出すのかが重要となる。従って，ユーザのロケーションが重要であることは当然であるし，必要な情報が位置情報と関連付けられていなければならない。GPSや無線LANによて，ユーザ自身の位置の特定は容易となりつつある。あとは，いかに情報や物に対して簡便に位置情報を与えていくのか，が課題となるだろう。この課題さえ克服すれば，地図が必要不可欠な媒体となり，地理空間情報の技術はインターネットの必要不可欠なコンテンツなれる可能性を秘めているのではないかと思うのである。

上記記事では，GoogleのJohn Hanke氏（Keyhole社の創業者）が，「ジオグラフィは、世界をデータとして見るうえで有用なレンズだ」と述べたことが紹介されている。レンズどころか，眼となる可能性もあるだろう（これは言い過ぎかな...）。

Google関連としては，「Geo Search API」がどんな感じなのか気になるところだ。あとは，ESRI社との連携が発表されたのも注目に値する。ESRI社はGoogleが地理空間情報関連に参入する前は，一番大きな勢力だった。ESRIとGoogleは，旧勢力と新勢力のような関係だった。そんな2社が連携を発表する意味は大きい。というのも，ESRI社の地理空間情報のフォーマットは，これまでデファクトスタンダードだったのだが，Googleと連携することで，KMLとのやりとりが容易になることが予想される。一昔前の地理空間情報は，ESRI社のフォーマットが多かったこともあるし，もともとESRI社もウェブ上でのGISを進めてきた経緯もあることから，いっそう多くの地理情報がKMLを通して，インターネット上に出回ることになるだろう。

日本では，位置を表す手段として地域メッシュコードを使用する場合がある。地域メッシュコードは1次メッシュ(4桁)，2次メッシュ(2桁)，3次メッシュ(2桁)を繋ぎ合わせたコードである。

例えば，気象庁の気候値メッシュは3次メッシュの解像度である。また，防災科研の地震ハザードステーションの地震動予測地図なども3次メッシュの解像度である。何かと3次メッシュで集計されたデータが多い。

緯度経度の座標値から，地域メッシュコードへ変換するサイトはいくつか存在する(例1，例2)。しかし，マッシュアップ可能なタイプは見当たらなかった。そこで，緯度経度から地域メッシュコードを計算するAPIを作成した。

地域メッシュコードAPI
http://www.tagchan.net/sample/mesh_code.html

いままで作ってきたAPIと同様に，Google Mapsとマッシュアップしている。

※現在，サーバーは停止しています。

最近は，昔の空中写真や地図の公開が流行（？）している(リンク1, 2, 3)が，とうとう明治時代の地図が公開されるようになった。これは非常に興味深い。

歴史的農業環境閲覧システム
http://habs.dc.affrc.go.jp/index.html

こちらのシステムは，独立行政法人農業環境技術研究所（農環研）が公開したシステムで，迅速測図という地図が公開された。迅速測図は，近代的な地図測量が始まって間もない明治初期ころから中期にかけて測量・発行された地形図である。陸軍が作成したもので，縮尺は2万分の1である（この辺の説明は，マップショップが詳しいかも）。

サイト自体は，オープンソースのWebGISを使っているようで，サイト上で地図が簡単に閲覧できる。一応，OGCに準拠したWeb Mapping Service (WMS)によって地図画像が描画されているようだ。以下のURLで地図画像をリクエストできる。

http://habs.dc.affrc.go.jp/geowebcache/wms?WIDTH=256& SRS=EPSG:4326&LAYERS=rapid_latlon_2&HEIGHT=256& STYLES=&FORMAT=image/png&SERVICE=WMS& VERSION=1.1.1&REQUEST=GetMap& EXCEPTIONS=application/vnd.ogc.se_inimage& BBOX=139.63623,35.4418,139.64721,35.45288

（細かい説明はしないが，「EPSG」は投影法コードである。4326はPlate Carree図法である。このコードを変えてみたが，4326しかサポートしてないようだ。メルカトル図法の54004ではエラーとなる。）

上記URLの場合の地図画像はこちらである。関内付近である。

さらに，FAQによるとGoogle Earthのkmlファイルを読み込むこともできる。Google Earthのメニューで「追加 > ネットワークリンク」を選択し，
「http://habs.dc.affrc.go.jp/kml/doc.kml」
を入力する。すると，簡単にGoogle Earthの写真地図と比較できる。また，透過表示ができるので，位置あわせの精度も確認しやすい。

Google Earthを見ると，かなり位置ずれは発生しているようだ。図化は写真測量ではなく，平版測量だったこともあるのだろう。迅速測図は簡単な方法で幾何補正されており，方法によっては精度が上がる可能性もあるだろう（リンク）。とはいえ，数十メートルの誤差は生じているため，最新の地図とぴったり重ねることは難しいだろう。

したがって，最新の地図と比較する際は，数十メートルのずれがあると認識して観察する必要がある。Google Earth上でピンポイントで位置を決めて，迅速測図をオーバーレイさせてそのポイントが正確であると判断してはいけないのだ。

昔の地図になると，位置精度の問題は必ずつきものであるが，公開する価値は非常に高い。国土地理院もそろそろ過去の地形図を公開しても良いと思うのだが...。

地図や地名のことをテーマにした本を世に送り出す第一人者である今尾恵介氏の本「地名の社会学」が出たので，早速購入してみた。ちなみに，Amazonのお勧め機能のおかげで，この本の存在を知ることができた。Amazonに感謝する次第である。

この本では，これまでの今尾氏の本でみられたように，地名に関するトリビア的な話や小ネタが満載である。よく調べたなあと関心してしまう内容がほとんどである。第5章の「駅名を分析する」では，駅名は旧地名がかなり残っていることを知ることができた。個人的には，いつも通過している小田急線の鶴川駅が，「鶴見川」の省略形だということは知らなかった。

地名の由来は，各所で非常にオリジナリティーがある。それが時代を経て，社会制度や政治的な影響を受けて，消滅・拡大・変化した過程が，各章のどのトピックについても，詳細に調べられている。そして，場所にそぐわない地名が各地に誕生し，オリジナリティのある地名が消滅することを，筆者が憂いている。しかし，筆者がここまでこだわって地名の変化を詳細に調べる意義は何だろうか。

その理由は，この本の最後の最後に登場する。それが本エントリのタイトルである，「地名は過去への道標」である。このことばを本文で言及した後，筆者は次のように述べている。

われわれの先祖たちは日本中の至る所の土地を舞台に開墾して米や芋を作り，木を伐り，獣を追い，神を祀り，またある時は戦い，さまざまな活動を続けてきた。しかし，それらの一つひとつの活動は地名という見出しを付けることによって初めて「歴史」と認定され得るのである。その見出しが失われた時，無数に積み重ねられたこれらの活動は，現在と繋がる手がかりを失ってしまう。 （本文253ページ）

上の引用した文章の内容は，本を読んでいるうちに，薄々感じてくるのだが，最後にこの一文で「そうだよね。」と，納得させられるわけである。私の意見としては，上の引用のような主張を第1章で行うべきだったのではないかと思う。最初に筆者の問題意識を共有できていれば，鶴川が鶴見川だったような内容も，単なるネタではなく，読者の捉え方が違ってくるのではないかと思うのだ。

筆者の問題意識が共有できると，自分の住んでいる所の旧地名はどうだったのか，知りたくなるのではないだろうか。しかし，現状では旧地形を簡単に調べる方法はない。過去の地名をデータベース化するなど，過去の地名を調べやすい環境を整備することの必要性を感じるのではないかと思う。この場合，残念ながら過去の空中写真を眺めるだけでは不十分である。古地図を公開する意義はそこにあるのだと思う。

地名の社会学 (角川選書)
posted with amazlet at 08.12.24
今尾 恵介
角川学芸出版
売り上げランキング: 319759

おすすめ度の平均:
冗長で読みづらい

Amazon.co.jp で詳細を見る

Google Earthの登場によって、有名になったKML(Keyhole Markup Language)が、地理空間情報の標準化団体であるOpen Geospatial Consorｔium (OGC)によって、オープンスタンダードとして承認されたことが発表された。いくつかのIT系ニュースサイトでは報じられているが、ソースは以下にある。

OGC announced the approval of the OpenGIS® KML Encoding Standard (OGC KML), marking KML's transition into an open standard which will be maintained by the OGC. Developers will now have a standard approach for using KML to code and share visual geographic content in existing or future web-based online maps and 3D geospatial browsers like Google Earth. OGC® Approves KML as Open Standard

オープンスタンダードについては、こちらの説明を参照されたい。

先日、MicrosoftのLive Search MapsやVirtual EarthがKMLに対応したことが報じられたが、KMLがオープンスタンダードへ向かっている流れがあったことに対応していたのだろう。

昔からある地理情報システムの分野では、デファクトスタンダードとしてシェープファイル(shp)が知られているが、誰もが簡単に使用できるわけではない。KMLは、Microsoftの地図やGoogle Earthで読み込み可能なわけであるから、インターネットに接続したユーザなら誰でも使える地理空間情報のデータ形式となる可能性が高い。今後、KMLは地理空間情報をインターネット上を融通させるデータとして活躍することは確実だろう。

Googleに買収される前のKeyhole社のころからKMLは存在していたが、その当時は、KMLの仕様はコンフィデンシャルだったと記憶している。そのような当時を考えると、オープンスタンダードまではあっという間だったと感じる。

久々にMicrosoftの地図ネタが2つある。

1. KMLファイルをサポート

新版の最大の特徴の1つは、Live Mapsのコレクションを、KML、GPX、GeoRSSファイルとしてエクスポートし、ナビゲーションシステムに直接ロードできるようになったことだ。コレクションは、ユーザーが地図上に書き加えた情報とレストランや映画館のような個別の店舗情報をまとめて保存したもの。例えばコレクションをKMLファイルとして出力し、Google Earth上にマップすることも可能になった。

MS、Live Mapsを刷新――KMLファイルにも対応 (ITmedia News)


KMLのほかに，GPSを使用する際に使うことの多いGPX，RSSに位置情報を付けるGeoRSSもサポートした。これによって，これら3つのファイルの読み出し(インポート)と書き出し(エクスポート)が可能となった。

データに互換性があることは，とても重要なことなので，このサポートは評価に値する。今後もそのほかの標準化された地理空間情報のデータフォーマットがサポートされることを期待したい（もちろん，Google Earthにも）。

2. 都心の3D表示がスタート

マイクロソフトの地図サービス「Live Search　地図検索」ベータ版がパワーアップした。日本も3D機能に対応し、立体的な地図を表示できるようになった。表示地域は東京都中心部からスタートし、今後大都市や観光都市に拡大していく予定だ。

MSの地図検索サービス、日本が3D表示機能に対応 (CNET Japan)


とうとう日本で3D表示がスタートした。既に3D表示ができるGoogle Earthとは違って，ブラウザ上で3D表示が可能である。つまり，Google Earthのような別ソフトを起動する必要はない。早速試してみたが，都市の大きな建物には壁面にテクスチャが貼ってあり，Google Earthのグレーの箱ではない。しかし，壁面のある建物を全部整備するのはとても無理な話だろう。目立つ建物しか3次元表示しないのだろうか。また，非力なPCではとても動作が遅くなり，不満が残る結果となった。

先月，昭和30年代の空中写真地図がgoo地図に登場したことを紹介したが，早くも昭和20年代の空中写真が登場した。東京23区では，昭和22年，昭和38年，現在という3時期の写真地図を閲覧可能となったわけだ。昭和20年代の空中写真は，米軍が撮影したものであり，戦後すぐの土地利用を知る貴重な資料である。さっそく，3時期の変化を観察してみることにした。

今となっては23区は，ほとんどが市街地化しているが，都心から少し離れた外側の住宅街でも，昔は田舎の風景が広がっていたらしい。今回，小田急線祖師ヶ谷大蔵駅，千歳船橋駅，環状8号線のあたりを観察してみる。

ちょうどこのシーンでは，南北を環状8号が走っている。そして，東西に小田急線が通っており，左に祖師谷大蔵駅，右側に千歳船橋駅がある。昭和22年は環状8号はなく，田畑が多いことがわかる。昭和38年になると，環状8号の工事がはじまったように見える。最新の空中写真では，環状8号が通っていることが確認でき，周辺はほとんど住宅街となっている。

• 詳細な地形データと重ねてみると面白いかも

このように，土地利用が変化してきたことが容易に観察できるわけだが，先日紹介した基盤地図情報の詳細な地形データ（5m DEM）と重ねてみるとおもしろいだろう。かつて水田で，住宅街に変わったところでは，低地だったり，谷沿い地形だったりする場合が多い。

• 23区以外の米軍撮影空中写真

23区以外は，地図として重ねられないが，国土地理院が国土変遷アーカイブというサイトで公開している。どの範囲まで公開しているのかはよく分からないが，相当な数の空中写真が閲覧できる。なお，この空中写真は，地図に投影するための変換がされていない，生データである。時系列にデータがあるので，土地利用の変化は十分に比較できる。

例えば，SFC（湘南藤沢キャンパス）周辺の昭和22年撮影の空中写真も見ることができる。川沿いの低地は水田，あとは畑で，谷戸地形の斜面は樹林地となっており，住宅街はほとんどない。今でもSFCは田舎であるが，昔はど田舎だったのだ。

【2009年2月14日追記】
基盤地図の読み込みは，こちらの記事をご覧ください。
http://www.tagchan.net/blog/2009/02/gsi_dem_gis.html
--

前回のエントリーで紹介した，国土地理院の基盤地図情報のサイトだが，さっそく5m DEM(地形データ)を解析が容易なバイナリ形式の画像データとしてインポートしてみることにした。おそらく，GISソフトウェアのベンダーが今後インポーターを出すと思うので，一時的な方法となるだろう。

基盤地図情報では，JPGIS形式とGML形式の2つのデータ形式があり，ダウンロード可能である。どちらも，XML形式のようなテキストデータである。今回，テキスト処理が容易そうなGML形式のデータを利用した。処理は，Linuxのコマンドとシェルスクリプト，C言語を利用した。

データは，2次メッシュを10x10=100つのメッシュに分割されており，それぞれ拡張子がxmlのテキストデータとなっている。このテキストデータを１つずつ読み込み，バイナリデータへと変換させ，ENVIというリモートセンシングのソフトウェアのヘッダーファイルを出力するようにした。従って，ENVIを持っている人は，位置情報が入った形でデータを読み込むことが可能である。他のリモートセンシングのソフトウェアでも，インポートできるだろう。

今回作成したシェルは次の通りである。細かい点は説明しないが，データ内から，画像のサイズや各ファイルの四隅の緯度経度を読み込み，標高値のデータの適すとの部分を抽出し，バイナリに変換する。バイナリへ変換するC言語のプログラムのソースコードはこちらに公開した。

ENVIを持っていなくても，フリーのソフトであるGDALを使うことで，任意の形式に変化可能だ。gdal_translateというコマンドで可能である。また，今回のスクリプトでは，データはタイル状に作成されるため，別途繋ぎ合わせる作業(モザイク)を行う必要がある。GDALでは，データを繋ぎ合わせることも可能である。

各データを繋ぎ合わせて，Geotiff形式に変換し，ArcGISに表示させた結果は以下の通りである。場所は23区南部にあたる地域であり，メッシュのコードで表現すると，533935である。

青いほど低く，赤いほど標高は高い。標高の範囲は０mから50mとなっており，それほど地形の起伏がある地域はないが，とても細かく表現されていることがわかる。そして，とある衛星画像と重ねたところ，水域はほぼ重なっており，ちゃんとインポートできたと思われる。しかし，データの上部には，変な模様が入っている。元のデータを見ると，標高値と-9999の値が交互に並んでいることが分かり，元のデータに問題があると考えられる。

特にアナウンスは無かったが，2008年4月1日から国土地理院が基盤地図情報の公開を開始した。

基盤地図情報
http://www.gsi.go.jp/kiban/index.html

このサービスの概要については，FAQを参照すると良い。要するに，国土地理院や地方自治体が協力して，基盤地図情報を整備していき，誰もが使用できる仕組みを作ったのである。もちろん，使用の際は今までと同じで申請が必要なケースもあるが，このようなデータに簡単にアクセスできるようになるのは非常に重要な事である。現段階では，限られた場所しか整備されていないが，次第に整備範囲は広がっていくだろう。

整備されたデータは，基盤地図情報のサイトでダウンロードできるビュアーで閲覧可能で，ESRI shpファイルに変換できる機能があるようだ。

基盤地図情報で一番注目していることは，地盤高のデータであるDEMが5mの空間解像度で整備されたことである。5mのDEMは一部地域でCD-ROMで販売されていたが，こちらのサイトで無料でダウンロードできるようになった。この5mのDEMは，航空レーザ測量による詳細なデータから作成されており，従来の50mのDEMよりは格段の空間解像度が向上している。なお，50m DEMは2万5千分の1地形図の等高線から作成されたものであるため，地図作成者が空中写真から立体視して作成している。一方，5m DEMは，航空レーザ測量のたくさんの点データを，半自動処理(フィルタリング)によって作成しているデータである。

2008年3月26日から，気象庁が竜巻や突風に特化した注意報を発令するようになった。気象庁のサイトでは，気象情報でこの情報を見ることができる。都道府県単位なので，気象情報のページから都道府県を選択する必要がある。

なお，現在記事を書いている2008年3月26日21時15分の時点では，鹿児島県で竜巻注意情報が発令されていた。以下の画像は，気象庁のサイトで発表されていた竜巻注意情報のキャプチャである（最新の情報は気象庁のサイトで必ず確認を！）。

竜巻や突風など，一度の被害の程度が大きい災害であるため，このような情報の発令は社会的ニーズは高いと思われる。しかし，的中率は「1割前後」である。

ただ、現時点で情報の的中率は１割前後と低く、毎回避難が必要とはいえない。同気象台の楯嘉淳（たて・よしあつ）気象情報官は「急に暗くなったり雷鳴が聞こえたりしたら、頑丈な建物に避難してほしい。名古屋なら地下街に逃げ込むのも有効だ」と助言する。

竜巻情報、きょうから開始　気象庁「予測精度アップが課題」　（中日新聞）

どういう検証方法で的中率が1割なのか，手元に情報がないためにどう解釈すれば良いかわからないが，1割という数字だけで，この発令される情報の価値を判断するべきではない。

竜巻や突風の起きるような，天気の条件や積乱雲等は，観測したり予測したりできるようになってきたものの，「いつ，ここに竜巻や突風が起きる」というピンポイント（局地的な）な予測は困難であるし，将来も予測は難しいだろう。このように，竜巻や突風の予測の難しさと，このような現象の局所性を考えた場合，竜巻注意情報は竜巻や突風が発生するリスクが高まったことを知る手段として有効と考えるべきだろう。

例えば，自分のいる地域で竜巻注意情報が発令された場合，こまめに雨雲レーダを確認して発達した積乱雲の動きを注意するとか，空の雲の色や，雲の動き，風の変化に気をつけるなど，が挙げられるだろう。

なお，気象庁のサイトに，竜巻注意情報の説明があるので，一読することをお勧めする。

リーフレット「竜巻から身を守る～竜巻注意情報～」
http://www.jma.go.jp/jma/kishou/books/tatumaki/index.html

写真に位置情報を付ける方法は，今までいろいろと試行錯誤してきたが，とりあえずまとめてみようと思う。基本的に，下記の位置情報を付ける方法はお金をかけていない。以下に示す3つの方法で，写真から位置情報を付ける方法がだいたいカバーできていると思う。

【追記2008年3月25日午前10時半】
このエントリーは、コンパクトデジカメや一眼レフカメラを想定している。携帯電話のGPSを使う方法もあるが、今回は触れていない。

1. 写真の共有サイトで位置情報を付ける方法

Flickrにアップロードした写真に対して，位置情報のタグであるGeotagを付ける方法である。これは，既に以前のエントリで紹介している。

http://www.tagchan.net/blog/2007/04/flickrgeo_tag.html

Bookmarkletを使うことで，Flickrのサイト上でGoogle MapsでGeotagを付けることができる。しかし、この方法の場合は，Exifに位置情報が与えられてるわけではなさそうだ。FlickrのサイトからGeotagを与えた写真をダウンロードしてみたが，Exif情報はそもそも付与されていない。

2. GPSから位置情報を付ける方法

SonyのGPS-CS1Kなどでは，写真と位置情報を付けるソフトウェアが付属している。また，Macユーザの場合は，GPSPhotoLinkerというフリーウェアがあるらしく，GPSのファイル形式であるGPXと写真の撮影時間から，写真のExifに位置情報を付けることができる。

WindowsユーザがGPSから写真と関連付けを行う方法としては，カシミール3Dを使うのが最も楽である。このソフトウェアでは，GPSデータの読み込みや書き出しができる。筆者はGarminでしか試したことがないが，GPSレシーバを直接繋いでデータをダウンリンクすることは可能だ。

カシミール3Dのプラグインである，「デジカメプラグイン」をインストールすると，カシミール3D上で読み込んだGPSとデジカメプラグインで読み込んだ写真を，GPSによる測位された時間と撮影時間で関連付けることができ，Exif情報にGPSの位置情報を付けることができる。

3. ソフトウェア上で位置情報を付ける方法

Googleが出している写真管理ソフトであるPicasa 2では，Google Earthを使ってジオタグを付ける機能がある。「ジオタグ」としているが，Exifに位置情報をつけてくれるのである。PicasaからGoogle Earthが起動し，位置情報付けることが可能である。

ただし，Google Earthなので，地図画像が表示できず，写真の撮影地点を特定するのが難しい。そこで，Google EarthにGoogle Mapsの地図画像をオーバーレイするkmlを利用し，空中／衛星写真だけでなく地図の情報も利用して，位置を特定することが容易にできるようになる。

Flickrなどのオンライン上で位置情報を付けるのは良いのだが，Flickrは厳選(?)された写真しかアップロードされないため，アップロードされなかった写真には位置情報がつけられない。しかも，Exif情報をつけてダウンロードできないため，結局のところ，手元のデータには位置情報はつけられない。

オフラインでExifに位置情報がつけられれば，Flickrではアップロードする際に自動的にGeotagをつけてくれるらしい（リンク）。なので，オフライン，つまり自分のPC上で写真のExifに位置情報をつけられることがベストということだ。というわけで以下がまとめである。

• 写真に位置情報を付ける方法

GPSの位置情報を使う場合：
カシミール3D+デジカメプラグインを使ってExifに位置情報を付ける。

GPSがなくて地図から位置情報を取得する場合：
Picasa2 + Google Earth(Google EarthにGoogle Mapsの地図画像をオーバーレイするkml)でExif情報に位置情報を付ける。

Yahooが昭和30年代の古い地図の公開をはじめたり，過去と現在の空中写真が比べられる書籍を紹介したが，goo地図が東京23区の昭和30年代の空中写真を公開をはじめた。しかも無料で。

NTTレゾナントは19日、「goo 地図」において、昭和38年に東京23区で撮影された航空写真をスクロール地図上で無料公開した。翌39年開催の東京オリンピックに向けて建設中の代々木体育館や首都高速道路などの様子がわかるという。

昭和38年の東京23区内の航空写真、「goo 地図」で無料公開 (Internet Watch)

というわけで早速goo 地図を訪れてみた。「古地図」というタブをクリックすることで，昭和38年の空中写真に切り替わる。当然モノクロである。昔の地図は古地図と呼ぶが，昔の空中写真＝古地図というのはちょっと違和感がある。だが，考えてみると「古地図」のように，過去の空中写真を1つの単語で言い表す適切な言葉が無い。

ざっと古地図を眺めてみると，23区の周辺も含まれている。例えば，23区の南側は川崎市だが，武蔵小杉なども入っており，外側もある程度の範囲で含まれていることが分かった。東側では，浦安市の一部が含まれている。特に興味深いのは，東京ディズニーランドのあたり。

この図は，昭和38年空中写真と最新地図の比較である。ディズニーランド付近は昭和38年は埋め立て工事すらはじまっておらず，砂浜または海だったことがわかる。ディズニーランドの北側の住宅街も，砂浜だったようだ。他には，羽田空港も埋め立ての規模が全然違うのでおもしろい。

goo地図への要望としては，地図のウインドウを横に並べるようにして，過去の空中写真と最新の地図や空中写真を比較できるようなインターフェイスも作って欲しいことである。

なお，goo地図は上記Impressの記事によると，戦後間もない頃に撮影された米軍撮影の空中写真も，2008年4月以降に公開予定とのこと。これも期待できる。古い地図や空中写真の公開に関しては，gooがYahoo!よりもリードした形となった。

過去の地図や空中写真に関しては，

http://www.tagchan.net/blog/2007/11/post_56.html
http://www.tagchan.net/blog/2008/03/yahoo_old_map.html
http://www.tagchan.net/blog/2008/03/past_aerial_photo.html

で述べているように，積極的に公開していくべきであると主張してきたが，意外と早い時期に，誰でも容易に閲覧またはアクセスできる時期が到来しそうな予感がする。

Wikipediaのように，参加型で地理空間情報を収集していくサイトの日本語版が登場した。

OpenStreetMap Japan
http://www.openstreetmap.jp/

OpenStreetMap(略称OSM)は道路地図などの地理情報データを誰でも利用できるよう、フリーの地理情報データを作成することを目的としたプロジェクトです。自由に使えると思っている地図の多くが実は法的・技術的に問題があり、人々がクリエイティブに、生産的に、あるいは今まで予期しなかった方法でそれを利用する事を妨げているため、このプロジェクトは開始されました。

一般に出回っている地図には無い情報について，地図化していくことに大変意義があると考える。

しかし，なんでもかんでも地図化してくことには問題があると思う。特に，道路や鉄道，河川などのインフラなどの基盤的な地理空間情報は，このような参加型で作成する地理空間情報として適切だろうか。おそらく，基盤的な地理空間情報については，データの空間的な精度および属性情報の精度に対する信頼性を確保することが難しいだろう。

そもそも，自分で線や点を描く程度であれば，背景の地図を利用する程度であることから，Google MapsやYahoo! 地図のAPIを使えば良いのである（APIの場合は商業利用の際の問題が発生しそうだが，商業用であればそれ用のサービスが地図会社を中心に存在しており，それを使えばよいはずだ）。

基盤的な地理空間情報は，高度な技術による，非常に高い位置精度を持った情報として作成されている（そのため，地図の作成は人の手でないと不可能）。一方で，参加型というのは，情報を集約することには役立つが，非常に高い位置精度をも克服することは不可能なのである。従って，基盤的な地理空間情報を，このような参加型のアプローチによって作成することは，現段階での技術水準では適切ではない。

というわけで，私が参加型地図に期待したいところは，「誰もが思いつかなかった地理空間情報が新たに生まれ，それがものすごいスピードで，多くの人によって更新および追加され，カバーする範囲が広まっていくこと」である。参加型のアプローチによる地理空間情報の収集は非常に興味があるので，今後も注目していきたいと思う。

有料かつ東京23区限定であるが，インターネットで過去の地図を閲覧できるようになるらしい。

昭和30年代の東京にタイムスリップ――。ヤフーは、昭和30年代前半に作製された地図や航空写真をインターネットで閲覧できるサービスを始める。当時話題になった出来事や事件が起きた場所なども写真や読み物と一緒に地図上で紹介する。ヤフーの有料会員になると、利用できる。

　新サービス「昭和レトロ地図」は、17日から1年間公開する。ヤフーは複数の収集家などの手元に紙で残っていた昭和30（1955）年作製の地図約60 枚を収集。1枚ずつデジタル化し、東京23区の地図を1枚にまとめた。地図は「1万分の1」と「2万5000分の1」の二つの縮尺を用意。いずれもサイト上でスクロールして閲覧できる。

「ヤフー、昭和30年代の東京地図をネットで再現」 Nikkei net (2008/3/11)

他に情報が無いため，このサービスの詳細は不明である。ただ，有料の理由としては，デジタル化して閲覧できる見栄えにするために，コストがかかったからではないかと推測される。有料ではあるが，過去の地図を容易に閲覧することを可能にした点は評価したい。

過去の地図を閲覧したいというニーズは，結構多いのではないかと思う。例えば，2007年に横浜市の3千分の1地図が公開されて話題となった。また，上記のYahoo!でも，過去に江戸時代と明治時代の地図の公開をしている(リンク)。今回のYahoo! Japanが行う予定の古地図を配信するサービスは，期間限定の企画物にせず，何年後かには無料で公開して欲しいと思う。

また，ほとんどの地図に当てはまることであるが，日々更新される地図の過去のデータを残しておき，「5年前の地図」や，「30年前の地図」といったレイヤーが登場することを要望したい。特に，国土地理院は明治時代からの5万分の1や，2万5千分の1の地形図が蓄積されているので，是非ともデジタル化して公開して欲しい。そうすることで，過去の土地を知ることができ，自然災害のリスクを知ることもできるだろうし，研究目的，総合学習の資料にも役立つはずである。

Twitterをはじめて数ヶ月経過したが，MovaTwitterが非常に便利だ。その理由は3つある。それは，(1) 携帯で投稿が可能，(2) 携帯電話のGPSから取得した情報から，「L:住所」という位置情報を簡単に付けることができる点，(3) 携帯写真をはてなフォトライフへアップロードできる点，である。

MovaTwitterで取得した位置情報，投稿した写真を，自分のウェブサイトに表示することができるブログパーツを作成した。

Twitter + Google Maps ウィジェット
http://www.tagchan.net/twitter_widget.html

「L:住所」が入っている場合，「住所」の部分だけ抽出して，Google Maps APIのGeocoderを使って，緯度経度を推測する。それを使って，Google Mapsの地図上に，Twitterに登録しているアイコンでオーバーレイすることができる。

MovaTwitterにアップした写真については，エントリ（つぶやき）に表示されている，はてなフォトライフの画像のURLを抽出し，imgタグで画像表示をさせている。

つぶやきのみ，つぶやき＋写真，つぶやき＋位置情報，つぶやき＋写真＋位置情報，という全てのケースが対応している。

今後の課題としては，時系列表示を可能にすることと，Google Static Maps APIの利用である。

前エントリーで，Google Static Maps APIを紹介したが，パラメータを打ち込むのが面倒なので，Javascriptを使って，画像URLを生成するスクリプトを作成した。

Google Static Maps APIの画像URL生成
http://www.tagchan.net/google_static_map.html

工夫した点としては，Google Maps APIのジーコーダーを使用した点が挙げられる。住所や駅名などから，緯度経度を取り出して，地図の中心とマーカーの座標としている。以下は，「富士山」として作成した例である。

今までのGoogle Maps APIは，ズームができたり移動がマウスでできたり，動的な地図だった。今回，パラメータを入力することで画像を出力する，Google Static Maps APIが登場した。Staticとは「静的」という意味であり，Javascriptは使わずにimgタグで貼り付けることができるので，携帯サイトなどで威力を発揮するだろう。また，地図を表示する場合に，店舗の地図を表示するケースなど，わざわざ動的な地図である必要が無い場合もあるだろう。そういう際には，Google Static Maps APIは便利な部分もありそうだ。

以下が出力例。パラメータの説明をしていく。

center=35.658127,139.684446
地図画像の中心座標。緯度，経度。

zoom=16
地図のズームレベル。0から19の範囲。数字が大きいほど大縮尺となる。

size=200x200
地図画像のサイズ。単位はピクセルである。

maptype=mobile
背景地図のタイプ。mobileとroadmapがある。

markers=35.658127,139.684446,bluea
マーカーの座標とアイコン。緯度，経度，マーカー色＋アルファベット。
マーカー色は，blue，red，greenがある。そして，マーカー内に小文字のアルファベットをという文字を入れることができる。blueaは，青色マーカーに「a」というアルファベットを入れることになる。このマーカーの設定が無い場合は，デフォルトの赤色のマーカーとなる。

マーカーは，複数置くことも可能である。「|」で区切り，緯度，経度，マーカー色＋アルファベットを追加することで複数にできる。

key=ABQIAAAANb5JuD4i3v_Isz_A_z4ipxTrwmVSgF6tOzG2piSiw3F-ORmacRQGqjoiQ55HzLvszowcXYUDT1mXwA APIのキー。もちろん，あらかじめ取得しておく必要がある。上記keyは当サイトのもの。

パラメータを入れるところは，昨年登場したGoogle Chart APIに近いと思われる。まだまだバリエーションは少ないが，今後は線や面も引けるようになるのではなかと思っている。

地図にいろいろ書き込めるサービスがMapionで始まった。このようなサービスは，地図を使った新たな情報発信手段としておもしろいのではないだろうか。

地図ガキ
http://labs.mapion.co.jp/chizugaki/

背景となる地図は，白地図かMapionで公開されている地図が選べる。そして，選択した地図に，四角形，三角形，円などの図形が描画でき，もちろん線も描画ができる。文字も入れることが可能だ。そして，完成したらブログに貼り付けができる。たったそれだけである。

地図上で図形や線を書き込んだ場合は，形状の修正はできないようだ。ただ，消しゴムで消すことができ，まさしく消しゴムで消したようになる。消しゴムツールで四角形を消した例が以下の図。

さらに，おもしろいのが，地図を拡大した場合，描画した図形や線も一緒に拡大されるのだ。上の図の消しゴムで消したところを拡大した状態が以下の図となる。

図形や線が描画されると，パワーポイントで描くような図形や線などのオブジェクトとは違い，画像になってしまうようだ。でないと，消しゴムツールで部分的に消すことができないだろう。

画像という方法も良いが，図形や線をオブジェクトとして残るような方法も考えてもらえるとうれしい。また，各図形や線などは，IllustratorやPhotoshopのように，レイヤー構造をもたせることができれば面白いのではないか。

てなわけで，道案内図みたいなものを作ってみた。これは私が下北沢駅から大学まで歩く道を示したものである。

Google Mapsには，マイマップという機能があって，地図上に線，点，面を描画することが可能である。ただし，Google Mapsのマイマップの方は，線，点，面を「地図データとして描画する」アプローチである。地図ガキの方は，地図データとして考えずに，ただ「地図に書き込む」という考え方である。

地図から情報発信する手軽さを考えると，「地図ガキ」のアプローチの方が有効な場合も多そうだ。

林野庁の空中写真の入手は，以前は日本森林技術協会で受け付けていたのだが，12月末で日本森林協会は空中写真業務を終了してしまった。そして，1月21日から別の業者が林野庁の空中写真の取り扱いをはじめた。以前は，林野庁撮影の空中写真の管理業務は，日本森林技術協会が随意契約で受託していたようだ。そのため，随意契約でなくした結果，別の業者に管理業務が移った形になったと推察される（まだもう一つ事情があるのだがここでは伏せる）。

そして，グリーン航業株式会社が，林野庁の空中写真の管理業務を受託し，この会社から空中写真が購入可能である。以下のサイトに詳細が掲載されている。ちょっと分かりにくいけど。

「空中写真関係」 グリーン航業株式会社
http://www4.ocn.ne.jp/~allgreen/shasinn-kannkei.html

「空中写真の入手方法」グリーン航業株式会社
http://www4.ocn.ne.jp/~allgreen/nyuushu-houhou.html

今回は空中写真の入手方法について説明しよう。

1. 林野庁撮影，地理院撮影の確認

まず，その対象地が林野庁撮影なのか，地理院撮影なのかを確認する必要がある。それには，次のサイトが参考となる。

「林野庁と国土地理院の撮影区域図」(社)日本林野測量協会
http://www3.ocn.ne.jp/~rinsokyo/html/0205.htm

2-1 林野庁撮影だった場合

いつ，どのくらいの縮尺で対象地が撮影されたのか，「標定図」から確認することができる。この図は，5万分の1地形図に，空中写真が撮影された航空機の撮影地点が○で示されている(例)。だいたい，1960年から1970年くらいから，5年おきに撮影されているので，年代を言えば，その時代に近い撮影の標定図を入手可能である。

入手するためには，5万分の1の地形図の名前を調べておく必要がある。その名前は国土地理院で確認できる。地形図閲覧サービスのこちらをまず表示させる。この「索引図による検索」の地図にメッシュ内に名前が入っているが，これは20万分の1の地勢図の名前である。ここで対象としている地域に対応するメッシュをクリックすると，さらに細かいメッシュ(8×8)が表示される。これが，5万分の1地形図の名前である。

年代と5万分の1地形図の名前を言えば，FAXでグリーン航業から標定図が入手可能である。その後の入手方法については，「空中写真の入手方法」のページを参照して欲しい。発注書へのリンクと価格が掲載されている。

2-2 国土地理院撮影だった場合

日本地図センターに詳しく掲載されている。標定図から探すことは基本的に同じだ。ただ，地図センターの場合は，ウェブで過去の撮影履歴まで確認できるので非常に便利だ。ただ，標定図自体は問い合わせを行って入手する必要がある。

「国土地理院空中写真 撮影範囲索引図」日本地図センター
http://www.jmc.or.jp/photo/gsi/index.html

PDFだが，1960年代からの撮影履歴が確認できる。

また，デジタル化した画像ファイルとしても空中写真は販売されている(リンク)ので，デジタル写真測量を行いたい場合はすぐに取り込むことができて便利である。

ちょっと時間差があるが，YahooとGoogleの地図の空中写真が更新された。

「Yahoo!地図情報」が航空写真を拡充、3社から提供受け「いいとこどり」(Impress)
http://internet.watch.impress.co.jp/cda/news/2007/12/25/17999.html

航空写真は、複数の大手測量会社から提供を受けて表示する。原則として東京23区と大阪市、名古屋市が国際航業、それ以外の東名阪主要都市がパスコ、全国エリアなどがデジタル・アース・テクノロジーとなり、エリアや縮尺によって切り替わって表示される。航空写真下部に表示されるコピーライト表記を見ることで提供元を確認できる。

「Google マップ」の航空写真が鮮明に、東京23区や大阪市などで (Impress)
http://internet.watch.impress.co.jp/cda/news/2008/01/18/18161.html

グーグルの公式ブログによれば、東京23区、名古屋市、大阪市の3地域で新たな画像を採用したという。これにより、航空写真の解像度が向上しただけでなく、再開発などで新たに建築された建造物も反映されたとしている。

2つの地図を比較してみよう。大きい建物で最近完成した23区内のものといえば，東京ミッドタウンが思いつく。Yahoo地図は国際航業，Googleは下部にはDigital Earth Technologyとなっている。

どちらも工事中である。ミッドタウンが完成する前の撮影のようだ。そして，良く見てみると色調はちょっと違うが，実は全く同じ写真なのだ。車の位置まで同じということは，元の写真は一緒である可能性が極めて高い。しかし，Googleの地図は国際航業の撮影とは書いてない。このへんの事情は謎である。

空中写真をいろいろ切り替えて比べてみると，YahooとGoogleの違いが見えてくる。23区に限定してみていくことにしよう。

Yahooは一番拡大した縮尺と，1段階縮小した縮尺において，国際航業の空中写真を使っており，23区は全て国際航業の空中写真となっている。そして，それより縮小した場合は，Digital Earth Technologyの別の空中写真に切り替わる（もちろん，縮小しすぎると衛星写真に変わる）。つまり，同じ縮尺では同じ会社の均質な空中写真を使用しており，縮尺を変えると空中写真のデータソース自体が変わるのだ。

一方，Googleの方は，最大に拡大して徐々に縮小していっても空中写真のデータソースは変わらない（もちろん，縮小しすぎると衛星写真に変わる）。そして，23区内で空中写真の色の違いがタイル上に発生している箇所があり，23区内でも別データを使う場合が発生しており，データが均質ではないのだ。つまり，場所によってデータソース自体が変わる。

まとめると，Yahooは縮尺で空中写真が変わるが，Googleは場所で空中写真が変わるのである。この2つのアプローチが良いのかは判断が難しい。Yahooのアプローチの方が見た目がきれいである。Googleのアプローチの方は，新しい空中写真が取得されれば，局所的に更新することができる。時間的な新鮮さから言うと，Yahooの場合は一括して更新するデータが揃うまでに時間がかかってしまうだろう。

というわけで，非常に細かい話ではあるが，YahooとGoogleの空中写真を比べた結果，細かい違いを認識することがきた。

ここ数日で，標高精度の問題は一気に解決となった模様。

精度不足の陸域観測衛星「だいち」、３月までに改善めど　(読売新聞)
http://www.yomiuri.co.jp/science/news/20080116i515.htm

精度不足で地図作りに支障が出ている陸域観測衛星「だいち」について、宇宙航空研究開発機構と国土地理院は１６日、新たに開発した画像調整ソフトなどを使い３月までに改善できるという見通しを、文部科学省宇宙開発委員会で報告した。

　高さの精度の誤差は、季節変動パターンから補正した結果、同日までに、地図作製に必要な誤差５メートルにまで下げることに成功した。画像にモザイク模様のように入るノイズは、国土地理院が開発した軽減ソフトによって改善が見込まれ、３月までにソフトを導入する。

なお，宇宙開発委員会での報告内容は，以下で公開されている。

陸域観測技術衛星「だいち」データの地図への利用 (JAXAプレスリリース)
http://www.jaxa.jp/press/2008/01/20080116_sac_daichi.pdf

国土地理院が問題があると発言(リーク？)し，数日後の宇宙開発委員会で，JAXAと国土地理院は協力することで精度は目標は達成できると報告。問題発覚→解決の時間があまりにも短すぎて，非常に不自然に感じる。この辺の事情は良く分からないが，この数日間での解決には何か裏がありそうだ。

報告内容を少し細かく見ていく。

この内容によると，国土地理院側の改善方法としてスライド9枚目には，
「RPCモデルに対応したソフトウェアの導入（高さ精度向上）」
と書いてある。RPCモデルというのは，衛星画像の画素を地理座標へ変換するパラメータであるが，これを導入して改善したのだろうか。このRPCモデルはPRISMを購入する際にファイルとしてついてくるパラメータであり，商用のソフトでもこのRPCファイルを読み込むことは可能だ。地理院はこれをやっていなかったのだろうか。これを適用しないで，精度が出ていないと言うのはおかしいと思うのだが...。

iPod touchのメニュー画面がやっと賑やかになりました。

アップル、iPhone/iPod touchのソフト更新 (インプレス)
http://k-tai.impress.co.jp/cda/article/news_toppage/38006.html

iPod touchでは、メールや地図、株価、天気、メモと5つのアプリケーションが新たに提供される。メール機能は、HTML対応でPOP3/IMAPが利用できる。GmailやYahoo!メールなども利用できる。地図アプリは無線LAN基地局を使って現在地を確認できる。国内の既存iPod touchユーザー向けには、アップグレードが2,480円で提供される。

2480円がなぜかかるのか疑問に思いながらも，インストール完了。お目当てのGoogle Mapsを表示させてみた。

上の検索が，地名検索。駒場で表示させてみたところである。ピンの上にある「東京都目黒区駒場」という吹き出しをタッチすると，ブックマークにこの地点を追加できる。

左下の丸いアイコンは，無線LANから位置を探すためのボタンである。タップすると位置を特定しようとするが，私が今いるところでは位置が特定できなかった。

そして，下部中央に「検索」と「経路」があるが，検索と経路検索に切り替えることができる。経路については，「運転経路が受信できません」と表示され，どうやってもうまくいかなかった。Google トランジットとは違うのだろうか。その辺はまだ良くわからない。

下部の一番右の目のアイコンをタップすると，地図がめくれるようになって設定画面が表示される。そして，ピンを地図上に落とすことができたり，渋滞情況を表示できたり，地図表示の切り替えができる。渋滞情報は，まだ日本ではできない。地図の切り替えは，地図，地図＋写真，写真の3種類があって，地形表示は対応していない。

地図表示の部分の使い勝手だが，非常に良い。地図を指でフリック(スクロール)すると，直感的に地図が移動していく。ダブルタップすると，タップしたところが拡大される。また，ピンチイン／ピンチアウト(指二本による閉／開)がそれぞれ拡大／縮小に対応している。

というわけで，日本国内でまだできない機能があるが，地図表示での操作部分は使い勝手は非常に良い。無線LANでの位置特定については，他のところで可能なのかはまだ分からないので，他の場所で試してみたいと思う。早く，街角の無線LANが整備されて，どこでもこのiPod touchを使って外で地図を眺められるようになったら面白いと思う。

前エントリーで，ALOS/PRISMの標高精度が目標の5mの精度に達しなかったことを紹介したが，多くの主要紙がこの問題を取り上げており，以下のような記事まで登場した。

観測衛星「だいち」の精度低下、「改良したい」と文科相　(読売新聞)
http://www.yomiuri.co.jp/science/news/20080111ik01.htm

渡海文部科学相は１１日、閣議終了後の記者会見で、宇宙航空研究開発機構の陸域観測衛星「だいち」の画像データの精度が想定より落ちている問題で、「当初目指していた精度が得られるように改良を加え、年度内をめどに調整していきたい。まだあきらめたわけではない」と話した。

まず，突っ込みを。精度は「低下」しているわけでも「落ちている」わけでもない。「低下」や「落ちている」というと，時間を経て精度が悪くなっていっている印象であるが，最初から精度が出ていないのである。もちろん，センサの劣化で精度が低下する可能性もあるが，この場合は最初から精度が出ていないと解釈する方が正しい。

また，改良を加えることについて言及しているが，どうやって精度を高めていくのだろうか。方法はいくつか考えられるが，画像上で正確な地理座標が分かっている場所を対応付ける方法がある。ただし，この報道されている6mは，地理座標の対応付けを行った上での結果なのか，判断できないため，なんともいえない。衛星プラットフォームにおける何らかの問題を解決して精度を高められる可能性はあるが，（私は専門ではないので分からないが），実際に衛星のところに行って対処することは不可能であるため，調整して精度が上げるための対策は限られるだろう。つまり，あまり期待できないと思われる。

一応，高さの検証をやっている(ネット上で見つけた)ペーパーを紹介。

• 水田ら(2005), 地理院時報, Vol.111
  http://www.gsi.go.jp/REPORT/JIHO/vol111/2-3.pdf
• Gruen and Wolf (2007), Proceedings of High Resolution Earth Imaging for Geospatial Information (ISPRS)
  http://130.75.85.12/html/publikationen/2007/workshop/paper/wolff_gruen.pdf
  

海外のサイトでも，このALOSの精度の問題が取り上げられていた。この記事によると，国土地理院の人が精度が低いことについて言及しており，地理院のリークだったのだろうか。

Japanese satellite flops at map-making: official　(Spacemart)

The 457.8-million-dollar "Daichi" satellite was sent into space to create detailed maps of remote parts of Japan, but the images have not been of sufficient quality, the government's Geographical Survey Institute said.

2007年は高機能携帯端末が続々と登場した。代表的なのがiPhoneとiPod touchだろう。これらはPCと同じMac OSが入っており，タッチパネルを導入するなど，使いやすいインターフェイスとなっている。ほかにも，小さいラップトップであるAsus Eee PCの登場(予定)や，デルもモバイルデバイスが出るのではという噂も出ている。また，Googleが発表した携帯電話のプラットフォームである「Android」の登場など，Googleもモバイルの分野に本腰を入れ始めている。通信インフラについては，未だに携帯電話やPHSの回線がメインではあるが，街中の無線LANもゆっくりではあるが，着々と整備されている。いつでもどこでも，回線の太さを気にすることなくインターネット等のネットワークにアクセスできる環境が整いつつある。

通信インフラの整備，デバイスの高機能化および小型化，インターフェイスの高機能化，アプリケーション開発の容易性に伴って，高機能な携帯端末は一気に広がる可能性を秘めている。これからは，高機能携帯端末に関連する動向にも注目すべきだろう。

これまでは，主な携帯端末である携帯電話での各種インターネット上でのサービスは，ディスプレイのサイズやインターフェイス，通信回線の太さによって制約を受けていた。しかし，高機能携帯端末の登場および普及によって，PCで可能だったインターネット上の各種サービスが，携帯端末で実現できる可能性がある。従って，地図サービスについても，PC上で可能だったマッシュアップや，高機能なサービスを携帯端末で受けられる可能性がある。これらのメリットは，地図サービスにとって大きな転機となる可能性を秘めている。

次に，地図の効用について考えてみたい。地図は机上やPC前で使用することも有効であるが，デジタルやアナログに限らず，「対象とするリアルな空間の中心で」地図を使用することが最も効果的ある。机上やPCの前で地図を使する場合，例えば地図で見ていたその対象地まで行くのに，時間が必要である。一方，対象とするリアルな空間の中心，例えば初めて訪れた街へ行って地図を参照すれば，その情報を意思決定や行動にすぐに反映させることができる。地図は現場で活用できてこそなのだ。

ただし，従来は現場での活用には制約が多かった。従来の紙地図では，自分がどこにいるのかを自力で知る必要があり，さらに紙地図から得られる情報には限りがあった。

これらの制約は，高機能携帯端末を用いることで解決できるだろう。測位(位置情報)については，GPSの普及やPlace Engineなどの無線LANによる測位によって，自分の位置を知る苦労はもはやほとんど無い。さらに，通信インフラも問題なくなりつつある。従って，インターネット上から位置情報をキーワードとした関連情報を引き出し，ディスプレイに簡単に表示し，高機能なインターフェイスによって，インタラクティブに情報の切り替えや検索が行えるようになる。

つまり，高機能携帯端末を利用することで，地図を使う効用が最も発揮できると考えられるのだ。

2008年に高機能携帯端末がブレークすれば，地図サービス関連はもう1度ブレークするかもしれない。今後のこれらに関連する動向に注目していきたい。

測量機器大手のソキアとトプコンの経営統合は記憶に新しいが，航空測量業界の再編が始まるかもしれない。

公開買付けの開始に関するお知らせ (日本アジアホールディングス)
http://www.ja-holdings.jp/holdings/html/jahl/viewNews.jsp?id=30545613321&dir=200712&update_time=1198627339000

平成19年12月25日開催の取締役会において、国際航業ホールディングス株式会社（以下「対象者」といいます。）の普通株式を公開買付け（以下「本公開買付け」といいます。）により取得することを決議致しましたので、お知らせ致します。

上記サイトにPDFがあり，かなり詳しくTOBに関する情報が掲載されている。なお，友好的TOBのようだ。

なお、本公開買付けにつきましては、既に対象者の取締役会からもご賛同をいただいており友好的に行われるものであります。- 1. 公開買付けの概要

また、国際航業株式会社を取り巻く市場環境は、売上の８割以上を占める公共部門のマーケット縮小を受けて、年々厳しさを増してきている事情にあります。こうした危機認識の下、当社は、経営組織の再構築を促進するための持株会社化を国際航業株式会社に提案し、上記のとおり、平成19年10月に株式移転により同社の持株会社化を実現しました。なお、対象者の事業活性化においては、従来からの主要事業である地図・空間情報サービス事業に加えて、さらなる派生・応用事業への多角化や民間部門での事業拡大が不可欠であり，（以下略） - 公開買い付けの背景

確かに，公共部門に重きがある会社だったと思う。営業のパスコ，技術の国際航業というイメージがあるので，これを機に営業が強くなり，民間へシフトしていくことが期待できるかもしれない。

うまくこの外圧を利用して再生することを願いたいが，実はこの日本アジアホールディングスはもう一つの航空測量大手のアジア航測の株式を27％くらい持っているのだ。

アジア航測株式会社の株式譲渡契約締結に関するお知らせ
http://www.ja-holdings.jp/holdings/html/jahl/viewNews.jsp?id=60344987995&dir=200709&update_time=1188892891000

国際航業とアジア航測の合併は規定路線ということなのだろうか...。

前々エントリでは，SRTM3というデータを使って，標高値を抽出するAPIを作成した。SRTM3は，空間解像度が約90mであり，データ量が大きいため，このAPIは日本周辺に限っていた。今回，解像度がSRTM3の10倍であるSRTM30を使って，ほぼ全球の標高値を抽出するAPIを作成した。

「ほぼ」というのは，南極が含まれている南緯60度以南が含まれていないという意味である。というのも，高緯度帯はSRTMミッションでは観測できていないのである。北半球の高緯度帯については，GTOPO30という他のデータソースがあるため，それを用いている。

データは，これまでと同じように，ftpサイトにあってダウンロード可能である。従って，SRTM3と同様の方法で，APIを作成することができた。

SRTM30データによる標高値抽出 API
http://www.tagchan.net/sample/elevation2_api.html

※現在，サーバーは停止しています。

前エントリにて，Google Mapsの地形レイヤーが登場したことを紹介したわけだが，そうなると標高値が知りたいところ。なので，SRTMというNASAがスペースシャトルから作成した地形データを用いて，緯度経度から標高値を抽出するAPIを作成した。

標高値抽出 API
http://www.tagchan.net/sample/elevation_api.html

これまでのAPIと同様に，JSONPで出力される。また，Google Mapsとマッシュアップも行っており，クリックすると，矢印が表示されてその地点の標高値が表示される。

ただ，これを作った後に，同じことをやっている人を発見したのでした...。

以下，細かい実装方法について。

SRTMのデータは緯度経度1度ごとにタイル状に分割されて，データが保存されている。今回，これらタイル状のデータ(ファイル)はモザイク(接合)せず，緯度経度を入力されたら，適切なファイルを読み込み，標高値を返すようなプログラムとした。このようにすることで，標高値を読みに行くまでの時間を短縮させることができたと考えている。

まずはデータをダウンロード。シェルで行った。17度×17度の289枚のタイルである。
http://webmodis.iis.u-tokyo.ac.jp/~tagchan/srtm/get.csh.txt
wgetでダウンロードし，解凍後にddコマンドでBig EndianをLittle Endianに変換する。

そして，
http://webmodis.iis.u-tokyo.ac.jp/~tagchan/srtm/tile.txt
のようなテキストファイルを生成させる。

この，「32129」は，北緯32度東経129度を意味している。SRTMのデータは，ファイル名に左下の緯度経度が含まれている。つまり，「32129」の場合は，N32E129.hgtということになる。

これまでが，get.cshのおこなったこと。

次に，
http://webmodis.iis.u-tokyo.ac.jp/~tagchan/srtm/src/txt2bsq.c
によって先ほどのテキストデータをバイナリデータに変換する。intが17×17個で，1156バイトのバイナリデータである。

そして，
http://webmodis.iis.u-tokyo.ac.jp/~tagchan/srtm/src/dem_value.c
によって，緯度経度を引数として，標高値を返すプログラムである。

// Specify file name using index tile
この段落部分で，緯度経度からファイル名を決定している。

// Extract elevation
そして，この段落部分でピクセル値を抽出する。バイナリファイルには，fseekを使っている。

※現在，サーバーは停止しています。

Google Mapsに新しいレイヤー「地形」が登場した。右上の切り替えボタンは以下の画像のようになっている。

「航空写真＋地図」がなくなったが，「航空写真」の下の「地名の表示」のチェックでOn/Offができるようだ。

この地形レイヤー，地形の陰影表示が施されている。また，標高が高くなるほど，地形の色がベージュ→黄緑→緑→白と変化していくようになっている。ただ，一部で茶色も入ったりしていて，色づけの規則性については不明である。

また，見ていて気づいたのだが，タイル上の模様が入って，不自然な箇所も見受けられた。その一例を以下に示す。

なぜそのようになっているのかは不明である。

インターネット地図空間上でのコミュニケーションが登場してきた。その例としては，だいぶ前に登場しているが，はてなわんわんワールドがある。そして，最近の例ではalisがある。一方で，地図空間ではないけど，現実世界に近い3次元仮想空間でのコミュニケーションが実現しており，セカンドライフが有名である。

mixiのようなウェブサイト形式ではないが，サイバー空間上に人物を置き，人と人がコミュニケーションを行う方法は，ソーシャルウェブの潮流なのだろう。このような，人と人がコミュニケーションをする媒体や場として，地図(地理情報)を活用することは非常に重要だと私は思っている。その理由を以下に示す。

・地理的に近接であれば，互いに同じ問題意識や属性を持っている可能性があり，そこでコミュニケーションをはじめるきっかけとなる可能性がある。Web2.0としてタグが重要であるのは周知の事実だが，そこにさらに地理的情報を付加すると，一層有益なコミュニケーションができる可能性がある。

・地理（空間）データを活用してコミュニケーションできる可能性がある。物事を空間的に捉え，それを基に議論したりする。それを仮想「地図」空間上で行うことで，効果的に行える可能性がある。要するにGISの分野で以前から言われてきたような，「地図コミュニケーション」である。

さらに，3次元での地理情報を用いることで，2次元以上に現実空間に近づくことが期待できるだろう。以上のようなことを考えると，理想は「Google Earthでセカンドライフの実現」なのかもしれない。

で，そんなことをここ最近考えていたら，こんな記事が。やはりGoogleもそういうことを考えているのだろうか。

グーグル、「Second Life」ライクな仮想世界を構築か？--米報道 (CNet)
http://japan.cnet.com/news/media/story/0,2000056023,20357086,00.htm

しばらく前から、CNET News.comではGoogleが仮想世界スペースに進出をもくろんでいるのではないかといううわさを耳にする。特にSecond Lifeのような既存の仮想世界に対する関心が高まっていることや、Google Earthの成功、Sketchup技術の買収などがその根拠になっているようだ。

しかし、真に活気のある仮想世界を実現するための鍵はユーザーが作成するコンテンツである。Sketchupなどのサービスを利用するユーザーが、あらかじめ作成された大量の3DコンテンツをGoogleの運営する仮想世界に簡単にインポートできるとしても、Second Lifeや、それよりはユーザー数が少ないThereが住人を集めたような新味のあるコンテンツにはならないだろう。

セカンドライフに比べて，現実世界との接点をとりやすいというメリットを生かし，仮想空間の地理情報と現実世界の間をうまく繋げる仕組みを考えるだけで，意外に広まるのではないかと思っている。

地図系の視点を持つ私としては，地理情報技術はソーシャルウェブのさらなる発展に貢献できると期待している。またもやGoogleか，という気がしないわけでは無いが，期待をこめて動向を見守りたいと思う。

GPS機能付き携帯電話では，写真を撮ると画像ファイルのExifにGPSの位置情報をつけてくれます。そこで，位置情報を付けた写真を，携帯メールから送信し，自分のサイトのGoogle Mapsにほぼリアルタイムで自動的にマッピングさせるスクリプトを作ってみました。

PHPはいろいろな機能が付いてまして，メールの送受信ができてしまいます(参考)。また，Exifの情報を抽出することが可能です(参考)。そこで，PHPを使ってメールを受信して写真を添付ファイルとして保存し，Exifの情報からGPSの位置情報を抽出し，テキストファイルに書き出すことにしました。また，PHPでは簡単な画像処理もできます。添付された画像は，サイズが大きい場合があるので，縮小させる処理も行うことにしました。

メールの受信部分については，レッツPHP!さんの写メールBBSのスクリプトの一部を利用させていただきました。ありがとうございます！

まず，下記URLにアクセスすると，サーバーサイドでメールを受信し，EXIF情報を抽出し，添付ファイルを保存し，テキストデータに書き出す作業を行います。
http://www.tagchan.net/photo_php/pop.php

そして，自動的に下記URLへ移動し，Google MapsにGPS情報を基にポイントがマッピングされます。また，リスト表示も可能となっています。このGoogle Mapsのスクリプトは，ホームページのトップで使っているものとほとんど同じです。
http://www.tagchan.net/photo_php/map.html

まだ試験的段階です。もう少し洗練させることができればと考えています。今後は，GeoRSSの形式で保存するなどの工夫をしたいと考えています。また，スクリプトは早い段階で公開したいと考えています。

※ 送ってみたい方がいましたら，メールアドレスを教えますので，ご連絡くださいませ。

地球は５ミリ小さかった！　精密測定で判明（産経新聞）
http://www.sankei.co.jp/culture/kagaku/070805/kgk070805000.htm

地球の大きさを精密に測定すると、赤道の直径が従来より約５．１ミリ小さいことが分かった。情報通信研究機構や国土地理院などが参加する国際機関が４日までに、電波望遠鏡や衛星利用測位システム（ＧＰＳ）衛星などのデータを総合的に解析した成果を、「国際地球基準座標系（ＩＴＲＦ）」の最新版として３年ぶりに公表した。

地球の大きさから5.1ミリという値を考えると，ほとんど誤差の範囲ですね。ただ，厳密に考えると大陸プレートの移動によって不動な地点はないわけなので，そういうことも厳密に考慮して，正確な地球の形を考慮した座標系が，ITRFということなのだろうと思います。以下のサイトにITRFの説明がありますので，ご参考までにどうぞ。

参考：日本測地学会編「測地学テキスト ー 2-1-5-1.ITRF」
http://wwwsoc.nii.ac.jp/geod-soc/web-text/part2/2-1/2-1-5-1.html

こういうことを研究する分野は「測地学」と呼ばれる学問分野です。大雑把に言えば，地球の正確サイズを測る学問という感じでしょうか。あまり注目されない分野ですが，地球の正確な形状や大きさを測るということは，位置を正確に記述する測量へ繋がり，最終的には正確な地図の作成へ繋がります。また，上記の大陸プレートの移動と関連して，地殻変動や地震，火山とも密接に関連してくるわけで，我々とは全く関係の無い分野だとはいえないわけです。

そんな測地学を，わかりやすく説明した本が出ています。下記の本は，日本測地学会が出版した本で，リモートセンシングや地図などに興味ある人は，一読しておくことをお勧めします。雑学っぽいネタにもりそうですね。自分は数年前に購入して読んだのですが，もう一度読んでおこうと思います。

地球が丸いってほんとうですか? 測地学者に50の質問 (朝日選書)
posted with amazlet at 08.12.24
大久保 修平 日本測地学会
朝日新聞社
売り上げランキング: 205748

おすすめ度の平均:
真実は只１つ
測地学から入る地球惑星科学の入門書

Amazon.co.jp で詳細を見る

インターネットで地図を利用する人が多くなってきました。従って，以前よりも地図に接する機会が多くなったといえます。地図は当たり前のように溢れているわけですが，ここで，地図はどのような技術・手法等で作成されているのか，どのくらい作成が大変なのか，という基本的な部分の知識について，一般ユーザは知る必要があると思っています。

また，地図は作成された時点で，地物が抽象的に表現され，また情報の新鮮さは劣っていくわけです。主題精度，時間精度，位置精度などを念頭において，地図を読むことができる「地図リテラシー」は，インターネットで地図が容易に閲覧でき，空中写真や高解像度衛星画像も簡単に見ることができる時代においては，必要な知識であると考えています。ただ，そういうことを体系的に教えている教科書はないですね。

ただ，そういう部分の一端を垣間見ることができるような書籍を紹介します。これは，田口が購入した地図作成に関する書籍です。リストアップされているのは，地図の歴史，地図の豆知識，経度計算に重要な時計の歴史，三角点の選定に関する小説，です。

地図に訊け! (ちくま新書)
posted with amazlet at 08.12.24
山岡 光治
筑摩書房
売り上げランキング: 55517

おすすめ度の平均:
地図自体が面白くなる
地図に一生を捧げた技術者の書いた良書
知らなかった地図の情報
地図はたのしい、、、
なかなか熱い「地図」本

Amazon.co.jp で詳細を見る

先日，朝日新聞の書評に掲載されていたんで，早速購入しました。地形図に関する逸話を含めた読み物です。地図の作成，表現，正確さに関して記述されています。

地図を作った人びと―古代から観測衛星最前線にいたる地図製作の歴史
posted with amazlet on 07.07.19
ジョン・ノーブル ウィルフォード John Noble Wilford 鈴木 主税
河出書房新社 (2001/01)
売り上げランキング: 506156

おすすめ度の平均:
地図ってこうやって作るんだ！

Amazon.co.jp で詳細を見る

ものすごく分厚い本です。電車の中では読めません。この本では，地図が発明されたところから，最後は火星や月面の地図まで網羅しています。衛星リモートセンシングや写真測量についても触れられています。

経度への挑戦―一秒にかけた四百年
posted with amazlet at 08.12.24
デーヴァ ソベル
翔泳社
売り上げランキング: 284089

おすすめ度の平均:
科学と技術の発展の原点がここにある
なぜベストセラーに？
時計の好きな方にお勧めします
こんな違いがあるとは。
科学と技術史と言うよりもお話し

Amazon.co.jp で詳細を見る

経度の正確な計算には，正確な時計の存在が必要不可欠。その時計にまつわる話が中心です。大航海時代における緯度経度の決定方法を知ることができます。

劒岳―点の記
posted with amazlet on 07.07.19
新田 次郎
文芸春秋 (2006/01)
売り上げランキング: 29529

Amazon.co.jp で詳細を見る

点の記というのは，測量で使う基準点の設置の記録のことです。登頂が非常に困難な劔岳の三角点の設置の記録です。地図を作るためには正確な位置が判明している基準点が必要であり，地形図の基本です。

また，新田次郎のこの小説は映画化されるようです。2009年予定ですが，楽しみです。

木村大作カメラマン初監督、新田次郎原作「劔岳～」映画化 ［文化通信.com］
http://eiga.com/buzz/show/7725

東映は13日、映画「劔岳　点の記」の企画を発表した。「劔岳　点の記」は、「八甲田山　死の彷徨」「富士山頂」などで知られる新田次郎の同名小説の映画化。明治40年、日本地図最後の空白地点、前人未踏の劔岳に測量のため挑んだ男たちを描く実話。

前エントリーでFlickrがGeoRSSをサポートしていることを紹介しましたが，実はkmlをサポートしていることもわかりました。このことは，結構いろいろなBlogで紹介されています。例えば以下のサイトに多少詳しく紹介されています。

FlickrがKML対応？(グーグルアースを楽しむBlog@N-O)
http://googleearth-no.blogspot.com/2007/06/flickrkml.html

「format=kml_nl」とパラメータを設定することでKMLをフィードしてくれるわけです。

Flickr, KML, and a stroll down memory lane. (geobloggers )
http://geobloggers.com/archives/2007/05/31/flickr-kml-and-a-stroll-down-memory-lane/

というわけで，田口のFlickrにアップロードされていて，geotaggedされた写真のkmlは以下のURLとなります。

http://api.flickr.com/services/feeds/geo/?id=7593934@N02&format=kml_nl

2週間に1回くらいは新しい写真が更新されているかもしれません。

以前にコメントしましたが，Google Mapsは，GeoRSSをサポートしています。GeoRSSで与えられている緯度経度をGoogle Mapsでオーバーレイする方法は2つあって，

1. Google Mapsのサイトで，地図の検索のところにGeoRSSのURLを入力する方法

2. Googel Maps APIのGGeoXMLを使って，自分のサイトに載せる

があります。

さて，写真共有サイトのFlickrは，GeoRSSをサポートしていることが分かりました。

RSSに位置情報を格納できるGeoRSSをGoogle Maps APIがサポート (F.Ko-Jiの「一秒後は未来」)
http://blog.fkoji.com/2007/03250034.html

Flickrで取得できるフィードはGeoRSSに対応しているらしく、&georss=trueというパラメータを付与することでフィードにGeoRSSで位置情報が埋め込まれるそうです。

田口のFlickrでGeoRSSを出力すると，以下のようになります。

http://api.flickr.com/services/feeds/photos_public.gne?id=7593934@N02&format=rss_50&georss=true

てなわけで，これをGoogle MapsでGeoRSSをオーバーレイしてみました。

1の方法は，こちらをクリックすると，Google Mapsのサイトへ飛んでマッピングされます。ただ，問題点があり，こちらで示されているように，二重に表示されてしまいます。

2の方法は，こちらにサイトを設置しました。ソースはシンプルで，

var map; var geoXml = new GGeoXml("http://api.flickr.com/services/feeds/photos_public.gne?id=7593934@N02&format=rss_50&georss=true");

function onLoad() {
if (GBrowserIsCompatible()) {
map = new GMap2(document.getElementById("map"));
map.addControl(new GMapTypeControl());
map.addControl(new GLargeMapControl());
map.setCenter(new GLatLng(35.51881, 139.44418),9);
map.setMapType(G_SATELLITE_MAP);
map.addControl(new GOverviewMapControl(new GSize(120,120)));
map.addOverlay(geoXml);
}

これだけです。

以前，Flickr APIでJSONを出力し，Google Mapsにオーバーレイする方法を紹介しましたが，今回の方法は，マーカーのアイコンがいじれないなど，自由度は低いですね。従って，しっかりしたサイトを作りたい人は，Flickr APIを使用する方法がお勧めです。気軽さでいえば，今回の方法もありでしょう。

とにかく，GeoRSSがFlickrのような大手のサービスで採用されているのは，大変望ましい限りです。

リアルタイム地図更新は，地図の情報と現実とのギャップを埋めるために重要です。それをホンダのカーナビで実現したようです。

internavi Premium Club 地図データ更新
http://www.premium-club.jp/service/service1.html

さすがにデータ量が多いので，DVDやHDによってデータを持ってくる必要があるようです。

次に，リアルタイムの豪雨情報と地震情報が配信されるようになりました。今までは，渋滞情報はありましたが，渋滞情報以外で，リアルタイムな情報として配信されるデータはありませんでした。

「インターナビ・ウェザー」に世界初の「豪雨地点予測情報」と「地震情報」サービスを追加(Honda プレスリリース)
http://www.honda.co.jp/news/2007/4070704b.html

財団法人 日本気象協会から提供される降雨予測情報をもとに、インターナビVICSの通過予想時刻にもとづく、約10分先までの時間雨量30mmを超える豪雨地点予測情報をナビゲーション画面に表示し警告する。

配信方法はVICSを使っているのですね。電話系の回線ではありません。

http://www.premium-club.jp/technology/t1.html
http://www.premium-club.jp/technology/index.html

災害リスクに関する情報がリアルタイムで配信されるという，かなり先進的な事例だと思います。

さらに，注目したいのが，各車の情報を集約できるシステムがあることです。

internavi Premium Club インターナビフローティングカーシステム
http://www.premium-club.jp/technology/tech1_2.html

フローティングカーシステムとは、クルマをセンサーにして、そのデータを、通信機器経由で収集する仕組みのことです。

GPSで位置が分かるわけですから，いろんなセンサーを付けることで，さまざまな位置にある車から広域に情報を収集可能となるわけですね。たとえば，ワイパーの動作の情報を集めることで，雨の降っている所がレーダーより詳細にわかったりとか・・・。

地図のリアルタイム更新，災害リスクに関する情報のリアルタイム配信，位置＋情報の収集システムが整備されているということで，空間情報分野の最先端の実用例ですね。

ちょっと前の記事ですが。個人的に気になる記事です。

「見えなかった情報」を可視化――NII、論文300万件をGoogle検索対象に (ITmedia News)
http://www.itmedia.co.jp/news/articles/0705/25/news041.html

国立情報学研究所（NII）が4月から、国内の学術論文情報300万件のデータベース「CiNii」（サイニイ）をGoogle検索対象にした。同時に、データベースも検索エンジンが見つけやすい形に変更。一般ユーザーが論文情報にアクセスしやすくした。

最近，論文タイトルでGoogle検索すると，国内論文が多く引っかかるようになり，とても便利になりました。これはCiNiiのおかげですなんですね。この記事によると，論文データベースをGoogle検索でひっかかるように開放し，Google Scalar(学術文献の検索)とも連携したようです。

感じとしては，自分たちで，まずデータベースを構築・改善し，「Googleさん，データベースをインデックス化して検索しやすくしたので，使ってください。」という感じで取り込んだのではないでしょうか。このやり方は，Googleとの付き合い方を考える上で，非常に有効な方法だと考えられます。

各分野では，いろいろな既存の情報が保有されていて，陽の目を見ない情報や，Googleキーワード検索で簡単にひっかかってしまう情報も混在しているわけです。そういう情報を，CiNiiのようなサイトを構築し，検索エンジンと連携も可能とすることは，とてもメリットがあると思うのです。

CiNiiのデータは、マシンで情報を収集・整理するGoogleとは対照的。学者が手で書き、査読し、学会で精読し、学会誌に掲載した論文に、被引用数を手作業で確認して作っており、何人もの人が膨大な手間ひまをかけている。人の手で整理した情報にはロボット検索にはない価値がある。「キーワード検索では、周辺の分野や、他の情報との関連性が見えづらい。手作業で整理した論文情報のページには、著者や掲載誌、引用情報などが書かれているから、ここを起点にして周辺情報に触れることができる」（大向氏）。各論文情報ページにはパーマネントリンクが付いており、それぞれのページが情報ポータルになる。

Googleによって，情報を全てインデックス化されてしまう前に，自分達が必要と考えられる方法でデータベースを構築し，インデックス化するべきだと思います。そうすれば，互いに手を組むことで，検索エンジン側としてはインデックス化する手間が省け，情報を保有していた側は，検索エンジンを通してデータを公開でき，自分達の領域を守ることができるわけです。つまり，お互いにハッピーですね。

GISの分野の人たちは，空間情報を自前でインデックス化できればいいのですが，既に侵食されてきているので，難しいでしょうね。

社会問題の意識向上に貢献する「Google Earth」--米非営利団体が活用 (CNET)
http://japan.cnet.com/news/media/story/0,2000056023,20350469,00.htm

Googleが提供している3次元表示が可能な地図表示ソフトウェア「Google Earth」を米国の複数の非営利団体が、森林伐採や大量虐殺といったさまざまな問題に対する世間の関心を高めるための新たなツールとして活用している。

上記の引用記事は，Digital Earth（デジタルアース）のシンポジウムについて取り上げています。先日行われたようですね。

The 5th International Symposium on Digital Earth (ISDE5)
http://www.isde5.org/index.htm

むかしむかし，「デジタルアース」という構想が，今や温暖化問題の伝道師であるゴア氏によって提唱されていました。（一応，デジタルアース日本学会というのもありますね。）

デジタルアース日本学会「デジタルアースとは」より
http://de.gsec.keio.ac.jp/digitalearth/about.html

"デジタルアースとは、地球上の自然的・社会的事象を空間的な参照情報を持ったデータとしてデジタル化し、インターネットで繋がれたコンピュータ上の仮想世界に再構築された地球、「アースメタファ」のことです。"．

福井弘道研究室「Digital Earth Project」より
http://web.sfc.keio.ac.jp/~hfukui/d_earth.html

デジタル・アースによって、グローバルからローカルまでの多様な情報をシームレスに視覚化し、地球規模の問題の全体像を分かりやすく提示して、多くの人の共感に基づく「地球市民としての身体の知」の形成が促進されることが期待されている。

デジタルアース構想は，空間情報が統合されて視覚化され，それが意思決定に結びつくことを目標にしていたはず。それを冒頭の記事を読む限り，その目標に近づきつつあることが分かります。

Googleがkeyhokeを買収し，Google Earthを出す時点でこうなることは予想できましたが，改めて「Google earth = Digital Earth」であることを再認識したわけです。

情報を地図上にプロットして情報を提供するウェブサイトは，最近急激に増えています。このようなウェブサイトでは，サイトごとに空間情報が集約されていると考えられます。しかし，他のウェブサイトの空間情報をオーバーレイすることは想定されていません。従って，サイト間での空間情報の連携というのは，現状では全く無いといえます。

しかし，逆に散在する空間情報(地理情報)は統合されて一括に扱うことが可能となり，容易に互いの散在するデータをオーバーレイできれば，空間情報の威力をさらに発揮することが可能になるのではないか，と私は考えています。

例えば，全く別の空間情報どうしをオーバーレイすることができれば，知られていなかった関連性や知見が新たに得られる可能性があります。また，空間情報はレイヤ構造となっていて，テーマごとにファイルがあります。そこで，地理座標を使って検索することで(空間検索)，他のレイヤのデータでも，横断的に一括して空間情報を取り出すことができるようになります。

ウェブマッピングの次のステップとして，前回エントリーで紹介した「plnet」のコンセプトのように，様々な「空間情報」を集約・統合するような，1つ上の階層の仕組みを考えるべきだと思っています。

GeoRSSやkmlのようなフォーマットによって，集約や統合は容易になるでしょうが，それだけでは情報量が足りないと思います。テキストでもなんでもかんでも，空間情報として取り出せてしまうような仕組みができ，統合可能なシステムが登場すると，もっとおもしろいと思います。

空間情報を集約・統合する仕組みの目指す先については，また今度書きます。

「みんなが集まって，地図を作りあげる。」

ここ最近，参加型地図が注目を集めつつあります。これまでは，アナログ地図の場合もそうですが，小数の人が地図を完成させて，多くの人に発信・公開するという流れでした。しかし，インターネットによって，情報のやりとりが容易になりました。そのため，「みんなで作り上げる地図」という形が，じわじわと広がってきているような気がします。

参加型地図が注目を集めた最初の事例としては，

バカ日本地図
http://www.chakuriki.net/japan/

というのがありました。これは完全にお笑い系でしたね。自治体系では，例えば

ふじさわ電縁マップ
http://gis01.city.fujisawa.kanagawa.jp/Portal.do

というのがあります。

最近は，「口コミを集約する手段としての地図」という位置付けで，様々なサービスが多く立ち上げられている印象があります。例えば...

ワイワイマップ by Yahoo! 地図情報
http://waiwai.map.yahoo.co.jp/

buzzmap by so-net
http://buzzmap.so-net.ne.jp/

食べログ by 価格.com
http://r.tabelog.com/japan/rstmap/

が挙げられますが，探せば他にもいっぱいあるでしょう。

こういうサービスがどんどん増えてきたわけですが，次のステップとしては，こういう集約した情報を，いかに適切なタイミングで提供するのか，ということになるかと思います。GPSやPlaceEngineなど，位置情報を取得する技術を生かすことができれば，適切なタイミングで，実世界にいる位置情報を照らし合わせて，情報を提供できるようになるはずです。

最近，Google Mapsに関する大きな出来事といえば，先日登場したMy Map作成機能でしょう。

Google マップで自分だけの地図を作成
http://maps.google.co.jp/help/maps/userguide/index.html

やっと，APIの知識無しでも，データを作ることができるようになりました。フィーチャを点だけでなく線，面も作れるのがいいですね。また，KMLにもできるようですね。あとは，マイマップを自分のサイトやブログに貼り付けることができるようになれば，いいのになあと思います。

マイマップは，あくまで個人ベースであることと，インタラクティブに作成できることがメリットと言えます。しかし，データの管理という観点からは，マイマップだけでは結構面倒なのではないかと思います。で，Google Maps API Blogには，興味深い例が紹介されてました。

Creating Dynamic Client-side Maps Mashups with Google Spreadsheets
http://googlemapsapi.blogspot.com/2007/03/creating-dynamic-client-side-maps.html

WebベースでMS Word, Excelのような機能が提供されているGoogle Spreadsheetは，Google Spreadsheet APIを使うことで，Google Spreadsheetで編集したデータをJSONの形式で吐き出すことができるようなのです。また，

JSON output is native Javascript code itself, and with a callback parameter that wraps the JSON output text in parentheses and a function name of your choosing, it allows you to get around some of the cross-domain security issues you might encounter in typical client side JavaScript.

と述べているように，JSONはJavascriptと親和性が高いこと，クロスドメインの問題が無いことから，HTML内にJavascriptのコードを記述するだけで，済んでしまいます。というわけで，自分のサイトのGoogle Mapsに簡単に取り込めるわけです。

Google Spreadsheetを使うことで，大量のデータの管理がしやすいこと，共有させることで他の人との共同編集が可能なことも，便利なところです。My Mapsを何らかの形でAPIとして組み込まれれば，Google Spreadsheet APIと組み合わせて，GISデータ作成ツールなんかも作ることができるかもしれません。

昨日のエントリーで，Flickrにアップロードした写真に地理情報のタグである，Geo tagを与える簡単な方法を紹介しましたが，この与えたGeo tagを使って，自分のサイトのGoogle Mapsにポイントとしてオーバーレイする方法を紹介します。もちろん適用する場合は，Flickrのアカウントを取得し，API keyを取得しておく必要があります。

方法を簡単に説明すると，Javascriptを用いて，Flickr APIを使って自分のアカウントの写真の情報をJSONの形式で抽出して分解し，Google Maps APIを使用して地図上のプロットということになります。

Flickr APIのうち，flickr.photos.searchを使います。

http://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=「API Key」user_id=[User ID]

この「API Key」と「User ID」を取得したものを入れ，JSONフォーマットのためのURLの末尾に「&format=json」を付けると，私の場合は，

http://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=e0c65155a65b79c9a6c9bd0776908bb3&user_id=7593934@N02&format=json

となり，結果はこちらとなります。横長のテキストが帰ってきます。ここにアップロードした情報が含まれているんです。そして，Geo tagを付けたものだと，こちらになります。一応，XML形式だとこんな感じ(Geotagのない写真は緯度経度が0になるようです)。緯度経度が含まれているのがわかります。他の情報も抽出できるので，詳しくはflickr.photos.searchのページを参照してください。

で，今回はJSONで呼び出しているので，クロスドメインの問題はなく，Javascriptで簡単に情報を抽出できます。それを，Google Maps APIでポイントとしてオーバーレイするわけです。試作したサイトは，

Flickr API + Google Maps API
http://www.tagchan.net/flickr_map.html

です。JSファイルは，こちらです。JSファイルはご自由にお使いください。なお，Google Maps APIを使っている部分は，私のホームページのトップにある地図と同じで，吹き出し内に写真を表示できるようにし，地図の外にはオーバーレイしたポイントをリスト表示しています。

Flickr+Google Mapsだとgeotagr!というのがありますが，これは写真の表示は別サイトで「あちら側」のまま。今回の方法だと，自分のホームページ上で写真地図を気軽に表示できるため，気分としては「こちら側」とすることができます。

＜参考にさせていただいたサイト＞
・JSON Response Format (Flickr)
http://www.flickr.com/services/api/response.json.html

・kajidaiの日記 - FlickrAPIがJSON対応
http://d.hatena.ne.jp/kajidai/20061002/1159811459

・第2回　JavaScriptからFlickr APIで画像検索：ITpro
http://itpro.nikkeibp.co.jp/article/COLUMN/20061101/252356/

写真を管理したり，公開するサービスはたくさんあります。代表的なのはGoogleのPicassaやFlickrでしょうか。「あちら側」で写真を管理して，共有もできます。

特に，Flickrはまさにweb 2.0の代名詞です。タグでの管理やAPIの公開など，積極的に行っています。今回，諸事情があって，Flickrをはじめてみたんですが，撮影地点をプロットしたフォトマップも作成できて，非常に便利なんです。

で，フォトマップのための撮影地点の座標をどう入れるのかというと，web 2.0らしくタグを使います。Geo Tagと呼ばれていて，タグを入力するところに「geo:lat=35518762 geo:lat=35518867」みたいに入れるわけです。もちろん，手打ちだと非常に面倒なので，こんな便利なツールがあります。

Localize Bookmarklet - Map Your Flickr Photos!
http://labs.sumaato.net/tools/flickr_geocode_bookmarklet/

I just spend some time to create a slim bookmarklet that enables mapping, geocoding and geotagging directly in your Flickr photo page. It works with all common browsers without the need for any extension.

ブックマークレットです。使い方は，とても簡単。まず「Don't waste your time: Grab it here!」をブックマークのところにドラッグしておきます。そして，自分のflickrの写真のページで，このブックマークレットをクリックすると，Google Mapsが表示され，ダブルクリックすると勝手にGeo Tagに緯度経度を与えてくれるのです。

このGeo Tagの緯度経度をFlidkr APIを使って呼び出し，自分のサイトでGoogle Mapsにプロットする方法を，次エントリで紹介します。

ハリケーンKatrinaによるNew Orleansの被災後の衛星画像は，Google Maps/Earthでいち早く公開されていました。どうやら最近画像が切り替わったらしく，被災前のデータに戻ってしまったようです。アメリカでは，これに関して結構話題になっているようです。

Google Goes Back To Pre-Katrina Maps (CBS News)

Google's popular map portal has replaced post-Hurricane Katrina satellite imagery with pictures taken before the storm, leaving locals feeling like they're in a time loop and even fueling suspicions of a conspiracy.

被災地域の衛星画像によって，保険の申請の資料へ活用したり，被害復興計画に活用されたようなので，非常に重要な衛星画像だったはずです。この画像にアクセスできなくなってしまった点は，非常に残念といえるでしょう。引用した記事によると，画像の切り替えによって，Googleに対して批判が広がっているようです。

ただ，やはり災害を受けている状況の画像を公開し続けるのも，違和感があるのも事実。地図を見て，旅行を取りやめてしまう人もいるかもしれません。見た目とか，そういう点を総合的に判断してGoogleは切り替えを決めた可能性もあります。一応，Google側は以下のように述べており，ベストの画像を提供していると主張しています（Chikai Ohazama氏は日本人？）。

Chikai Ohazama, a Google Inc. product manager for satellite imagery, said the maps now available are the best the company can offer. Numerous factors decide what goes into the databases, "everything from resolution, to quality, to when the actual imagery was acquired."

最適な画像を提供する判断はGoogle側にあるわけですから，この判断は仕方が無いとはいえ，このような衛星(航空)写真は影響力が大きいため，判断は慎重に行うべきでしょう。

ベストなのが，一番最近の画像を載せることですが，これはコスト的に現実的ではありません。時価総額が18兆円をこえるGoogleですが，さすがに全世界で高解像度の画像を最新に切り替える作業を継続することは，絶対に無理でしょう。

現実的に考えられる点は，画像を最新にすることではなく，ユーザーに画像の撮影時間を意識させることでしょう。撮影時間がわかれば，ユーザーは意識的に今の状況を推測することが可能となります。

私の考えとしては，Google EarthにしろMapsにしろ，撮影時間を明記するべきである，ということです。紙ベースの地図は最新が前提だったわけですが，せっかくITを利用するのであれば，そのようなことを考慮した地図表示システムを提供することは可能でしょう。

『追記』
なお，Google Mapsではなく，有料のスタンドアローンソフトウェアであるGoogle Earth Proについては，以下の記事によると，２時期で切り替えが可能なようです。
Google Shows Pre-Katrina Photos for New Orleans (Google Earth Blog)by FrankTaylor

横浜市三千分一地形図
http://www.city.yokohama.jp/me/machi/kikaku/cityplan/gis/3000map.html

Google Earthのkmlファイルで横浜市の過去の1/3000の地形図を閲覧することができます。この時代に1/3000の地図が整備されているとは知りませんでした。早速，kmlファイルをダウンロードし，Google Earth上で透過表示としてオーバーレイしてみると，

こんな感じになります。上大岡駅周辺なのですが，ちょっとずれてますけど良い感じで重なっています。もちろん，重ならないのは，地形図の誤差とかいろいろな要因があります。そういえば，戦中戦後直後の地形図って，写真測量なんだろうか...。

地形図の詳細については，上記URLに記載されています。

「三千分一地形図」は、1919(大正8)年の旧都市計画法の成立を契機に、都市計画策定の基礎資料として作成されたものです。 　横浜市では、1921（大正10）年から「三千分一地形図」作成を目的に、詳細地形図測量に着手しています。この取組は関東大震災により中断を余儀なくされましたが、1925（大正14）年から改めて測量の取組を開始しました。 　その取組にあたっては、欧米の都市計画の基礎資料を参考にしています。縮尺3000分の1、東西2400m、南北1800mの図郭とし、当時の横浜市域を53図葉でカバーする計画でした。 　現在残っている地形図を見ると、戦前では1938（昭和13）年まで詳細地形図測量に基づいて三千分一地形図が作成されていたことが確認されますが、その後は厳しい戦時体制となり、郊外部を対象とした三千分一地形図作成は陸地測量部（現在の国土地理院）が作成した一万分一地形図を三千分一に拡大して利用していることが分かります（これらの地形図には「仮製」と表示されています。）。そして1949（昭和24）年から1950（昭和25）年には、戦前に地図作成ができなかった金沢付近の地形図が、最後の三千分一地形図として作成されました。

大正時代からはじまり，関東大震災や第二次世界大戦があったわけですが，戦後も継続して作成していたようです。

技術的な点としては，図葉ごとにkmlが分かれているのは不便です。いちいちダウンロードしないといけません。1つのファイルでシームレスに表示できるようになると，さらに便利になるでしょう。

とかく，kmlで表示可能となった点は，大きな進歩といえます。地図が好きな人にはたまらないでしょうが，小中学校の総合学習など，教育にも活用できるでしょう。国土地理院も，過去の地形図はじゃんじゃん公開して欲しいですね。

KML and GeoRSS Support Added to the Google Maps API (Google Maps API Blog)
http://googlemapsapi.blogspot.com/2007/03/kml-and-georss-support-added-to-google.html

Google Maps API上で，インターネット上にあるkmlを読み込んで表示可能となりました。上記URLにはサンプルがあります。

http://tagchan.net/blog/2006/07/google_mapskml.html

で紹介したように，Google Mapsの検索画面でkmlのURLを入力すると，地図にフィーチャーがオーバーレイされることを紹介しました。今回は，自前のサイトのAPIに組み込んで表示可能となったわけです。

ただ，勝手に読み込みにいけるとなれば，あたかも自分が作成したデータのように振舞うことも可能かもしれません。データ作成者の著作権をどのように守っていくのか，その辺が気になります。

また，オーバーレイできるのは，点・線・面の３つだけのようです。

Can Google Maps read the KML files I've made for Google Earth?
http://maps.google.com/support/bin/answer.py?answer=41136&topic=1475

Please note that Google Maps currently supports KML files with points, lines, polygons, styles, icons, and network links (without view-based refresh). We plan to add support for ground overlays, screen overlays, folders, and visibility in the near future.

地図画像を直接オーバーレイできるGroundOverlayはまだサポートしてないようで，将来的にはサポートするようです。私が以前やった，

http://tagchan.net/blog/2007/01/wmsgoogle_mapsearth_1.html

Google maps + WMSのように，kmlでWMSレイヤーもオーバーレイできるようになったりして...。

もうひとつ，GeoRSSは，RSSに地理情報を与えることができる仕組みです。あまり広まっている印象はありませんが，こちらも要チェックでしょう。

トプコンとソキア　経営統合で基本合意　測量機１・２位、海外勢に対抗(FujiSankei Business i)
http://www.business-i.jp/news/ind-page/news/200703170021a.nwc

測量機の最大手トプコンと２位のソキアは１６日、経営統合することで基本合意したと発表した。経営基盤を強化し、海外の巨大メーカーに対抗する。トプコンの国内シェアは約４０％に上り、統合後のシェアが５０％を大幅に上回るのは確実なため、公正取引委員会の承認を得て、最終合意を目指す。

なんと1位と2位の統合のようです。毎年，測量の全国イベントに参加していますが，大手企業のブースと，それ以外の企業の小規模のブースの大きさの差がどんどん開いている，という話を関係者から聞いたことがあります。つまり，測量機器業界は勝者敗者の2極化が進んでいるということなのでしょう。そうなると，測量機器業界では，さらに大手企業とそれ以外の企業の差が開いていくことが予想されます。さらに，今回の統合は国内企業との競争は念頭になく，海外との競争で生き残れないと，立ち行かなくなると判断したのでしょう。

測量機器は物ですから，簡単にリプレースしてシェアが変わってしまうため，国内企業にとっては海外製品は脅威となります。ただ，同じ業界で航測会社は，業務が地方自治体や国から来ていることが多いと思うので，権益は守りやすく，測量機器業界とは状況が異なっています。ただ，公共事業が縮小していることを考慮すると，民間向けの仕事の開拓が進まない航測会社がある場合，生き残れなくなってトプコンとソキアのような経営統合もありえるかもしれないですね。

地図をネット配信　国交省、０８年度実施へ測量法改正
http://www.business-i.jp/news/sou-page/news/200702230025a.nwc

国土交通省は２２日、国土地理院が測量・作製し、刊行している各種地図をインターネットを通じて提供できるよう、測量法を改正する方針を決めた。ネット普及が進む中、国土地理院が持つ地図データを利用しやすくすることで有効活用を促すのが目的。有償とするか無償とするかは今後詰める。今国会に改正案を提出し、２００８年度実施を目指す。

国土地理院はすべての測量の基本となる「基本測量」を行い、都市部を対象とした「１万分の１」のほか、全国をカバーする「２万５０００分の１」から「５００万分の１」まで、主に７段階の縮尺の地図を刊行、書店などで販売している。この地図を、地理院のホームページからダウンロードできるようにする。

地図センターとか大きな書店で数値地図を購入し，幾何補正をしてたこともあるので，インターネットを通じて各種地図が手に入るようになると，非常に楽ですね。ただ，どうやって地図を配信するのかがポイントで，各自ダウンロードして使うのか，完全にWeb Map Serviceとして配信するのか，が気になるところです。個人的にはどちらもやって欲しいです。

「有償とするか無償とするかは今後詰める。」と書いてありますが，国民の税金で作った地図を有償で提供するってのはどうなんでしょう。むしろインターネットを通じてもっと活発に利用してもらえる効果を考えると，有償が基本というのは論外ではないかと思います。

私はWindowsユーザですが，Macもいいなあと最近考えはじめている今日この頃。Appleからいろいろな魅力的な商品が登場しますが，今回は携帯電話のようです。

Mac＋iPod＋携帯でスマートフォン超えを目指す「iPhone」 (ITmedia)
http://www.itmedia.co.jp/news/articles/0701/10/news010.html

Google Mapsはアプリケーション化されており、衛星写真との切り替えも可能だ。

データは無線LANなどでインターネットに接続する必要があると思いますが，ブラウザを介してではなく，iPhoneのアプリケーションの一部となっているようです。また，アメリカのAppleのサイトでは，Google Mapsを使ったデモンストレーションがあります。検索もできてリスト表示も可能。リストアップされた電話番号を直接コールできるようです。

Apple iPhone "Breakthrough Internet Device"
http://www.apple.com/iphone/internet/?feature=feature04

おそらく，GPSとの連携へと繋がっていくでしょう。日本でもいつかは発売されると思うので，期待したいところです。

あけましておめでとうございます。今年も，当サイトをよろしくお願い申し上げます。

ことし一発目のエントリーです。

WMSは，Web Maps Serviceの略で，ネット上にサーバーを公開して地図情報を配信するサービス(WebGIS)のことで，OGCによって，標準化がなされています。URLに定められた形式に沿ってパラメータを入力すると，地図が画像としてかえってきます。インターネットに接続されたパソコンであれば，誰でも表示させることが可能です。従って，空間データを広く公開する手段として有効です。

WMSやWFSなどは，昔からGISを扱ってきた人達の分野から発展してきたものです。一方で，Ajaxなどを使用した，Google MapsやAlps Lab，MSのLive Searchなどの，どちらかというとIT分野から出てきたWebGISも最近は登場し，マッシュアップが増えているのは，ご存知の通りでしょう。どちらかというと，こっちの方が勢いがあります。

インターフェイスが良いことや，APIで簡単にカスタマイズできること，最初から地図や衛星画像が提供されている点を考えると，情報分野から登場したWebGISに乗っかってサービスを提供していくことが，広く利用してもらうために重要といえます。ただ，データの表現方法の柔軟性や，データの汎用性や空間データの管理の側面を含めて考えると，WMSやWFS（画像ではなく，ベクターデータを配信する標準化された規格）を利用することも重要です。

私は，2つの流れから発展してきたWebGISのメリットを生かせるように，融合させることが有効だと考えています。空間データの格納や配信はWMSやWFSを使用し，配信されたデータを表示する手段として，APIを使った地図を利用するというアプローチです。それを実現するために，自分でWMSを構築し，所属している研究室で受信している衛星画像を配信する仕組みを整えました。そして，WMSで配信されるレイヤーを，Google MapsとGoogle Earthにオーバーレイすることが可能となりました。

実は，2006年の夏からウェブサーバーにMapserverを導入し，WMSを構築していたのですが，設定が良く分からず，あまり進んでいませんでした。冬休みにいろいろといじったところ，やっとうまくいったのでBlogにて紹介することにしました。Google Mapsへのオーバーレイは，John Deck's Blogで紹介されているソースコードを利用しています。

Web Map Service + Google Maps
http://webgli.iis.u-tokyo.ac.jp/modis/merc_map.html

右上の「MODIS Composite」をクリックしてください。このwebgliというサーバーは，レスポンスが早くありません。ですので，表示されるまで少しお待ちください。ある程度，拡大表示すると描画されなくなります。一方，Google Earthについては，

http://tagchan.net/blog/2006/09/google_earth_5.html

で紹介しているように，WMS表示機能が搭載されているので，それほど難なく表示できました。kmlファイルで共有できるので，こちらに公開しました。

※現在サーバーは停止しています。

地図とニュースのマッシュアップされたサービスがいくつか登場してきています。先日，共同通信が新しいニュースサイトを立ち上げました。地図とニュースの融合を前面に出した正式なサイトは聞いたことがないので，非常に興味深いところです。

47NEWS
http://www.47news.jp/

地図はゼンリンで，Google Maps API Ver.1のときの画像と同じでしょうか。地図のレスポンスとしては，Google Mapsの方が早い印象。縮尺や表示範囲を変更するたびに，ニュースを読み込んでマッピングしているようです。縮尺は，建物輪郭が見えるところまでズームイン可能です。

上記サイトよりは前面的ではないですが，ニュースと地図が融合した例としては，gooニュースのニュースマップがあります。

ニュースマップ - 日本
http://news.goo.ne.jp/region/

こちらは，Flashをインターフェイスとしていて，関東圏くらいまでしか拡大されません。また，日本だけではなく，世界版もあります。こちらのサイトでは，ニュースのマッピングを点ではなく，ゾーンとして円を描画しています。ニュースのソースと地図をマッピングする際，どういうフィーチャ及び精度で表現するか，といのは難しい問題だと思うので，このマッピングの方法は興味深いです。

とにかく，実際に上記サイトのように，ニュースと地図が融合したサイトが登場したわけです。となると，実際に使用してみて，どういう部分において，今までの地理情報が付加されていないニュースサイトよりも有効性や有用性があるのか，という点が気になる所です。

自分なりの結論としては，現状はニュースの表現手段の1つで，必要不可欠なものにはなり得ない。と思っています。位置情報が付加されると，ニュースに関する情報量は多少増えるという効果はありますが，それが自分の価値観や考え，行動に影響する所までは行かないだろうと思います。なぜなら，自分の行動範囲の外にあるニュースについては，「だいたいあの辺」というのが分かれば十分なのではないか，と考えるからです。

ニュースと地図が融合して，効果が発揮されるのは，いかに自分の行動範囲の近いところにニュースの発生源があるか，という点だと思っています。たとえば，とある場所Aで路上強盗が発生したというニュースが地理情報と共に表現されれば，その近辺を行動範囲とする読者は当然，その道路を通らないように努めるでしょう。

となると，できるだけたくさんの「ニュース」を発信していく必要があるわけです。当然，大手報道機関などは無理でしょう。47NEWSは各県の新聞社を統括している，という点で細かくニュースを発信可能ですが，それだけでは不十分でしょう。既存のマスメディアではそういうことは困難だと思います。

現状では，上記サイトのニュースマッピングは表現手段の1つです。個人の行動に影響するようにするためには，些細ながらもたくさんのニュースを拾ってマッピングする必要があり，それは既存報道機関では困難です。地域の力を借りた枠組みとか，まったく別の新たな枠組みが必要でしょう。そういう枠組みによってニュースがマッピングされて，はじめて，地図とニュースのマッシュアップが有効だったと言えるようになるのかなと考えています。

北米航空宇宙防衛司令部（North American Aerospace Defence Command: NORAD）が，サンタのトラッキングを毎年このシーズンになると行っています。人工衛星などを駆使して，高速でトナカイとそりが駆け抜けている映像が公開されてます。

NORAD Tracks Santa 2006
http://www.noradsanta.org/index.php

さて，そのトラッキングの様子は，Ｌｉｖｅカメラと地図があります。地図はMicrosoftのWindows Live Localを使って表示されています（リンクIE推奨）。一応，サンタのトラックが追えますのでご覧くださいませ。

たまには，世間の話題を追ってみようと思います。もちろん，地図関係ですけど。

アメリカのYahooでは，Google Maps APIが公開されたらすぐに，地図ＡＰＩが公開されていました。そして，とうとう日本のYahooの地図でも，APIの公開が始まったようです。

Yahoo!デベロッパーネットワーク 「Yahoo!地図情報」
http://developer.yahoo.co.jp/map/

リファレンスをみると，まだまだGoogleのように機能が充実しているとまでは言えないでしょう。ただ，Google Mapsとは違って，Yahooの地図はAlps社の技術を使った国産の地図APIなのかもしれません。なので，Google Mapsに負けずにがんばって欲しいものです。

一方，Google Mapsの方はというと，止まっていた日本版ジオコーダーが復活した模様です。

Japanese Address and Placename Support Added to the Geocoding API
http://googlemapsapi.blogspot.com/

サンプルページへのリンクがあり，実際に試してみることができます。

MS、Virtual Earthにリアルな3D地図を追加　(IT media)
http://www.itmedia.co.jp/news/articles/0611/07/news030.html

米Microsoftは11月6日、検索サービス「Live Search」内の地図情報に、建物を3D表示できる機能を追加した「Virtual Earth 3D」を開始すると発表した。実際の建物の写真を元に作成した3D画像を組み入れることで、「よりリアルな」地図を実現したという。

記事の写真によると，建物の壁面がちゃんと描かれています。Google Earthは箱だけだったので，こちらの方がよりリアルといえます。ただ，建物の壁面のデータまで作るとなると，整備するのに手間がかかるでしょう。全国を整備するのは困難ですね。

現時点でこの3D機能には日本からアクセスできないようだが、日本のユーザーにはフルにローカライズされたVirtual Earthが本日から提供開始された。

先ほどIE6からアクセスしてみましたが，サンフランシスコやシカゴなども3次元表示してくれませんでした。なぜ，日本から見ることができないのか意味不明です。早く日本で3次元が見たいですね。

MS、「Live Search」日本語版に地図検索機能を追加 (CNET Japan)
http://japan.cnet.com/news/media/story/0,2000056023,20304047,00.htm

日本版も本格始動しました。いろいろといじっていますが，気になる点が。地図画面左上に地図と航空写真の切り替えや，縮尺の変更ができるウィンドウがあります。そこの＋と－で1段階縮尺を変更できるのですが，縮尺バーとの境界が明確ではなく，間違えてつまみの方をクリックしてしまって，突然全世界が表示されたりしてびっくりしました・・・。

一応，地名を検索すると，地図画面の右上に「スクラッチパッド」というのが登場します。IEだと，ラインやポリゴンが描画できます。色も変えられるようで，これはGoogle Mapsにはデフォルトではこういう機能は付いてないですね。

Google Mapsと比較したいのが，地図そのもの。どちらもゼンリンですが，見た目が全然違います。Googleはゼンリン地図のデータから，自分で描画したようです。

Google Mapsの美麗地図はデータのみZENRIN、描画はGoogle　(ここギコ！様より)
http://kokogiko.net/m/archives/001794.html

ZENRINがベクトルデータのシェープファイルだけを提供したのを元に、Googleが描画したもののようです。

残念ながら，このLive Searchの地図の描画が，Microsoft自身によって行われたのかどうかは不明です・・・。

Google mapsの地図は，縮尺によっては，描画する道路が不適切に選択されているような気がします。なので，色使いとか綺麗さという点ではGoogle mapsに軍配が上がりますが，Live Searchの地図の方が，個人的には，適した表現がなされている印象がします。

※現在公示地価を表示するサーバーは停止しています。

前回に続き、公示地価マップの改良を進めております。今回、新たな機能を追加しました。それは、地価の時系列変化のグラフを、各地点のマーカー上に表示したことです。時間変化がわかるといっても、やはり地点ごとに地価の変化がわかったほうが便利だと思ったので、このような機能を付けました。また、建蔽率や容積率、駅距離など、ダウンロードしたデータに付いていた情報も漏れなく載せることにしました。

ある地点の情報を1つの吹き出しで並べて表示するのは難しいので、Google maps APIで実装可能なタブ機能を活用しました。点をクリックして、地価情報を表示した後、Graphタブをクリックすると、地価の時系列グラフが表示されます。

このグラフ、Rというオープンソースの統計ソフトを用いて、2200点をバッチ処理し、2200枚のグラフを作成しました。自動で作成しているので、相対的には地価の変化が小さいのに、視覚的に価格が暴落しているように見えたりもします。その辺は、自動処理で作成する難しさでしょうか。

住宅地の地価の時系列変化を見ると、おもしろいことがわかります。全体的にはやはりバブルのころは地価が一気に上昇し、その後は下落します。ただ、下落の仕方に種類があるようで、だらだらと下がっていく場合、2000年まで下落して、それ以降、さらに下落する割合が大きくなる場合とか、いろいろあります。もちろん、周辺の開発の状況とか、立地条件によっていろいろと変わるわけでしょうけど、いろいろと考えをめぐらせて見ると面白いかもしれませんね。

Land prices @ Kanagawa
http://webgli.iis.u-tokyo.ac.jp/chika/index3.html

※現在公示地価を表示するサーバーは停止しています。

前回のエントリーで，公示地価マップを紹介しましたが，早速改良してみることにしました。改良点は次に示す2点です。

1. 地名や住所によるジャンプ機能
地名や住所を入力すると，自動的にその場所付近にズームするようにしました。Google Mapsでは，ジオコード機能があり，住所を入力すると地理座標を返してくれます。ただ，日本ではその機能が実装されていません。そこで，Google Ajax Search APIというのを使い，代替することができます（参考サイト①，②）。例えば，「遠藤」と入力しても，ちゃんと藤沢市遠藤に移動します。もちろん，全国に同じ地名はあるでしょうから，間違えて飛んでしまうこともあるはずです。

2. 土地利用カテゴリごとの表示
公示地価には，住宅地・宅地見込地・商業地・準工業地・工業地・市街化調整区域内宅地・林地というカテゴリがあります。ですので，カテゴリごとに表示することもできるようにしました。右側にプルダウンメニューを用意しましたので，それを選択すると，切り替わります。
ただし，年度を変更する場合，いったん全カテゴリが表示しなければなりません。例えば住宅地だけ見たい場合は，いちいち変更しなければならないのが不便な点です。

Land Prices @ Kanagawa
http://webgli.iis.u-tokyo.ac.jp/chika/index3.html

てなわけで，地価マッピングはこれでひと段落でしょうか。ただ，「都道府県地価調査」のデータもマッピングできそうなので，それもやってしまうかも・・・。

※現在公示地価を表示するサーバーは停止しています。

今までは，自然関係のデータをマッピングしてきましたので，今回はそれとは反対の，人間的なデータをマッピングしてみようと思いました。それは地価です。地価の上昇とか下落とか，たまにニュースになりますよね。

基準地価、３大都市圏１６年ぶり上昇（読売新聞）
http://www.yomiuri.co.jp/homeguide/news/20060919hg03.htm

国土交通省は１９日付で、２００６年の基準地価（７月１日時点）を発表した。東京、大阪、名古屋の３大都市圏の平均で、住宅地が前年比０・４％上昇、商業地は同３・６％上昇し、ともにバブル期の１９９０年以来、１６年ぶりに上昇に転じた。 　東京など大都市の中心部で先行した地価の回復が郊外にも広がり、都市圏全体の地価を押し上げた。一方、全国平均は、住宅地が同２・３％下落、商業地が同２・１％下落し、いずれも１５年連続で下落したが、下落率は３年連続で前年より縮小し、下げ止まりに向けた動きもうかがえた。

地価はいくつか種類があるみたいですね。「基準地価」というのが，都道府県が調査する毎年9月1日の地価（参照）。「公示地価」というのが国土交通省が調査する1月1日の地価（参照）。上記記事の地価は基準地価らしいです。

やはり，バブルの頃からは地価は低いんだろうな，となんとなく想像できますね。ただ，実際にどういうところで地価が高かったり低かったりするのか，バブルの頃からの地価の変化，というのは興味深いところです。上記記事によると，都市圏では上昇していますが，都市圏外では下落しているところもありそうですね。

てなわけで，Google Mapsにてマッピングしてみることにしました。先日の記事に書きましたが，日本の地図が更新され，見た目もきれいになりました。地価が示されている所はどんな場所か，一目でわかるので便利ですよね。

データは，国土数値情報から平成18年度版公示地価をダウンロードしました。このデータは，緯度経度が付いているので，マッピングが非常に簡単です。さらに，1984年からの地価があるので，過去の地価もマッピング可能なのです。

Land price of Kanagawa
http://webgli.iis.u-tokyo.ac.jp/chika/

このマップの特徴
① 1984年から2006年まで表示可能
バブルの頃と，現在の比較ができます。2006年は2000点くらいプロットするので，ブラウザが重くなってしまうという問題点があります。

② 価格による色分け表示
価格別に青や赤で色分け表示しました。凡例も示してあります。さらに�