「マルチメディア，分散，協調とモバイル(DICOMO2010)シンポジウム」 平成22年7月

are displayed. The user’s recognizing the position where contents are correct inthree dimension space has a diﬃcult problem only by the size of icons which acorrect real spatial representation doesn’t consist. In this thesis, it veriﬁed itfrom both sides of the method of selecting contents and the method of drawing
contents icons that displayed to the contents drawing on the panorama viewer.
Moreover, it was possible to draw to contents icons in the foot to understandcontents more intuitively, to look down in the down shot, and to have proposeda new interface by this thesis. As a result, the contents display performance on
the panorama viewer can be said the improvement.

パノラマビューアにおける大量コンテンツの効果的な表示方法の提案
中島弘貴†1新井イスマイル†2安部陽平†1
西尾信彦†1

実世界上の物や場所に関するコンテンツを管理するシステムとして，実世界指向
CMS と呼ばれるシステムがある．その中の一つである Gooraﬃti は，3 次元空間の球面上にパノラマ写真を展開したパノラマビューアに，コンテンツのリンクをマッシュアップしたものをクライアントとし，周辺に存在する物や場所に関するコンテンツへリンクさせるアイコンを，パノラマ写真上に重畳表示している．しかし，建物に隠れて本来見えないはずのコンテンツも表示されており，正しい実空間表現ができていない問題や，アイコンの大きさだけでは 3 次元空間におけるコンテンツの正しい位置をユーザが認識することは難しいといった問題が存在する．本論文ではパノラマビューア上におけるコンテンツ描画に対し，表示するコンテンツの選定方法とコンテンツアイコンの描画方法の両面から検証し，より直感的にコンテンツを理解できるようにコンテンツアイコンに足を描画したり俯瞰的に見下ろしたりすることが可能である新しいインタフェースを提案した．これにより，パノラマビューア上のコンテンツ表示性能は向上したことが分かった．

1. は じ め に
近年，Google Street View1) のような，パノラマビューアを用いた実世界指向のサービス・研究が注目されてきている2)3) ．パノラマビューアは全方位カメラによって撮影されたパノラマ写真を，3 次元空間に形成された球の内面に貼り付けることで実現されており，球の中心からそのパノラマ写真を見ることで実際にその場所にいるかのようなビューを提供できる．これにより，今までに多く見受けられた地図や俯瞰図を用いた 2 次元的な実世界指向サービスとは異なる，より実世界に近い形の 3 次元的なビューアを提供可能となった．
さらに，このような 3 次元的な実世界指向サービス上に，店舗に関する情報を表示したり場所と関連する他のウェブサービスへのリンクを表示したりして，その利便性を高めた実世界指向 CMS(Contents Management System）が普及してきている．例えば，セカイカメ

Proposal of Eﬀective Display Methodof a Large Amount of Contents in Panorama Viewer
Hiroki Nakajima,†1 Yohei Abe,†1 Ismail Arai†2and Nobuhiko Nishio †1
There are systems that is called real world oriented CMS(Contents Management System) as a system that manages contents which mean the real world
and contents concerning real world. Gooraﬃti that is one in the system assumes
the panorama viewer that develops the panorama picture on the sphere of three
dimension space to be a client, and has improved the link of contents in mash.
The icon to link with contents that relate to things and places that exists in thesurrounding is displayed on the panorama photograph in the overlay. However,contents that are hidden oneself in the building and not to be seen in reality

ラ4) やレイヤー5) ，実空間透視ケータイ6) などがある．我々も Google Street View 上にコンテンツのリンクをマッシュアップした実世界指向 CMS として Gooraﬃti7) を提案している．Gooraﬃti の外観を図 1 に示す． しかし，実世界指向 CMS には表示されるコンテンツが大量になると，3D 空間にアイコン画像を浮かべているためにコンテンツ同士の位置関係の把握が困難であるという問題や，アイコンの重なり合い等によりユーザにとって視認性が悪化するという問題がある．大量のコンテンツアイコンが描画された状況を図 2 に示す．
こうした実世界指向 CMS の 3D 空間における奥行きを認知し難い問題を解決するために，横矢らは照明条件と奥行きを推定することにより，3D 空間上に設置する仮想物体に影をつ†1 立命館大学情報理工学部
Department of Computer Science and Engineering，Ritsumeikan University†2 立命館大学総合理工学部研究機構
The Research Organization of Science and Engineering，Ritsumeikan University― 783 ―

