Comments
Description
Transcript
GPS を用いた即時性のある情報投稿 プラットフォームの
平成 21 年度 フロンティアプロジェクト 修士学位論文 GPS を用いた即時性のある情報投稿 プラットフォームの開発 A news contents posting platform using GPS functions 1125142 岡添 拓典 指導教員 清水 明宏 2010 年 3 月 4 日 高知工科大学大学院 フロンティア工学コース 要 旨 GPS を用いた即時性のある情報投稿 プラットフォームの開発 岡添 拓典 Weblog とは誰もが容易に情報発信を行える Web サービスのひとつである．近年では， Weblog は様々な目的のために利用され，その市場を大きく拡大させた．しかしながら，店 舗やイベントなどの位置情報を発信するという目的に対し Weblog では，記事内に詳細な 位置情報を文章で記述するか，電子地図サービスにリンクを張るなどの対策をユーザが行 う必要がある．記事投稿者や記事閲覧者の負担を軽減するため，梅山らによって電子地図と Weblog を組み合わせた elemap blog が開発された．elemap blog では位置情報と Weblog とを紐付けすることで，誰でも簡単に位置情報を持った blog 記事を投稿できるようになり， Weblog の利用の幅を広げた．一方で，近年の Web サービスでは，携帯電話の普及や高性 能化によって，即時的な情報をやりとりするサービスに注目が集まっている．その中で携帯 電話は，テキストや画像などの情報を柔軟に投稿できるインターフェースとして利用されて いる．しかし，elemap blog では，PC からの情報投稿は行えるが，携帯電話を用いた即時 的な情報投稿には対応していない．本論文では，携帯電話の GPS 機能を用いた即時性ある 情報を投稿できるプラットフォームを開発し，評価した． キーワード 携帯電話，GPS，電子地図，即時性 –i– Abstract A news contents posting platform using GPS functions OKAZOE, Hironori Weblog is Web service that can posted articles easily by everyone. Recently, weblog is used for various purposes, and has increased number of users. However, weblog users should take measures such as writing addresses in articles, or providing links to digital map services, when weblog user’s purpose is to post addresses of stores and local events. There, Umeyama developed elemap blog aiming to reduce imposition of writers and readers. Elemap blog is composed of digital maps and Weblog. For this reason，users can post articles which has addresses easily. Elemap blog expanded the feild of use of Weblogs. On the other hand, in recent web services, people are taking notice of Web services that exchange news, because mobile telephones became popular and high performance. People are exchanging information composed of texts, images and more, by using mobile telephones as a flexible interface. However, when users post news, users cannot use mobile telephones in elemap blog. In this paper, I developed a news contents posting platform using GPS functions, and evaluated the platform. key words Mobile-telephone,GPS,Digital-map,news – ii – 目次 第1章 序論 1 第2章 Weblog と WebGIS 3 Weblog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 2.2 第3章 2.1.1 記事投稿者への負担 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2 記事閲覧者への負担 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Web GIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1 電子国土 Web システム . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2 GoogleMaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 elemap blog と Web サービスのニーズ変化 10 3.1 elemap blog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Web サービスのニーズ変化 . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 elemap blog の課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 即時性のある情報投稿プラットフォーム 14 第4章 4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.1 情報描写フェーズ . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.2 情報投稿フェーズ . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.3 情報保存フェーズ . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 他サービスへのデータ提供 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 評価 20 5.1 実験環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2 処理時間の計測 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2 第5章 提案システム構成 – iii – 目次 5.3 機能比較 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 結論 24 6.1 災害時被災者間情報共有サービス . . . . . . . . . . . . . . . . . . . . . . 24 6.2 地域広告配信サービス . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 第6章 謝辞 27 参考文献 28 – iv – 図目次 2.1 電子国土 Web システム . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 GoogleMaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3 Google Static Maps API . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 提案システム：メインページ . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2 提案システム：地図とマーカーの表示 . . . . . . . . . . . . . . . . . . . . 17 4.3 提案システム：投稿情報の表示 . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4 提案システム：メーラ起動リンク . . . . . . . . . . . . . . . . . . . . . . . 19 4.5 ある地点におけるユーザの行動特性例 . . . . . . . . . . . . . . . . . . . . 19 5.1 elemap blog 上での投稿場所決定手順 . . . . . . . . . . . . . . . . . . . . 22 5.2 提案システム上での投稿場所決定手順 . . . . . . . . . . . . . . . . . . . . 23 6.1 災害時情報共有サービス概要 . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.2 地域広告配信サービス概要 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 –v– 表目次 5.1 提案システムの実験環境と開発言語 . . . . . . . . . . . . . . . . . . . . . . 20 5.2 使用 PC の性能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3 データ表示時間 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 – vi – 第1章 序論 情報通信技術の発展に伴うインターネット人口の増加と共に様々な Web サービスが登場 している．特に市場を大きく拡げた Weblog は，誰でも容易に情報を発信できる Web サー ビスとして注目されている．また，Weblog では投稿者同士，もしくは投稿者と閲覧者との コミュニケーションの取り易さも特徴のひとつであり，様々な分野において情報発信のツー ルとして用いられている．現在，Weblog サービスへの登録人数はのべ 2,600 万人以上とさ れているが，サービスに登録していない閲覧者等を含めると 2,600 万人を大きく上回るとも されており，今後も増加していくことが予想される [1]． Weblog の発展に伴い，投稿されている記事から特定の地域に限定した口コミ情報を取得 しようとするユーザが増加している．しかし，記事上で書かれている地域を示す情報は，投 稿者によって表記が異なり，表記された地域周辺の土地勘を持たない人にとって理解し辛い ことがある．土地勘のないユーザにも記事に関連する地域を理解し易くするため，Weblog と WebGIS(Web Geographic Information System) を組み合わせた elemap blog が梅山ら によって提案された [2]．elemap blog によって投稿される記事の内容と Web GIS によって 得られる位置情報が紐付けされ，投稿者は客観的な位置情報を記事に付与し，投稿すること が可能になった．また，記事に位置情報が付与されたことで，特定の地域に限定した口コミ 情報の収集を可能にした． 一方で，近年，Web サービスを取り巻く環境に変化が現れている．携帯電話の普及と高性 能化によって，何時でも何処でも Web サービスの恩恵を享受できる環境が整備され始めて いる．このため，Web と携帯電話を併用した即時的な情報をやり取りするサービスに注目 が集まっている [3]．その中で携帯電話は，テキスト情報や画像情報，GPS 機能によって取 –1– 得できる位置情報などの情報を柔軟に投稿できるインターフェースとして利用されている． 本論文では，梅山らの elemap blog を拡張し，GPS 機能を用いて即時性のある情報投稿 を可能にするプラットフォーム導入について述べる． 第 2 章では，基盤技術である Weblog と WebGIS について述べる．Weblog の特徴を述 べた後，WebGIS の技術的な特徴について述べる．次に第 3 章では，elemap blog の課題 について述べる．elemap blog の特徴について述べた後，elamap blog を含む Web サービ ス全体を取り巻くニーズ変化について述べ，課題となる点を整理する．第 4 章では，提案す る方式について述べる．提案するシステムについて具体的に述べ，データの取り扱いについ て述べる．第 5 章では，開発したシステムに関する評価基準について述べた後，評価を行っ た結果から考察を述べる．最後に第 6 章では，本論文の成果をまとめ，今後の展望について 述べる． –2– 第2章 Weblog と WebGIS Weblog とは情報技術に関する専門的な知識を持たないユーザでも，Web 上に情報発信 を行う Web ページ領域を確保することで，情報発信を行うことができる CMS(Content Management System) である． Web GIS は，Web 技術を利活用した GIS である．GIS とは，コンピュータ上に地図情 報やさまざまな付加情報を持たせて統合し，総合的に処理・管理・分析を行い，その結果を 表示するコンピュータ情報処理システムである．特に，Web などのネットワークをり活用 する GIS を Web GIS を呼ぶ． 本章では，既存研究である elemap blog 及び提案システムの基盤技術である Weblog と Web GIS について述べる． 2.1 Weblog Weblog は誰もが容易に情報発信を行える情報投稿 Web サービスのひとつである． Weblog の主な構成は公開用ページと管理用ページの 2 つで構成されている．公開用ページ には，個人ごとの TOP ページとこれまでに投稿されてきた記事ページによって構成されて いる．TOP ページには，それぞれの記事ページへのリンクやユーザプロフィール，または そのリンクなどが用意されている．記事ページには，コメントを記入するフォームがあり， 記事閲覧者はコメントフォームを利用することで，記事投稿者とのコミュニケーションをと ることが可能である．一方，管理用ページでは，投稿記事の管理やコメントの削除，公開用 ページのデザイン変更などが可能である．続いて，Weblog の問題点を記事投稿者と記事閲 –3– 2.2 Web GIS 覧者に分けて説明する． 2.1.1 記事投稿者への負担 イベントの内容を blog 記事として投稿する際には，イベントの行われる時間や場所，イ ベントの内容などが記述される．記事投稿者が文章や画像を用いて記事の内容を記述するこ とで，記事閲覧者に情報を発信することができる．しかし，記事投稿者がイベントに関連す る位置の情報を発信する場合，電子地図などを用いて地図の画像を用意し，編集しなければ ならない．イベントに限らず，地域に根差した店舗などの情報を発信する場合においても， 記事投稿者は店舗の位置情報を調べ，画像や文章を用いて記事を記述する必要がある．ま た，詳細な地理情報を発信したい場合，外部の地図アプリケーションなどとのリンクを張る 必要も求められる． 2.1.2 記事閲覧者への負担 記事を記述する書式は記事投稿者によって異なるため，必ずしも記事投稿者が万人が理解 できる地域名を使用して記事を記述するとは限らない．また，記事投稿者が文章のみで記述 した場合，記述内容が生活圏と関連がない記事閲覧者は，投稿された記事が関連する場所 がどの地域なのか知ることができない．そのため，記事に興味を持った記事閲覧者は，自ら 地図を調べるなどしてイベントが行われる場所までの経路に関する情報を取得する必要が ある． 2.2 Web GIS GIS とは電子情報化した地図データと空間データ (地理的位置や空間に関する情報を持っ た自然・社会・経済等の属性データ）をコンピュータ上で統合させ，総合的に処理・管理・ 分析し，その結果を表示するコンピュータ情報処理システムである．カナダの森林保護管理 システム CGIS(Canadian GIS) は，世界で最初に動作可能な GIS として開発された．ただ –4– 2.2 Web GIS し，CGIS は政府機関向けであり，また，開発当時のハードとソフト両方の技術の限界に近 いものであったため，普及することは無かった．我が国においては，1970 年代より GIS に 関する研究が始まった．ただし，GIS に関する本格的な取り組みが始まったのは，1995 年 に起きた阪神淡路大震災にて，関係機関が保有していた地理情報を効果的に活かすシステム がなかったことに起因するといわれている．現在 GIS は，行政機関や各自治体で利活用さ れている他，Web 上で個人から発信された情報を集約する情報流通の基盤としても用いら れている．個人による WebGIS を用いた情報発信を可能にしたのは，プログラムライブラ リである API(Application Program Interface) が公開されたためである．API を用いる事 で，開発者は複雑なプログラムを一から組む必要が無く，簡単なプログラミングのみでコン テンツ開発が可能になった．地図導入のための API を国土地理院が電子国土 Web システ ムを平成 15 年に初めて公開した後，GoogleMaps をはじめとする LSP(Location Service Provider) が続いて API 公開を行った．これらのサービスは API を公開することによって， 誰もが簡単に地図を用いたサービスの実現を可能にし，ユーザが地図を自由にカスタマイズ できる仕組みを拡げていった．API の公開は，マーケティング戦略上でも注目を集めてい る．公開された API を開発者が利活用することで，Web サービスやシステム構築事例が増 え，Web 上での宣伝広告が自然に広がるためである．誰もが自由に無償で利用でき，日本 国内で認知度が高い電子国土 Web システムと GoogleMaps について解説する． 2.2.1 電子国土 Web システム 電子国土 Web システムは，数値化された国土に関する様々な地理情報を位置情報に基づ いて統合し，コンピュータ上で再現する仕組みである [4]．2010 年 2 月の時点では，電子国 土 Web システムを利用する場合，対応している OS は，WindowsXP/2000 である．また 以下の Web ブラウザに対応している． • Internet Explorer 5.01 以降 • Nerscape 7.0 以降 –5– 2.2 Web GIS • Mozilla 1.4-1.5 電子国土 Web システムをシステム実装するにあたり，プラグインソフトのインストール を必要とする電子国土 Web システム Version1 とプラグインを必要としない非プラグイン 版の電子国土 Web システム Version2 がある．プラグインソフトをインストールしている か否かで，起動する Version が異なり，電子国土 Web システム Version2 では，一部機能 が利用できない仕様となっている．電子国土 Web システム Version1 での実装を行うには， 国土地理院により無償公開されている Microsoft Internet Explorer 用のプラグインが必要 になる．動作環境として，ブラウザは Internet Explorer 6.0 以降，対応 OS は，Windows 2000，XP，Vista である．一方，電子国土 Web システム Version2 ではプラグインを必要 としないため，多くのブラウザでの動作が可能である．2010 年 2 月時点では以下のブラウ ザが対応している． • Internet Explorer 6.0 以降 • Firefox 2.0 以降 • Opera 9.0 以降 • Safari 2.0 以降 電子国土 Web システムの動作について，図 2.1 を用いて説明する． 電子国土 Web システムが扱う地理情報は，地理情報の発信者により作成された主題地図 データと国土地理院のサーバから発信される背景地図データの 2 種類に分けて処理される． 主題地図データは，経度緯度を含む位置情報と地名などの地理情報から構成されている．背 景地図データは，国土地理院が全国の 1/2000 万相当の地図データから 1/25000 相当の縮 尺データの配信を行なっている．サイトの利用者が Web ページアクセスしたとき，この主 題地図データとそれに必要な範囲・精度の背景地図データを自動的にサーバから読み出し利 用者のブラウザ上で重ね合わせて利用する仕組みとなっている．背景地図データは世界測地 系の緯度経度を座標系とするベクトルデータである．背景地図データはプラグインが自動的 に読み出し，重畳処理を行うため，地理情報を発信する側で者はその動作について触れる必 –6– 2.2 Web GIS 要がない．また，主題地図データは，データ内に表記された緯度経度により背景地図データ と対応している．電子国土 Web システムを利用した Web サイトでは，主題地図データと 地図を操作表示するためのユーザインターフェースを用意するだけで，地理情報を発信する Web サイトを構築することができる． 2.2.2 GoogleMaps GoogleMaps は，図 2.2 のように，Google 社が 2004 年に公開したオンライン地図情報 サービスである．地図のインターフェイスには Ajax(Asynchronous JavaScript + XML) と呼ばれる技術が用いられている．Ajax の非同期通信によって，クライアント側で特殊な プラグインなどを用いることなく，Web ブラウザのインタフェースの中で動作し，シーム レスなマウスドラッグによる移動や，地図の縮尺変更を行うことが可能になっている [5]．ま た，GoogleMaps では通常の地図表示 (地図) の他，実写の衛星写真を表示するサテライト (航空写真)，地図と衛星写真を重ね合わせて表示するデュアル (地図＋写真) 等，複数の地 図表示を行うことができる．GoogleMaps は，API としても公開されており，GoogleMaps のページだけでなく，GoogleMaps API を用いる事で，他の Web サイトに機能を組み込む ことができる．また，組み込むだけでなく，ユーザ側で地図機能のカスタマイズも可能であ 図 2.1 電子国土 Web システム –7– 2.2 Web GIS る．2010 年 2 月の時点では，GoogleMapsAPI は以下の Web ブラウザに対応している． • Internet Explorer 6.0 以降 • Firefox 2.0 以降 • Safari 3.1 以降 また，2008 年からは携帯電話端末からでも利用できる Google Static Maps API をサー ビス開始した．これまでの GoogleMaps と同様に，地図作成画像や状況に応じた地理情報 を利用して，地図の表示が可能であるが，Google Static Map API では指定されたエリアの Google MAP が画像として動的に生成される．HTML タグに必要な情報を入力し，Google Static Maps API に情報を渡すことで，Google MAP の画像を取得できる．画像として クライアントである携帯電話端末に地図データが引き渡されるため，JavaScript が動作し ない端末においても，GoogleMaps の地図データを利用することが可能になった．Google Static Maps API が利用できる携帯電話端末は，Web に接続可能で，GIF，JPEG，PNG の一般的な Web 画像の形式に対応している端末であれば利用することができる．Google Static Maps API においても，図 2.3 のように，GoogleMaps 同様に他の Web サイトにそ の機能を組み込むことができる．通常の GoogleMaps のようにシームレスな動作は不可能 図 2.2 GoogleMaps –8– 2.2 Web GIS だが，携帯電話が持つ GPS 情報と連携を取り，JavaScript が動作しない端末でも利用可能 である． 図 2.3 Google Static Maps API –9– 第3章 elemap blog と Web サービスの ニーズ変化 前章であげた，Weblog の問題点を解決し，サービスに係わるプレイヤの負担を軽減する ことを目的として，梅山らによって，電子地図と Weblog を組み合わせた elemap blog が 開発された． 本章では，elemap blog によって，Weblog の課題がどのように解決されたか述べ，Web サービス全体としての環境の変化について述べる．次に，変化した環境に対応するための課 題について述べる． 3.1 elemap blog Weblog では，多種多様な情報発信が行われている．しかしながら，位置情報を発信する という点において，記事投稿者と記事閲覧者に負担がかかってしまう問題がある．問題を解 決するにあたり，elemap blog の目的はコンピュータなどに対する専門的な知識を持たない ユーザでも，容易に位置情報を付与した情報発信を可能とすることである．しかし，Weblog 上に単純に地図を表示しても，ユーザによって土地勘のある場所は異なるため，目的の場所 を把握し難い．ユーザが土地勘のない場所の地図を見た際，地図が示す場所を正確に理解で きるユーザは限られている．そこで elemap blog では，S2S(Spot to Spot) システムを実装 した．S2S システムとは，目的の場所までの道順，方角，距離などをユーザの土地勘のある 場所から提供することで，ユーザの位置理解を補佐するシステムである．土地勘のある場所 – 10 – 3.2 Web サービスのニーズ変化 としてユーザの生活圏を登録する．ユーザに対し，始めに土地勘のある地域を表示すること で，ユーザは目的の場所までの距離や方向をより理解しやすくなる． このシステムを実装することにより，elemap blog では，位置情報と Weblog とを紐付け することが可能であり，誰でも簡単に位置情報を持った blog 記事を投稿できるようになっ た．また，記事を閲覧するユーザにおいても，他の Web サービスや地図を利用しながら記 事を閲覧する必要が無く，記事が指す場所までの経路を理解できる． 3.2 Web サービスのニーズ変化 前節では elemap blog の目的と特徴について述べた．本節では，elemap blog 含めた Web サービスのニーズ変化に付いて述べる． 携帯電話が普及し，携帯電話ユーザは何時でも何処でも，Web につなげることが可能に なり，それ伴い，携帯電話を用いた Web 利用が増加している [6]．また，Web を用いたサー ビスにも携帯電話に対応したものや携帯電話を対象としたものが登場し始めた．また，携帯 電話から利用できるという利点を活かし，即時的な情報をやりとりするサービスが求められ るようになった．またそうした中で，ライフログサービスが注目されている． ライフログとは，ユーザの行動に関するすべてのデジタルデータを記録することである． ライフログの一例として下記のようなものがあげられる． • クレジットカードなどの購買履歴 • メールなどのテキスト情報 • デジタルカメラのデータ • 年間を通したスケジュール情報 • 身体的な情報 • GPS 情報などの位置情報 ライフログサービスとは，ライフログを収集，分析し，情報やサービスを個人レベルにまで 絞り込み，提供するサービスである．インターネット販売などでみられる購買履歴から商品 – 11 – 3.3 elemap blog の課題 を推薦するシステムもライフログサービスと言える． Web そのものが普及した現在では，ライフログの収集・蓄積，分析は容易になりつつあ り，市場の成長が期待されているが，特に携帯電話市場での爆発的な成長が見込まれている [7]．これは，携帯電話の普及と高性能化が関係している．現在の携帯電話には，様々な機能 が付加されている．Edy をはじめとする電子マネーやカメラ，音楽プレイヤーやスケジュー ラ，GPS 機能など，高性能化し，多くのデジタルデータを含む携帯電話はライフログの宝 庫である．ライフログサービスと携帯電話は今後，益々結びつきを強くしていくだろうと言 われている．その中でも，GPS 機能が特に注目を集めている． GPS 機能によって得られる GPS 情報 (緯度・経度) や GPS 情報を付与したデータを蓄 積・分析することで，ユーザの行動範囲を特定することが可能である．また，GPS 情報が 得られた日時などパラメータとして保存し，分析を進めることでユーザの行動範囲ばかりで なく，ユーザの行動に関する規則性や特性を発見することも可能である．得られたユーザの 行動特性をプロファイルし，蓄積しておくことで，ユーザが行動する地域の情報を効果的な タイミングで配信できるなど，ライフログの幅広い利活用に期待されている． 携帯電話が普及し，ライフログサービスの登場やユーザの行動履歴の蓄積によるサービス への利活用などによって，即時性のある Web サービスが求められている． 3.3 elemap blog の課題 本節では，elemap blog の課題について述べる． 現在，elemap blog への記事投稿は PC から行われている．Weblog の投稿によって， ユーザの趣味嗜好を持った情報を elemap blog では収集し，蓄積・分析し，プロファイルす ることが可能である．また，Weblog と Web GIS の融合によって，ユーザの位置情報も蓄 積されている．そのため，elemap blog を用いて，ライフログサービスのような，ユーザ個 人をターゲティングしたサービスを展開することが可能である．しかしながら，情報投稿を PC からでしか行えず，即時性が求められている現在の Web サービスのニーズに対応して – 12 – 3.3 elemap blog の課題 いない． そこで本研究では，GPS 機能を用いて，即時性のある情報投稿を可能とする情報投稿プ ラットフォームを開発する． – 13 – 第4章 即時性のある情報投稿プラット フォーム 提案システムでは，携帯電話端末を用いて，情報の投稿と取得を行う．携帯電話のどの端 末からでも利用できるよう，特定のキャリア向けのアプリケーションとしてではなく，Web 上の動作を前提として開発を行う．携帯電話端末には，我が国での携帯電話端末のシェアを 占める DoCoMo と au と SoftBank の 3 キャリア製の携帯電話端末を対象とし，その中で も，ユーザへの普及率が高い，第 3 世代携帯電話に分類される機種を対象とした． 4.1 提案システム構成 提案システムの構成は，大きく分けて，携帯電話から GPS 情報を取得し，地図の描写を 行い，同時に描写範囲に投稿された情報をデータベースより取得・表示する情報描写フェー ズ，携帯電話端末のメーラを起動し情報投稿を行う情報投稿フェーズ，携帯電話端末より情 報投稿が行われた時，情報を分析し，データベースに保存する情報保存フェーズの 3 つに分 かれている．それぞれのフェーズについて仕様と流れを示す． 4.1.1 情報描写フェーズ 情報描写フェーズは，Google Static Maps API を用いて開発を行った．Google Static Maps API では，JavaScrip を使用しておらず，GPS 機能より取得した緯度経度の情報を 引き渡すことで，引き渡した緯度経度を中心とした Google Map が画像ファイルとして動 – 14 – 4.1 提案システム構成 的に生成される．JavaScript は特定の端末で動作しない恐れがあるほか，処理性能の劣る 端末の場合，ユーザビリティの面から動作が遅くなるといった問題が発生する．このため， Google Static Maps API を用いることで，JavaScript を用いるよりも対象を幅広く取れ， かつ，低処理端末でもある程度軽快な動作が期待できる．また，携帯電話での操作を考え， ユーザ自身が操作せず，基本的な動作はバックグラウンドで行う必要がある．クライアント 側である携帯電話での処理は地図を描写するなどの画面処理のみとし，その他の処理はサー バ側で行う． 投稿された情報を表示する際には，Google Static Maps API で提供されているマーカー を使用する．Google Static Maps API では API に位置情報を指定し，画像を生成して画 面表示を行うため，投稿された情報を重ねて表示を行うと，地図部分が投稿された情報に覆 われ，視認性が落ちてしまう．そこで，視認性を高め，かつ投稿された位置をユーザに示す ためにマーカーを利用し，番号を割り振ることで問題を回避する．情報自体は画面をスク ロールすることで閲覧でき，割り振った番号との紐付けを行う．この時，投稿された情報を 際限なく表示すると，マーカーによっても地図が覆われ，位置情報の視認性を損ねてしまう ため，同時に表示される投稿情報の上限を 5 つまでと定めた． 続いて，情報描写フェーズの流れを示す．ユーザが図 4.1 のようにメインページにアクセ スを行った際，使用している端末を選択する．GPS 情報の提供の有無をユーザに確認し， ユーザが許可すれば，GPS 情報を受け取り，次の画面へ遷移する． 取得した GPS 情報を中心とし，携帯電話の画面に地図の表示を行う．地図を表示する際 には，画面表示内の領域に既に投稿された情報が存在しないか，データベースにアクセス し，データが存在すれば，緯度経度の情報を取得する．(投稿された情報のデータベースへの 保存形式は，本節後の情報保存フェーズにて示す) 取得した位置情報を順次 Google Static Maps API のマーカーへ引き渡し，図 4.2 のように，ユーザが提供した GPS 情報を中心に， 地図とマーカーの表示を行う． また，図 4.3 のように，地図の下方には投稿された情報がマーカーに振られた番号と紐付 けられて，表示されている． – 15 – 4.1 提案システム構成 4.1.2 情報投稿フェーズ 情報投稿は携帯電話に搭載されているメーラを用いて行う．画像の投稿は，携帯電話を用 いて Web ページ上から行うことができない．画像の投稿とテキストを分けて投稿すると ユーザへの操作負担が増えるだけでなく，サーバ側でも，後から投稿される画像ファイルと， 先に投稿されたテキスト情報との紐付けを行う必要があり，合理的でない．搭載されている メーラを利用することで，ユーザが普段から使い慣れたフォームをそのまま投稿フォームと して利用することができるといった利点もあるため，本システムでは情報投稿に携帯電話に 搭載されたメーラを使用する．図 4.4 の中央にあるリンクをクリックすることで，メーラが 起動する． このとき，ユーザが直接位置情報を本文ないしタイトル打ち込むことは操作性を損なう． そのため，情報表示フェーズで取得したユーザの GPS 情報をタイトルへ直接挿入しておく． また，投稿先であるメールアドレスも同時に指定しておく．ユーザは，画像を投稿したい場 合は，通常の携帯電話メールを送る時と同様に画像を添付するだけでよい．テキスト情報は メールの本文部分に記述する．ユーザは情報を記述し，メールを送信することで情報投稿を 図 4.1 提案システム：メインページ – 16 – 4.1 提案システム構成 完了し，操作は情報表示フェーズへと戻る． 4.1.3 情報保存フェーズ 本フェーズは，ユーザからの情報投稿があった際，分析・分解し，データベースへ保存す るフェーズである．ユーザの情報投稿は，メールで行われる．メールサーバで受信したメー ルを分析し，データベースに格納する．メールの構成は，送信者アドレス，タイトル，添付 ファイル，本文に分けられる．送信者アドレスはユーザ ID と紐付けることで本人確認が可 能なため，保存する．タイトルには，GPS 情報が緯度経度を「,」(カンマ) で区切って挿入 されている．GPS 情報は情報表示フェーズにて，緯度経度それぞれの値に分けられるため， 挿入された状態のまま，保存する．添付ファイルは，取得した際，サーバ直下のディレクト リに保存する．保存する際に，添付された画像ファイルのファイル名をサーバ側がメールを 受信した時間にリネームする．これは，投稿された情報を時系列に保存し，データベース内 のある情報と紐付けするためである．データベースには，実際の画像ファイルを保存せず， ファイル名のみをテキスト情報として保存する．実際の画像ファイルはサーバコンピュータ 図 4.2 提案システム：地図とマーカーの表示 – 17 – 4.2 他サービスへのデータ提供 に保存する．これは，保存されたユーザデータをプロファイルし，他サービスへの提供を考 えた際，保存された画像ファイル自体は必要としないためである．情報表示フェーズより呼 び出す際は，ファイル名とサーバの URL を用いて，画像を直接サーバコンピュータから呼 び出す． 4.2 他サービスへのデータ提供 提案システムをユーザが利用することによって，サーバに情報の蓄積が行われる．蓄積さ れる情報は，ユーザ毎に投稿地点である GPS 情報，投稿が行われた日時，本文中に記載さ れたメモ，添付された画像ファイルである．この中でも特に，投稿地点と投稿時間に注目す る．この 2 つを蓄積し，分析することで，ユーザが日常的に活動する地域やその範囲，また は，図 4.5 のように，週毎に現れる規則的な行動特性などをプロファイルすることが可能に なる． このプロファイルを提供することで，ユーザを限定した広告配信などのサービスを行う際 に，利活用ができる． 図 4.3 提案システム：投稿情報の表示 – 18 – 4.2 他サービスへのデータ提供 図 4.4 図 4.5 提案システム：メーラ起動リンク ある地点におけるユーザの行動特性例 – 19 – 第5章 評価 第 4 章では今回提案するシステムの概要と処理の流れについて述べた．本章では提案する システムの評価について，評価を行った実験環境と評価手法，その手法により得られた結果 を述べる．評価は，提案システムの処理時間の計測，及び elemap blog と記事を投稿するま でのステップ数を比較する． 5.1 実験環境 本研究の開発及び設計は，表 5.1 のような環境で行った．また，携帯電話シミュレータを 用いて，提案システムの評価を行った．シミュレータを用いることで，開発を行えるだけで なく，ネットワークの回線速度を調整し，回線が不調な場合を想定してテストを行うことが 可能であった． 表 5.1 提案システムの実験環境と開発言語 項目 内容 Web サーバ Apache2.2 OS linux server sentOS 5.4 DB MySQL 携帯電話シミュレータ i モード HTML シミュレータ II version8.3 開発言語 Ruby,PHP – 20 – 5.2 処理時間の計測 処理時間の計測に用いた PC の性能を表 5.2 で示す． 表 5.2 5.2 使用 PC の性能 項目 内容 OS Microsoft Windows XP Professional Version 2002 Service Pack 2 CPU Intel(R) Core(TM)2 Duo CPU T7700 2.40GHz メモリ 2.00GB 処理時間の計測 提案するシステムでは，GPS を提供し，携帯電話への画像表示処理が行われる．画像は 地図のみでなく，既に投稿された情報も表示される．そのため，これらの処理にかかる時間 を計測し，得られる結果からユーザビリティの評価を行った．評価する処理時間はユーザが GPS 情報の提供を許可し，画像が表示されるまでの時間を計測することとする．ユーザが 表示されたと感じる時間を計測するため，画面遷移を目視し，プログラム処理ではなく手作 業による計測を行った．この計測方法を 100 回繰り返し，計測された時間の平均を計測結果 とした． 提案システムの利用対象とした第 3 世代携帯電話の最大受信速度が 364kbps であること から，364kbps，128kbps，64kbps の 3 段階で評価した．結果，表 5.3 のようになった． 表 5.3 データ表示時間 回線速度 (kbps) 364 128 64 計測時間 (s) 1.81 3.18 5.04 ユーザが携帯電話を用いた Web ブラウジングの自発的な中断時間は平均 6.93 秒 [8] とい うリサーチ結果があることから，ユーザビリティの面からは使用に耐えるということが分 – 21 – 5.3 機能比較 かった． 5.3 機能比較 提案システムの機能を評価する上で，特徴である GPS 情報を利用した情報投稿フェー ズを PC 操作における elemap blog との情報投稿の際の操作ステップ数を比較して，評価 する． 記事を記述する場合において，elemap blog，提案システムの両システムとも，TOP ペー ジへアクセスし，次に記事へ付与する地域・地点の位置情報を定める．このとき，elemap blog では，図 5.1 のように，住所検索を行い，推定の場所へ移動し，その後，付与する地 域・地点までマウス操作を行って画面上の移動操作を行い，投稿情報に付与する地点情報を 確定する操作が行われる． 一方，提案システムでは，図 5.2 のように，メインページにアクセスした後，ユーザが GPS 情報の提供に承諾すれば，投稿する地点を表示することができる．ただし，即時的な 情報を行いたいときに有効であり，投稿を行いたい場所を離れアクセスした場合，携帯電話 上でも同様に画面上の移動操作を行う必要があり，PC 上での操作以上にユーザに対してス トレスとなることが予見される． 以上のことから，提案システムは，即時的な情報投稿は可能であるが，情報投稿自体を既 存の elemap blog と入れ替わって行い得るものではなく，elemap blog の投稿を補佐し，併 図 5.1 elemap blog 上での投稿場所決定手順 – 22 – 5.3 機能比較 用することで elemap blog 全体のユーザビリティを向上させるものである． 図 5.2 提案システム上での投稿場所決定手順 – 23 – 第6章 結論 本研究では，GPS 機能を用いて，即時性のある情報を投稿できるプラットフォームの開 発を行った．従来の投稿方法である elemap blog からの情報投稿に加え，携帯電話からの 情報投稿が可能になったことで，ユーザの即時的な情報を収集・蓄積し，分析することが可 能になった．本章では，今後の展望を述べる．蓄積された情報を分析することで，ユーザの 行動範囲や規則性といった行動特性をユーザのプロファイルとして整理できる．ユーザのプ ロファイルを利用することで，提案システムと elemap blog を活用した様々なサービス展 開が考えられ，今後はそうしたサービスの開発を行っていく． 以下で一部ではあるが，サービス例を示す． 6.1 災害時被災者間情報共有サービス 我が国は温暖湿潤な気候と複雑な地質構造が持つため，世界でも有数の災害大国である． 毎年のように台風などの大型低気圧が通り，火山が全国各地に点在し，地震発生も非常に多 く，各地で地域に合わせた防災がなされてきた．しかし，近年，2004 年 7 月の新潟・福島 豪雨などのゲリラ豪雨や未発見の断層による直下型地震など，予期していない地域に対する 大規模な災害が発生している．このため，防災に対する意識が高まってきており，新しい防 災の形が求められている．そこで，提案システムや elemap blog などから位置情報を持っ た画像や情報を投稿することで生成されるユーザプロファイルに着目する．このユーザプロ ファイルには，ユーザの行動範囲がプロファイルされている．同じ行動範囲を持つユーザ同 士を結び付けることによって，自宅周辺や普段使用している道路などの状況や，避難所まで – 24 – 6.1 災害時被災者間情報共有サービス の経路などを携帯電話などを用いることで即時的に共有することができる．携帯電話は被災 時に音声通信，パケット通信の独立したコントロールが可能で，パケット通信においては被 災直後でも使用することができる [9]. 被災者同士が動的に結びつき，被災地の写真などを位 置情報を含めて投稿し，それらの情報を共有することで，図 6.1 のように，行政や支援機関 に情報を提供するだけでなく，被災者間で 2 次災害のリスクを軽減することができる． 図 6.1 災害時情報共有サービス概要 – 25 – 6.2 地域広告配信サービス 6.2 地域広告配信サービス 近年，SNS や Wiki などのコミュニティサイトが Web 上に登場している．コミュニティ サイトにおいて，その収益の多くは企業による広告費である．その内訳は，全国展開してい る企業が多く，地方の中小企業の出資は限られている [10]．これは，他地域からの来客を強 く望めない地方企業のニーズと，全国を対象としたコミュニティサイトの広告配信手法がか み合っていないためである．しかし，コミュニティサイトに登録された情報を活用すること で，地域やユーザをより限定した広告配信も可能である．ユーザが提案システムや elemap blog を利用し情報投稿を行った結果，蓄積されたユーザの位置情報を分析することで，ユー ザの行動範囲を推測し，プロファイルすることができる．また，投稿された日時なども同時 にプロファイルしておくことで，ユーザの行動規則性を推測することもできる．こうして， 生成されたユーザプロファイルを用いて，図 6.2 のように，広告を配信する地域をユーザ毎 に定め，効果的なユーザターゲティング広告を行うことが可能である． 図 6.2 地域広告配信サービス概要 – 26 – 謝辞 高知工科大学 フロンティア工学コース 清水明宏教授には，卒業研究を含め，多岐にわた り言葉では言い表せないほどの御指導，御助言を賜った．ここに心より感謝申し上げる．本 研究の副査を担当して頂いた高知工科大学 情報システム工学科 篠森敬三教授に深く感謝申 し上げる．また同じく本研究の副査を担当して頂いた高知工科大学 フロンティア工学コー ス 村上雅博教授に深く感謝申し上げる．さらに，有益な議論を交わしていただいた高知工 科大学 清水研究室の関係者各位に感謝申し上げる． – 27 – 参考文献 [1] 総 務 省,“ ブ ロ グ SNS の 経 済 効 果 に 関 す る 調 査 研 究” ， www.soumu.go.jp/menu_news/s-news/16209.html，2008，(accessed 2010.2.10). [2] 梅山直樹, 清水明宏“相互交流型電子地図システム , ELEMAP の開発”,IEICE Technical Report,IE2005-27(2005-09). [3] Akshay Java,Xiaodan Song,Tim Finin,Belle Tseng,“Why we twitter: understanding microblogging usage and communities ”,International Conference on Knowledge Discovery and Data Mining, 2007. [4] 国土地理院， “ 電子国土ポータル ”，http://cyberjapan.jp，(accessed 2010.2.10). [5] 高橋登史朗,“ 入門 Ajax ”，ソフトバンククリエイティブ，2005． [6] 総務省“通信利用動向調査” , ，www.soumu.go.jp/johotsusintokei/statistics/data/090407_1.pdf， 2009，(accessed 2010.2.11). [7] 株式会社 ROA Group,“ 携帯ライフログ・ビジネスの展望と課題 ∼キャリアの囲い込 み策となるか∼ ”，株式会社 ROA Group，2009. [8] 新井田統, 上村郷志, 中村元， “ 携帯電話からの WEB アクセス行動：ユーザによるアク セス中断はいつ生じるか ”,www.jcss.gr.jp/meetings/JCSS2009/pdf/JCSS2009_P2- 22.pdf，(accessed 2010.2.10). [9] 株 式 会 社 エ ヌ・ティ・ティ・ド コ モ, “ FOMA(R) に お け る「 音 声 通 話 と パ ケット 通 信 を 分 離 し た ネット ワ ー ク コ ン ト ロ ー ル 」の 運 用 を 開 始 ”,(www.nttdocomo.co.jp/info/news_release/page/20060821.html),(accessed 2010.2.11). [10] 小谷翔一, 清水明宏,“ 位置情報を用いた生活圏定義型広告配信方式の提案 ”, 高知工科 大学大学院フロンティア工学コース, 2007. – 28 –