現在のグーグルマップモバイルのようなモバイルのアプリケーションは単にデスクトップアプリケーションの縮小版であり、モバイルという特性が十分に生かされていない。モバイルの地図アプリケーションにおいてはGPS情報や向きの情報を利用でき、また表示できる情報量が少ないなどの特性がある。この研究ではモバイルに適した地図アプリケーションについての関連研究をまとめ、そのようなアプリケーションを我々が簡単に開発できるようなフレームワークについて提案している。近い将来この論文で述べられているような地図アプリケーションが必ず登場してくるであろう。本論文はこちら→http://www2007.org/papers/paper287.pdf
A Mobile Application Framework for the Geospatial Web
地理情報を用いたWeb上のアプリケーションが急速に発展してきている。Google MapsやYahoo MapsのようなWeb ベースで地図に情報をマッピングするアプリケーションがGoogle EarthやNASA WORLD WINDのような3Dの地理情報閲覧アプリケーションと同様に多くのWebユーザと開発者を魅了した。モバイルの分野でもGPSやデジタルコンパスと連動した地図のナビゲーションシステムが登場してきている。
この論文ではモバイルにおける地理空間アプリケーションの発展について最近の流行を考慮して議論する。そして我々は新たなナビゲーションの特性(GPSや傾きセンサ)を持ったデバイス上で開発者が革新的な地理ユーザインタフェースを作れる事を可能にし、なおかつ従来のデバイスの操作性を失わないようなフレームワークを提案する。
論文の章立ては以下のようになる
Section2:関連研究
Section3:最新のツールや技術を用いたモバイルWebアプリケーションの発展について議論する。我々はモバイルの位置に基づいたインタラクションの３つの基本的なステップを定義し、それを例によって説明する。またこの例により一般的なモバイルWebアプリケーションのフレームワークが必要であるということを述べていく。
Section4:我々のアプリケーションフレームワークを紹介し、それはセクション３で述べた必要性を満たすものである。
Section5:地理データを表現するのに、デバイスに依存しないXMLフォーマットを用いたLocal Visibility Modelについて述べる。これが我々のフレームワークの主な革新点である。
Section 6:我々のフレームワークをセクション３での例に適用する。Local Visibility Modelのおかげで例のアプリケーションは、従来の操作性を失わず、さらにデジタルコンパスと傾きセンサなどを用いる事でよりユーザ体験を向上させる事ができるのである。
Section7:まとめと今後の展望
２．RELATED WORK
位置情報を知らせるインタラクションの研究は何年間も積極的に行われてきている。
仮想のポストイットメモやデジタルな落書きなどのように実世界にデジタル情報を付けるというような研究([4],[7],[18])が数多く行われている。（ただ単にデジタル地図に情報を書き込んでいく感じでそれほど新しいとも思えない。大量のデジタルポストイットから重要な情報のみをフィルタリングするというような事をやっていた）
位置を知らせてくれるデバイスを使ってユーザはその位置に着いての情報にアクセスし、協調マッピング作業や位置に基づいた社会的交流に従事する([19],[26])
他の研究はモバイルの地理的交流の分野のなかで特定のサブドメインに焦点を当てている：例えばユーザの位置データを蓄積することに関するプライバシーの問題にずっと取り組んでいる([3],[5],[31])
また都会でのGPSの信頼性や精度についてずっと調べられてきている。代替の位置計測方法（無線LANやGSMの基地局からの情報）が都会や室内環境でより適していると言うことが述べられてきた。([16],[17])
またGPSの誤差の程度についてユーザに隠さず知らせることでユーザの不安を和らげる研究[37]やGPSの誤差による矛盾を防ぐために、誤差をロケーション・ベース・ゲームの建物の配置を決定するのに用いるなどしている[2]
我々はこれらの研究活動が我々の研究の事前条件として重要であると考えている。しかし我々の論文での主要なトピックはユーザと地理情報のインタラクションである。ほとんどのモバイルの地図アプリケーションがただ単にデスクトップの縮小版に過ぎない。しかしデスクトップのインタフェースをそのままモバイルに適用するのには無理がある[15],
モバイルユーザはデスクトップユーザより迅速な応答を地図アプリケーションに求め、さらにより目的志向である[35]。それゆえあまりに情報が多い地図は寧ろ弊害となることがある[37]
結果としてモバイル専用のインタフェースを作ろうとかなりの努力が行われている。Egenhofer[6]はSmart Compass,Smart Horizon,GeoWandという３つのインタフェースを考案している。Smart Compassは常に行きたい目的地の方向を指し示したコンパスであり、Smart Horizonは特定の方向を指し示す事で、その方向の目に見えない部分をディスプレイに映し出すことができるものである。GeoWandはユーザが棒で物体を指し示す事でその物体の情報を入手する事ができるものである。そしてそのような特性を備えた製品が表れつつある。
３．DEVELOPING MOBILE GEOSPATIAL WEB APPLICATION
我々は次のモバイル地理アプリケーションのステップとして、開発者が携帯電話によって提供される革新的な性質（GPSやジャイロセンサの事だと思う）を用いて手軽に開発が行えるような、標準化されたオープンなフレームワークが必要なのではないかと考える。
デスクトップ上でオープンWebAPIが熱烈な開発者のコミュニティーを育てたのと同様に、モバイルにおいてもそのような開発者に適したフレームワークを作ってやる事で革新的な地図アプリケーションができるのではないかと思われる。
このセクションでは、我々はそのようなフレームワークに必要となる要素を導き出す。開発者が既存のツールとAPIを用いてモバイル地理アプリケーションを構築する時に取り組まなくてはならない問題について簡単な例を挙げて議論する。
図１は例として用いるアプリケーションの概略である。アプリにはGPS、ブラウザ、地理コードが埋め込まれたウィキペディアの記事が備わっている。
我々はわかりやすくするため、インタラクションの流れを端末の位置を知るPositioning、端末の位置に基づいた内容をAPIやその他のメカニズムを用いて取り出すSpatial selection、取り出した内容を端末のディスプレイに表示するPresentationの三つにわける。そしてそれぞれについて説明していく。
3.1 Positioning
デバイスごとにGPSデータの取り出し方は様々であるため、どのデバイスであってもGPSデータを同じプログラムで取り出せるように標準化していく必要がある。そこでブラウザからJavaScriptでGPSに直接アクセスして座標を取ってこれるようにActiveX controlでデバイスの違いを吸収する。
3.2 Spatial Selection
通常のデスクトップアプリケーションの場合、地図情報を取得するとき、地図の中心から半径○○メートル以内、あるいは現在表示されている地図の範囲内といった検索要求をして、その範囲内の
データを取得するが、モバイルアプリケーションの場合より重要となるのは建物が視界、目に見えるかどうかである(field of view and visibility)。目に見えている部分と判断するには３次元のマップデータが必要となる。これについては４章で詳しく説明する。
3.3 Presentation
空間の選択プロセスの次に、選択された結果はモバイルデバイスでの表示のためにフォーマットされる。我々の例では、フォーマットはサーバで、地理情報が入ったデータベースから取り出した検索結果とともに一般的なXHTMLテンプレートを投入することによって行われる。
考えるべきところは、デバイスの画面サイズ、サポートされている言語、含まれるセンサなどにより開発プロセスが複雑になっており、個々のデバイスに様々な対応をしなければならない点である。表示形式だけではなく、インタラクションのあり方まで入り込んで考える必要がある。このことを考慮したうえで我々が考えるフレームワークは次の２つのことを考慮する必要がある
・フレームワークは、すべてのモバイルデバイスに適合するような統合されたデータ出力フォーマットを提供することにより、主題の一貫性(thematic consistency)を施行しなければならない。
・フレームワークはデバイスの能力を最大限に引き出すように開発者に薦めなければならない。（例えばスペックの低いデバイスでも出力フォーマットを意味のあるテキストに変えられる、あらゆる機能を備えたデバイスであればより複雑なリアルタイムユーザインタフェースを実現できるようにすべきである）
4. A FRAMEWORK FOR MOBILE GEOSPATIAL APPLICATIONS
このセクションでは我々のフレームワークの実装について説明する。このフレームワークではユーザの位置から見える建物かどうかに基づいて内容を選択する空間クエリエンジンを特色とする。またクエリの結果はデバイスや結果の表示方法にとらわれないXMLデータ交換フォーマットで返されることとする。これにより主題の一貫性(thematic consistency)とデバイスの能力(capabilities)を最大限に生かすように開発者を促す仕組みが施行される。
4.1 2.5D Environment Model
ユーザの視界に入るかどうかを検証するためには、経度、緯度、高度を持った３次元環境モデルが必要となる。３次元モデルを実現することは最新の技術により容易になってきている。
実装において２つのデータセットが用いられた。１つ目はテスト用として手動で集めたデータセットであり、図４左に当たる。２つ目はかなり正確に作りこまれたデータセットであるであり図４の右に当たる。それぞれの建物は一つの２次元ポリゴンで表されており高さの値を持っている。
(何を持って２．５次元と言っているのかは不明だがおそらく２次元マップであるが高さの情報を持っているというところが２．５次元なのであろう。）
4.2 Query Engine
我々のフレームワークにおいてクエリエンジンの空間選択プロセスは２つのステップからなる。最初のステップは現在位置を考慮して２．５次元環境モデルをデータベースから取り出すことである。同時にその地域におけるコンテンツ情報も取得する。２つ目のステップとして、クエリエンジンは実際にユーザから見えているポイントを発見する。具体的には図５のようになる。QUERY LOCATIONが現在位置であり、あらかじめ設けておいたデータポイントが見えるかどうかを判断して見えるポイントと見えないポイントの２つに分けている。
4.3 XML Query Result
地図の多様な表現方法やインタラクション方法に対応するために、我々は新しいXMLデータ交換フォーマットを開発し、我々のクエリエンジンによって返される結果をXMLデータに変換しブラウザに渡してやることにした。
次のセクションでは我々は表現方法に依存しないＸＭＬのクエリ結果フォーマットであるthe Local Visibility Model (LVis)について詳細を説明する。
5. THE LOCAL VISIBILITY MODEL
Local Visibility Modelは検索結果空間の単純化された自己中心の概念である。LVisは３次元の情報を持っている。また標準的な単位を使用しており、例えばXSLTを使う事で簡単に意味のあるテキスト出力が行える。またLVisは極座標表記を採用しておりSmart CompassやGeoWandといった本来ならばデカルト座標（直交座標）から極座標への変換が必要なインタフェースを簡単に実現できる。開発が容易となるよう、LVisは単純な空間モデリングメタファであるPoints of Interest(POI)とビルボードを使用する。
5.1 Points of Interest
伝統的な地理検索クエリはジオコードが付随した内容への照会であった。照会結果のデータは一つの点座標で表される。このようなポイント型のジオコードで座標が示される内容はLVis中ではPoint of Interest(POI)で表現される。
LVisは極座標を用いるのでそれぞれのPOIはユーザからの距離、方向(heading)、高位によって定義される。このようにPOIのテキストの記述は複雑な計算なしに生成されるのである。図６はPOIの要素のためのXMLのサンプルコードを示している。またユーザの視界には入らないポイントを含めて表示する場合はhpoi(hidden-poi)としてpoiとは異なったXMLが生成される
5.2 Billboards
LVisでは通常のPOIだけでなく、実際の環境構造（３Ｄの構造）も表現する。このアプローチ（３次元データを取ってきて表現に生かす）のためのモチベーションは次の二つである
・一つ目として我々はモバイルデバイスの環境の形状のローカルな知識が幾つかの先進的なセンサを用いるインタフェースのためにおもしろいデザインの特徴であると言うことを主張する。（意味不明→おそらく先進的なセンサを用いた場合では、点で建物を表現するだけではセンサの良さが十分に活かしきれないのでビルボードという表現方法が必要となるってことを言っている）
・２つ目として我々は、我々の周囲に蓄えられた環境構造がリアルタイムユーザインタフェースのために必要な事前条件であるという事を主張する。もしクライアントが周囲の３次元構造についての情報を持っているならば、地図情報はもう一度クエリをサーバに送ると必要なしで統合されたセンサーから反応して変化することができる。（ユーザが動いてもすぐさま最新の状況に対応できる、ちょうどグーグルマップで地図を移動した時に周囲の地図については既にブラウザに読み込まれていて新たにサーバから地図データを取ってくる必要がないって事に似ている？）
GMLのような従来のベクター構造で２Ｄ、３Ｄを表現している場合、人間が読む事ができず画像の出力には複雑な計算を伴う。これは我々の、環境構造を簡単にテキストで表現するという目的に反するために、より簡潔な構造の表現方法が必要であると考えた。そこでLVisではビルボードメタファを用いて環境構造を表現する。ビルボードは建物の特徴をユーザと直接面する四角形の壁で近似するものである。このビルボードはPOIと同様極座標で表せ、近くの建物をテキスト記述で表せ、計算なしに直接ＸＭＬからビルボードを構築する事ができる。XMLでの記述方法はＰＯＩでの記述にビルボードの横幅の角度を表すhwidthと縦幅の角度を表すvwidthが加わったのみである。
5.3 Occlusion Detection
クエリエンジンは基本的な線をスキャンするアルゴリズムを個々のビルボードの間でオクルージョンを決定するために使われる。ビルボードのオクルージョンの発見をスピードアップさせるために、アルゴリズムは実際の建物の中でオクルージョンを計算しない。その代わり、アルゴリズムはそれぞれの建物を最初のステップとしてvisible cross sectionによって置き換える。それぞれのcross sectionはそれからチェックされる。LVisの計算が我々のクエリエンジンにより完全に行われた結果は図１０のようになる。図１０の上の部分は上から下を見下ろした図であり、下の部分は３６０度のパノラマの図である。ビルボードを確認しやすくするため「viewing beam」というものをもうけており、（角度的に）高いビルボードほど明るい色になっている。パノラマの図では明るい色ほど遠くにあることを示している。
5.4 Limitations
LVisモデルでうまく行かない場合として次の２つがある
１．図１１のようなアーチを描いた建物の場合は、建物の先が見えるに
もかかわらず見えないものと勘違いしてしまう。
2. 図１２のような、一つの建物が視界の１８０度以上を占めるとき、一つのビルボードでは表現しきれないため図１２のように３つのビルボードを使って表現する。
6.GEOSPATIAL USER INTERFACES
アプリケーションフレームワークに基づいて、我々はWikipedia Finderを実装した。このセクションでは我々のフレームワークとLVisで、異なったセンサーを持ったデバイスを用いて、いくつか可能なユーザインタフェースを実演してみる。
6.1 GPS-Enabled PDA
新しいスクリプトが一定期間おきに新しいLVisをサーバからXMLHttpRequestを用いて取り出されそれに応じてユーザインタフェース（表示画面）を更新する
図１３のように現在見えている部分のwikipediaのきじが見えていない部分の記事とは分離されており、この部分が図１とは異なっている。
6.2 Sensor-Equipped Mobile Phone
商用のデバイスでGPSとコンパスを備えているものがなかったため図１４のものを自作した。そして２章で説明したSmart Compass,Geo-WandとPanorama GUIというものを実装した。Smart Compassは図１５の左図のようになり、円の中心にユーザがいて、建物の方向が示されている。この矢印はユーザがどこを向いているかによって動的に変化する。Geo-Wandはスキャニングデバイスのように使われる、しかしいまいちどうするのかよくわからない。（ユーザがゆっくりと環境に沿ってデバイスをパンしている間、ユーザインタフェースは見えているWikipediaの記事の位置を指し示すと書いてある）、最後にPanorama GUIは３６０度全体を図１５の右のようにパノラマＧＵＩで表しており、近くの建物の情報を見る事ができる。
7.SUMMARY AND FUTURE WORK
この論文で、我々は将来携帯電話に取り付けられるであろうセンサによりどのような革新的な地理アプリケーションやユーザインタフェースが可能になるのかについて議論した。
また我々はWeb上で地理データを取り出す新しいAPIが必要である事を発見し、局所的な地理情報のXMLデータ交換フォーマットの候補としてLocal Visibility Model(LVis)を提案した。
そしてLVisがいかに多様なインタラクションのスタイルに対応できるかということを示した。
今後はビルボードによる表示が簡単すぎるので、簡潔さを失わない程度で３Ｄ化する、都会だけではなく田舎においてもビルボードは適用可能かどうかを調べる。ナビゲーションの機能を充実させるといった事を考えていきたいと思う。