けるという手法をとっている8) ．この影の描画により，現実に存在する他の物体との位置関係把握を直感的に行うことができる．しかしながら，大量のコンテンツを扱う実世界指向

CMS において，全てのコンテンツアイコンに対して影を計算して付加するという処理は，実用的な時間内に描画を終えることが難しい．また，アイコンの重なりを解決するために，渡辺らは各アイコンをグループ化して同じグループのアイコンを近くに集めるという手法をとっている9) ．しかしながら，実世界指向 CMS において登録されるコンテンツは多種多様であり，グループ化が容易にできるとは考えにくい．また，コンテンツのアイコンが本来の場所から移動してしまうことによって，実世界指向 CMS の価値を下げてしまうと考えられる．そこで本研究では，実世界指向 CMS における視認性確保のための妥当なフィルタリング手法として道路情報を用いる手法を検討した．さらに，奥行きに対する視認性確保の計算量が少ない手法としてコンテンツアイコンの地表への垂線を表示する手法と俯瞰ビューを提供する手法についても検討した．検討では，ぞれぞれの手法について 8〜12 名の被験者に妥当性と視認性に回答してもらい，その結果を考察している．以降，2 章では本研究で検図 1 Gooraﬃti の外観Fig. 1 Gooraﬃti’s appearance

討した 3 つの手法について詳しく述べる．3 章では検討で用いたシステムの設計と実装について述べ，4 章では検討の結果と考察について述べる．最後に，5 章で本論文のまとめを行うとともに，今後の課題について述べる．

2. 検討手法の概要
本研究では，実世界指向 CMS 上に大量のコンテンツを描画した場合の煩雑さを解消する手法として，実世界においてパノラマビューアの視点から実際に見ることができるコンテンツと，見えないコンテンツを分類するフィルタリングを行った．このフィルタリングは道路情報を利用することによって実現した．また，奥行きに対する視認性確保の手法として，コンテンツアイコンの地表面への垂線を表示する手法と俯瞰ビューアを提供する手法についても検討した．以降，それぞれについて詳しく述べる．

2.1 道路情報を用いたコンテンツフィルタリング手法
パノラマビューアでコンテンツを表示する場合，実世界における実際の視界を考慮した表示コンテンツのフィルタリングを行うのが妥当である．本研究で表示するコンテンツはあらかじめ 2 次元マップ上で登録されたコンテンツであるため，3 次元空間でどのように「実図 2 大量のコンテンツアイコンが描画された状況Fig. 2 Situation in which it is drawn to a large amount of contents icon

際には見えない」コンテンツを判断するか考慮する必要がある．本研究では全てのパノラ
マ写真は道路上で撮影されていることを利用し，障害物によって遮られることのない道路沿いの情報を「実際に見える」コンテンツと判断し，それ以外を「実際には見えないが付近― 784 ―図 3 道路オブジェクトとコンテンツ表示範囲
Fig. 3 The road object and range of contents displayには存在する」コンテンツと定義した．概要を図 3 に示す．道路情報には，各パノラマ写真の撮影地点間における地理的な隣接関係を利用した道路オブジェクトを生成し利用した．

図 4 システム全体図
Fig. 4 The all system outline

生成した道路オブジェクトはデータ構造的に幅を持たない直線となるため，道路沿いのコンテンツを道路に関連付けるために幅を与え，道路の範囲を定義した．

2.2 奥行きに対する視認性確保のためのコンテンツアイコン足の描画能性がある．本研究では，周辺地形とそれぞれのコンテンツの位置関係を可視化するため，表示させるコンテンツアイコンを制限するだけでは，ユーザが本当に得たい情報が省かれ俯瞰ビューアを実装し，これを解決する．本研究におけるコンテンツアイコンの足とはこのてしまう可能性がある．そのため，周囲のコンテンツアイコン全てを表示する機能も必要

垂線のことを指し，足を描画することで 3 次元空間上において幅と奥行きについての位置である．しかし，1 章で述べたようにこれでは表示するコンテンツが多くなり過ぎて問題に関係把握を容易とする．

なってしまうため，よりユーザにとって理解し易い見せ方が必要である．3D 空間を考慮し3. 設計と実装たビューアにおける視認性の問題は，表示はあくまで平面であるモニター上で行われるた

3.1 システム設計

