2008年12月アーカイブ

はじめに

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がブレークする可能性は十分にある。

以前のエントリで，Twitter検索を利用して天気関連のつぶやきを抽出するサービスをはじめたことを紹介した。

Twitterの天気関連つぶやきの抽出
http://www.tagchan.net/blog/2008/06/weathetter.html

今回，別のTwitter検索を発見して，それなりに良さそうな検索結果を返してくれるので，同じことをやってみた。

Weathetter(うぇざったー) twitter天気関連投稿解析サービス Ver. 2
http://www.tagchan.net/twitter/weathetter.php

基本的に前回と同じキーワードで検索している（ただし，うまく動作しているのかが良くわからない）。円グラフのカテゴリやキーワードについては，少し調整するかもしれない。

気象協会が天気APIを公開することを発表しており，うまく連携できる可能性があるかもしれない。また，天気関連のつぶやきは，携帯やiPhoneなどのモバイルで投稿することも多いと思う。そのため，位置情報が重要となってくると思う。たとえば，loc8rやBrightkiteなどの位置情報を重視したSNSやマイクロブログが出てきているので，その辺と連携できれば，天気情報の分野から見れば一つのブレークスルーになるのではないかと考えている。

ノートPCを買い換えた。今までは，ThinkPad X40を持ち運び用兼メインPCとして4年9ヶ月くらい使い続けてきた。ちょうど博士論文を書き上げたところで，自分へのご褒美として購入した。最初はネットブックも興味があったが，やはり１台で全部済ませられるノートPCが良いと思い，ThinkPad X200sを選んだ。構成は以下のとおり。

・WXGA+ LEDバックライト液晶 (1440x990)
・1.86Ghz SL9400
・2GB DDR3 RAM
・4セルバッテリ
・250GB HDD (5400rpm)
・Windows XP （ダウングレードでインストール済み）
・無線LAN
・Bluetooth

直販サイトで，購入。いろいろとカスタマイズができて，20万の構成だった。さらに5％引きで19万で購入。2chのX200のスレッドを見ていて，購入時にトラブルが発生している人が多いらしく，非常に不安だったのだが，11月27日注文で12月11日到着ということで，ほぼ予定通りの2週間で届いた。PCの構成も注文どおりで，今のところトラブルはない。

PCが入った箱。届いたときは，さらに一回り大きいダンボールに入っていた。

構成のリスト。直販サイトでは注文後に構成が確認できない問題がある（メールにも構成の一覧は送られてこない）ため，もし直販サイトで購入する場合は，購入時に構成の表を印刷しておくことをお勧めする。

以下はX40との比較した写真である。やはり横幅がある。でも，その分だけキーボードの横幅は余裕がある。また，液晶は額縁のようになっており，縦のサイズはX40の方が大きいのだ。

電源アダプタの比較。右がX40で左がX200sである。X40は3代目のアダプタである。X200sのアダプタの方が軽かった。

使って数日だが，とても快適である。X40と差がありすぎる部分もあるが，非常に満足している。キーボードも打ちやすい。液晶については，LEDバックライトでとても明るい。また，この液晶サイズで1440x990なので，デスクトップは広く感じている。

問題はインナーケースだった。X200sの純正インナーケースは出ていない。X200sのサイズはややイレギュラーなので，探すのに苦労した。明治神宮前にあるAssist Onに行き，実際に試してBUILT NY Cargo Sleeveを購入。このケースなら，むき出しで持ち運びもできるので，便利。ただ，ケース自体がやや重い。

いつの間にか，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は，既にこれに対応して書き換えられている。

結論を先に言うと，天気情報（アメダスも含めて）の基本的な項目は，気象庁が無料でAPIとして公開し，気象会社以外のユーザが，どんどん気象情報を有効活用できる枠組みにするべきである。ただし，気象業務法で認可が必要な場合や，警報，地震，津波などの防災上重要な情報は，その限りにあらず，である。

昨日，日本気象協会が天気情報APIを公開するとプレスリリースを出したが，前々から天気情報APIの必要性は感じていた。すでに，Livedoorがそういうサービスを始めているが，配信している情報の幅が狭いと思っている。

思い切って，気象庁は地震，津波，警報などの防災上重要な事項は除いて，APIとして気象情報を全部配信すれば良いと思う。そうすれば，気象業界だけにとどまらず，気象情報が様々な分野で使われることになるだろう。そして有益な情報として，天気情報は確実にステップアップできると思う。

さらに，配信する情報は地理情報として配信するべきである。天気の情報は，地図の上に重ねられていることが多く，地理情報なのである。しかし，現状では画像として見ているだけに過ぎない。位置情報系サービスがたくさん出てきていることを考えると，その辺を見越して地理情報として発信すべきである。

そうなると，気象会社は無料の情報があることを前提で，付加価値の高い情報の発信に注力し，そこでお金を儲けるような枠組みにできる。また，新たな企業が参入しやすくなり，気象予報士のニーズも増える思う。既存の気象会社全体の利益が増えることに貢献するのかは分からないが，社会全体としては，この方が利益が大きいだろう。これがまさしく，この時代の「気象情報の自由化」だと思う。

もちろん，業務で気象情報が重要な場合や，時間との勝負となる防災に関する重要事項については別である。また，自由化しても，気象業務法で認可が必要なケースが出てくるかもしれないので，その辺の線引きを明確にする議論は必要であり，登録制にして気象庁が定期的にクオリティコントロールはする必要はあるだろう。

この業界からは離れているので，最近の状況をよく知らないが，外野の意見として書いてみた。