め，奥行きの認識が難しいことに起因する．本研究では，それぞれのコンテンツアイコンから地表面に対する垂線 (以降この垂線のことを足と称する) と周辺地形を可視化することで本システムの概要を図 4 に示す．コンテンツに関する情報を持つデータベース (以降ここれを解決する．ここでいう周辺地形とは 2.1 節で挙げた道路オブジェクトのことであり，のデータベースをコンテンツ DB と称する)，パノラマデータ持つデータベース (以降このコンテンツとの位置関係を視覚化するために，コンテンツアイコンから道路オブジェクトをデータベースをパノラマデータ DB と称する) とし，コンテンツ DB はあらかじめコンテ描画する地表面に足を描画する．

ンツに関する情報を保持しているとする．また，コンテンツを描画するパノラマビューアは2.3 奥行きに対する視認性確保のための俯瞰視点の利用

Gooraﬃti を使用する．本システムはウェブアプリケーションとして動作し，大きく２つのコンテンツアイコン同士が地表面から高く離れた位置に描画されている場合や互いが離部分に分けることができる．一つはパノラマビューアやコンテンツアイコンを描画するレれた場所に存在する場合，コンテンツの位置関係を足の描画だけではユーザが理解し難い可ンダリング部であり，もう一つはレンダリング部で表示するためのコンテンツや道路の情報― 785 ―

表 1 各コンテンツが共通して持つ情報の詳細
Table 1 Detailed information on all contents
名称

詳細

panoIdコンテンツタイプ
位置情報
高さ

パノラマ写真の紐付く各地点に割り振られた固有 Id
コンテンツの種類
コンテンツが持つ緯度・経度
コンテンツが持つ地面からの高さ

名称

表 2 パノラマデータ
Table 2 Panorama datadepth
footﬁlter
arearoadwidth

名称

panoId
位置情報
道路 Id
道路番号

表 3 ユーザが値を指定可能なパラメータ
Table 3 Parameters for which user can specify value
詳細

初期値

道路およびコンテンツアイコンの足の下端が描画される平面の位置
アイコンに足をつけるかどうかの値 (0 or 1)
コンテンツ取得方法の指定値 (0〜3)
コンテンツを取得してくる範囲
コンテンツを道路に関連付ける範囲2(m)1
0100(m)25(m)詳細
パノラマ写真の紐付く各地点に割り振られた固有 Id
コンテンツが持つ緯度・経度
コンテンツが所属する道路に割り振られた固有 Id
コンテンツが所属道路の何番目の要素であるかを示すを，コンテンツ DB とパノラマデータ DB から取得してくるデータ管理部である．
コンテンツ情報
コンテンツ取得機構においてコンテンツ DB から取得され，レンダリング部へ返信される各コンテンツが共通して持つ情報の詳細は表 1 の通りである．これらの情報は，コンテンツ取得機構で生成された取得範囲のクエリにより，緯度経度をキーとして取得される．レンダリング部でのコンテンツ描画は Gooraﬃti で実装されている機能を利用した．
道路情報
データ管理部で生成されレンダリング部へ返信される道路情報とは，表 2 のようなパノラマデータの連なりであり，始点から終点までの順序が存在する．

3.2 レンダリング部
パラメータの指定
ユーザはブラウザ上から URL を用いて本システムを呼び出すことができる．また URLの後尾に表 3 のパラメータを記述することにより，各パラメータを初期値から変更できる．

foot，depth 以外のパラメータはデータ管理部へ送られ，コンテンツ情報や道路オブジェク
トを作成するためのパノラマデータを取得するために使用される．パラメータ送信後，データ管理部からコンテンツ情報と道路情報が返信されると，それらの情報を用いて Gooraﬃti上にコンテンツと道路を描画する．

― 786 ―

図 5 各パラメータの説明
Fig. 5 Explanation of each parameter図 6 本システムにおいて生成された道路
Fig. 6 The road generated in this system

図 8 コンテンツの足Fig. 8 The foot of contents

図 7 パノラマ写真が撮影された道路
Fig. 7 The road in which panorama picture wastaken a picture

報テーブルとリンク情報テーブルを表 4，表 5 に示す．まず，area の値により作成された道路の描画

コンテンツ取得範囲内にある panoId を，パノラマ情報テーブルから全て取得してリスト化

道路情報を構成するパノラマデータの緯度経度を用いて，3D 空間上の各パノラマデータする．そして，各地点においてその地点の panoId(以降リンク元と称する)，その地点と隣間に直線を引くことで道路を描画する．したがって実際に描画される道路は各パノラマデー接する地点の panoId(以降リンク先と称する) をリンク情報テーブルから取得し，各地点のタ間を結ぶ直線の集合となる．また，道路描画時は depth を参照し，このパラメータの値進行方向を一つの組 (以降リンクと称する) としてオブジェクト化する．次に，先ほど取得だけ視点位置から下方に道路平面を描画する．この値が大きくなると道路は俯瞰図のようにした範囲内全ての panoId のリストにおいて，リンク先が範囲内に存在しないリンク元を抽描画され，3D 空間において周辺地形の認識を容易にする．実際に本システムで生成された出する．ここで抽出されたリンクは，コンテンツ取得範囲の外周と交差する．よって，抽出道路とパノラマ写真が撮影された道路の形状を図 6，図 7 に示す．

されたリンク先の地点をこの範囲内における道路の始点とする．そして，始点から出発しアイコンの足の描画てリンク先が存在しなくなるまでリンク先を辿っていく．リンク先が存在しない場合，道路コンテンツ描画時には foot を参照し，1 であればアイコンの足を描画する．実際に足をの終端として一つの道路オブジェクトが完成する．一度道路オブジェクトを作成するために描画した結果を図 8 に示す．

用いたリンク元とリンク先の組み合わせは，除外することで処理が重複しないようにする．

3.3 データ管理部

また，コンテンツ取得範囲の外周と交差する形で存在するリンクがなくなった場合，リンクレンダリング部から送信されてきたパラメータに従ってコンテンツ情報と道路情報を生成

先が一つしか存在しない panoId から出発して道路オブジェクト生成を継続する．リンク先する．

が二つ以上ある panoId，すなわち交差点に来た場合，一つ前のリンクが持つ進行方向に近道路情報の生成

い進行方向を持つリンクを選択する．これらの処理を再帰的に行うことで範囲内の全ての道

パノラマデータ DB はパノラマ情報テーブルとリンク情報テーブルを持つ．パノラマ情路をオブジェクト化できる．このアルゴリズムを図で表したものを図 9 に示す．

― 787 ―

表 4 パノラマ情報の詳細
Table 4 Details of panorama information
名称

panoId
道路名
市名
位置情報
進行方向

詳細
パノラマ写真の紐付く各地点に割り振られた固有 Id
所属する道路名
所属する市名注目地点の緯度，経度
パノラマ写真撮影時の進行方向
図 10 一車線道路の場合
Fig. 10 The case of the single lane road

図 11 一車線道路の場合
Fig. 11 The case of the four lane road

表 5 リンク情報の詳細
Table 5 Details of link information
名称

コンテンツ取得

詳細panoId
隣接地点の panoId
隣接地点への方角

パノラマ写真の紐付く各地点に割り振られた固有 Id
隣接する地点の panoId
隣接地点への方向

ﬁlter の値が 0 のとき，area の値から作成されたコンテンツ取得範囲内にあるコンテンツを全て取得し，レンダリング部へ送信する．ﬁlter の値が 1 のとき，生成した道路オブジェクトを用いて，注目地点の panoId が所属する道路に関連付けられたコンテンツをレンダリング部へ送信する．道路オブジェクトは，このままではただの直線の集合であるため，コンテンツを取得する範囲を作成するためには幅を持たせる必要がある．この幅は road widthの値を参照することで得られる．道路情報を構成するパノラマデータ間を結ぶ，全ての直線に対して垂直方向両側にこの幅だけ離れた直線を引くことで取得範囲を実装した．この取得範囲をコンテンツ DB への条件クエリとすることで，道路に関連付けられたコンテンツを取得することができる．オプションとして ﬁlter の値が 2 のとき，ﬁlter の値が 1 のとき以外のコンテンツを表示する機能を実装した．また，ﬁlter の値が 3 のとき，どの道路にも関連付けられなかったコンテンツアを表示する機能を実装した．

4. 評価実験と考察
フィルタリングの評価
評価には被験者 8 人に回答してもらった．コンテンツアイコン数が多いと思われる地点をビューアで表示し，被験者がコンテンツアイコンの分布を理解し易いようアイコンを配置した 2 次元マップを用意した．単純な指定範囲検索によって取得したコンテンツのアイコンを表示し，フィルタリングを行った結果と比較して，表示されたコンテンツが妥当であると
図 9 道路オブジェクト生成アルゴリズム
Fig. 9 The algorithm that generates object of road

思うかを回答してもらった．試行を行うにあたり，道路幅は一車線の場合と四車線の場合を用意し，その試行順序は無作為に決定した． フィルタリングに対する質問において，回答の分布は図 10，図 11 に示す通りとなった．四車線道路の場合と比較して，一車線道路の― 788 ―場合の方が「妥当でない」という回答の割合が増加したことが見受けられた．これは道路オブジェクトの幅が実際の道路幅にかかわらず一定であるため，実際の道路幅が狭いほど道路幅を超えてコンテンツを取得する幅が増えることにより，「実際には見えないが付近には存在する」コンテンツを表示してしまったことが原因であると考えられる．また，逆に幅の広い道路においてコンテンツを取得する幅が狭くなり過ぎ，フィルタリングによってユーザが必要とするコンテンツまで省いてしまった可能性も考えられる．これらのことから，道路幅やコンテンツ数の差によって様々な道路幅を選択する必要があることが分かった．

4.1 足 の 評 価
評価には 12 人に回答してもらった．ある地点をビューアで表示し，その地点の中心からコンテンツアイコンに対しての距離が僅差である足の描画の無いコンテンツアイコンを 2 つ用意して番号を付け，距離が近いと思った方のコンテンツアイコンの番号を回答してもらっ図 12 足の評価実験の結果
図 13 俯瞰ビューアの評価実験の平均正答率
Fig. 12 Result of foot evaluation experiment that Fig. 13 Result of foot evaluation experiment thatuses footuses bird’s eye viewた．その後，コンテンツアイコンに足を描画して再び回答してもらった．この 2 回の回答を1 回の試行とする．試行に用いた地点は 5 地点であり，その順序は無作為に決定した．足を描画しなかった場合と描画した場合において，全被験者の平均正答率は図 12 に示す通りとなった．足を描画しなかった場合と比べて，足を描画した場合は正答率が大幅に上昇したことが見受けられた．また，足を描画した場合は全員が正解した．これにより，足はコンテンツアイコンの位置関係を把握するために有用であるといえる．

4.2 俯瞰ビューアの評価
評価には 12 人に回答してもらった．ある地点をビューアで表示し，その地点の中心からコンテンツアイコンに対しての距離が僅差である足の描画の無いコンテンツアイコンを 5 つ

表 6 単純な指定範囲検索によって取得したコンテンツの描画にかかる時間
Table 6 Time that hangs to drawing of contents obtained by simple speciﬁed range retrieval
コンテンツ取得
範囲半径 (m)

描画アイコン数(個)

サーバとの通信時間 (sec)

アイコン描画時間 (sec)

足の描画
時間 (sec)俯瞰ビューアへの切り替え時間 (sec)

50
100
150
200250
300

175
378
722
1023
1197
1332

0.049
0.06560.0839
0.108
0.117
0.118

0.946
1.22
2.283
3.216
3.758
4.247

1.543
3.396
8.238
14.32319.00622.616

1.287
2.347
3.888
6.425
8.275
10.78

用意して番号を付け，距離が近いと思った順にコンテンツアイコンの番号を回答してもらった．その後，俯瞰ビューアに切り替え再び回答してもらった．この 2 回の回答を 1 回の試
表 7 道路に関連付けられたコンテンツの描画にかかる時間
Table 7 Time that hangs to drawing of contents related to road

行とする．試行に用いた地点は 3 地点であり，その順序は無作為に決定した． 俯瞰ビューアを利用しなかった場合と利用した場合において，全被験者の平均正答率は図 13 に示す通りとなった．俯瞰ビューアを利用しなかった場合と比べて，利用した場合は正答率が大幅に上昇したことが見受けられた．これにより，俯瞰ビューアはコンテンツアイコンの位置関係を把握するために有用であるといえる．

4.3 処理時間の計測
本研究の提案するフィルタリング手法と足の描画，そして俯瞰ビューアへの切り替えにおいて，描画時間の計測も行った．ここでは，ユーザが指定可能なパラメータに関しては初期値 (depth:2，roadwidth:25，foot:0(足の描画時間計測時は 1)，ﬁlter:0(フィルタリング時は― 789 ―コンテンツ取得
範囲半径 (m)

描画アイコン数(個)

サーバとの通信時間 (sec)

アイコン描画時間 (sec)

足の描画時間 (sec)俯瞰ビューアへの切り替え時間 (sec)50100150200250300115143195224237245

0.46130.362
0.90330.22
0.33680.48461.02871.47362.654
3.177
4.74495.2262

0.777
0.991
1.468
1.82
2.025
3.21

0.882
1.385
2.099
3.018
3.818
6.085

1)，area:50(計測に応じて変更)) を利用し，コンテンツ数が非常に多いと推測される京都駅前の一地点を評価地点とした．フィルタリングを用いず単純な指定範囲検索によって取得したコンテンツの場合と，提案するフィルタリング手法を用いた場合の計測結果を図 6，図 7に示す．どちらの場合においても，描画されるコンテンツアイコンの増加に伴ってアイコンと足の描画時間，俯瞰ビューアへの切り替え時間が増加していることが伺える．しかし，コンテンツ数が大量である京都駅前において，単純な指定範囲検索によって取得したコンテ
ンツアイコンの描画はコンテンツ 1332 個に対して約 4.2 秒，道路に関連付けられたコンテ
ンツアイコンの描画は 245 個に対して約 5.2 秒となっており，十分に実利用に問題のない時間に収まっているといえる．また，足の描画時間と俯瞰ビューアへの切り替え時間においても，単純な指定範囲検索によって取得したコンテンツアイコンの描画時間はそれぞれ約22.6 秒と約 10.8 秒，道路に関連付けられたコンテンツアイコンの描画時間は約 3.2 秒と約6.1 秒と実利用に問題のない時間に収まったといえる．

5. お わ り に
本論文では，実世界指向 CMS の視認性問題の解決のために，「実際に見える」コンテンツのみを表示することで表示コンテンツ数の減少を図る機能と，コンテンツアイコンに足を描画することによる 3 次元的なビューア上で表示された情報の理解を容易にする機能，さらにコンテンツアイコンと周辺の道路を俯瞰的に見下ろしてコンテンツの位置関係を容易認識できる機能の 3 つを検討し，その機能を実装して評価を行った．評価を行った結果，実世界指向 CMS におけるユーザの視認性を確保し，コンテンツ同士の位置関係の把握を容易にしたといえる．本研究のフィルタリングにおいてフィルタリングを行う距離，すなわち道路に関連付ける幅をユーザが指定することは可能であるが，遷移する度に実際の道路幅を考慮して関連付ける距離を指定し直すのは面倒であると考えられる．しかし，現状のように初期値を与えておいて指定が無い場合はその値を適用するのでは，多様な道路幅に対応できないという問題が生じる．よって今後は，動的に道路幅を取得し，それを考慮した上でフィルタリングを行っていく必要がある．また，panoId などの各データは Google が Street View
サービスに用いているものを利用しているが，これらのデータはパノラマ写真を撮る撮影車が通った道路にしか存在しないため，道路情報が実際の道路の形状に沿っていない．よって，今後は道路情報を実際の道路の形状により近づけていくことが課題となる．その他，新たな機能を追加した場合，より高速な処理を求められる可能性がある．そのため，より高速な処理を可能にするアルゴリズムの提案も今後の課題とする．

― 790 ―

参考文献1) Google Street View.
http://www.google.co.jp/help/maps/streetview/.
2) 池田隼，難波公一郎，栗田智子，國島丈生，横田一正，”パノラマ画像を用いた仮想空間構築”，DEWS20064B-i12.
3) 興梠正克，蔵田武志，坂上勝彦，村岡洋一，”パノラマ画像群と位置合わせに用いたライブ映像上への注釈表示とその実時間システム”，情報処理学会 2009 年.
4) Sekai Camera.
http://support.sekaicamera.com/ja/service.
5) Layar.
http://layar.jp/.
6) 実空間透視ケータイ.
http://www.kddilabs.jp/press/detail 102.html.
7) 坂本憲昭，西尾信彦，新井イスマイル，”Google Street View とマッシュアップした
実世界指向 CMS”，情報処理学会 2009 年.
8) 横矢直和，神原誠之，”現実環境の照明条件と奥行きの実時間推定による仮想物体の陰影表現が可能な拡張現実感”，画像の認識・理解シンポジウム (MIRU2004)，2004 年 7月.
9) 渡辺奈夕子，五十嵐健夫，”アイコンの空間的なまとまりを利用した情報管理機構”，
WISS2005