DEIM Forum 2017 D2-1

交通機関のアクセスポイントを考慮した
Focus+Glue+Context マップシステムの実現
平児 祐樹†

山本 大介†

高橋 直久†† 名古屋工業大学大学院工学研究科情報工学専攻 〒 466–8555 愛知県名古屋市昭和区御器所町
E-mail: †hirako@moss.elcom.nitech.ac.jp, ††{yamamoto.daisuke,naohisa}@nitech.ac.jp
あらましFocus+Glue+Context マップシステム EMMA は，大縮尺の注目領域 (Focus) と小縮尺の周辺領域 (Con-text)，および，縮尺差により生じる歪みを吸収して両者を結ぶ領域 (Glue) からなる視認性と一覧性に優れた Web
マップシステムである．Web マップの使用目的の 1 つとして，遠方から交通機関を使用して目的地へ向かう時の行き方を調べることがある．その際ユーザーは，どのように交通機関を乗り継いで目的地の最寄りにあるアクセスポイン
ト (駅やバス停等) へ行くのかと，そのアクセスポイントからどのような経路を歩いて目的地に向かうのかを考える．
本稿では，このような使用状況を想定し，交通機関のアクセスポイントを考慮した Focus+Glue+Context マップシス
テムを提案する．Focus には目的地の周辺にあるバス停や駅などのアクセスポイント (ローカル AP) を，Context には新幹線や飛行機などの長距離移動で使われるような大きなアクセスポイント (主要 AP) と，そこからローカル APまでの路線を表示することで，ユーザーは主要 AP からローカル AP までの路線経路と，ローカル AP から目的地までの歩行経路を同一画面上で１度に閲覧することが可能となる．
キーワード Web マップ, 位置情報システム, ビジュアライゼーション, コンテキストアウェアネス, 地理情報システム

1. は じ め に

縮尺により表示する Context 領域，2 つの領域の間で縮尺差によって発生する歪みを吸収する Glue 領域の３つである．この近年，Google マップや Yahoo!地図等の Web マップシステ

ように，Focus と Context の間に可変縮尺の Glue を導入する

ムが広く普及し使われている．Web マップシステムを使うこことで，Focus と Context を一定の縮尺で描画することが可能とで，ユーザーは縮尺や表示範囲を自由に選んで地図を閲覧すとなり，視認性と一覧性を両立させたマップを実現している．

ることができる．しかし，これらの Web マップシステムでは，
画面上に表示される地図は同一縮尺のため，縮尺を変更する際
は画面全体の縮尺を変更する必要がある．例えば，交通機関を利用して目的地へ行くときの行き方を調べる場合を考えてみよう．目的地が遠方であれば，新幹線や飛行機等の長距離移動に適した交通機関を利用するため，空港やターミナル駅などのよ
うな広域においても目印となる大きなアクセスポイント (以下主要 AP と呼ぶ) を経由することになる．そして主要 AP から
は鉄道やバスを乗り継いで目的地の最寄りにあるアクセスポイント（以下ローカル AP と呼ぶ）まで行き，そこから徒歩で目的地へむかう．主要 AP からローカル AP への路線経路を決めるのには，目的地，主要 AP，ローカル AP，路線の経路を表す線が含まれる広域地図 (小縮尺の地図) が適しており，ローカ
ル AP から目的地までの歩行経路を決めるのには，より詳細に道路が描画されている詳細地図 (大縮尺の地図) が適している．
よって従来の Web マップを使用して行き方を決める場合，広図 1 Focus+Glue+Context マップ EMMA

域地図と詳細地図を切り替えながら使用しなければいけない．
こ の 問 題 を 解 決 す る た め ，我々は 図 2 の よ う な Fo-

これにより，先程の例のような場合においても，目的地から

cus+Glue+Context マップシステム EMMA [1] [2] [3] を提案

ローカル AP までの経路の詳細と，目的地と主要 AP の位置関した．EMMA は広域と詳細を同時に 1 枚の画面で閲覧可能な係の把握を同一画面上で１度に行うことが可能となった．一方Focus ＋ Glue ＋ Context マップを提供する．Focus ＋ Glue ＋

で，本当に有用なマップを実現する上で，以下に示すような問

Context マップは縮尺の異なる 3 つの領域によって構成される．

題が残っている．

注目する部分を大縮尺で表示する Focus 領域，周辺部分を小問題 1 Glue は Focus の生成によって隠れてしまう領域を限られたスペースに圧縮する．そのため，Glue 上には重要な道路を選別して描画する [4] [5]．また，地名や建物名等の地図オブジェクト情報も描画しない．Focus が大きくなると，Glue に圧縮される領域も増大し，地図から得られる地図オブジェクト情報が減少する．
問題 2 Focus ＋ Glue ＋ Context マップは 3 つの領域から構成されるため，拡大して閲覧したい領域に合わせて，それぞれの領域に以下の操作を行う必要がある．

Focus：拡大したい領域を含むように大きさを変更
Glue ：道路の圧縮具合に合わせて領域幅を調整
Context：閲覧したい領域が全て画面内に収まるよう
地図移動，縮尺変更

図 2 Fisheye View Map

本稿では，これらの問題を解決するため，交通機関のアクセス
ポイントとユーザーの目的地を考慮した Focus+Glue+Context

指定した地点から徒歩圏内にあるローカル AP をもとに Focus

マップシステムを提案する．

の形状を決定する．

2. 関 連 研 究

3. 提案システムの概要

この章では，本研究に関連する研究について述べる．

この章では，提案システムの目標と，システムの構成につい2. 1 Fisheye View map
広域地図と詳細地図を同じ画面上で表示する手法としてて述べる．

3. 1 提案システムの目標

FisheyeView マップ [6] [7] がある．地図全体に円形の魚眼レン(1)Access-Points-Based map

ズを当てたような変形を施すことで，全体の位置関係と目的地

提 案 シ ス テ ム で は ，Focus+Glue+Context マ プ シ ス テ ムの詳細を同時に把握することを可能としている．この地図では，EMMA を用いて，図 3 のような Access-Points-Based map

中心付近の様子は詳細に知ることができるが，周辺部は道路がの実現を目指す．Access-Points-Based map は Focus，Glue，

密集してしまい道のつながりが視認しにくいという問題があContext の 3 領域で構成される．Focus は目的地を中心とし，る． また，地図全体にわたって大きな歪みがあるため，距離感

目的地の近傍と目的地からローカル AP までの道路を大縮尺での把握も難しい．EMMA では, このような Fisheye View マッ表示する．Context は主要 AP と，主要 AP とローカル AP を

プに Glue を加えた，Focus+Glue+Context 型マップを実現し結ぶ路線を小縮尺で表示する．Glue は可変縮尺で道路を表示ている. Glue に地図の歪みを全て集中させることで，注目領し，Focus と Context の道路を滑らかにつなぐ．ユーザーはこ

域（Focus）と広域（Context）を歪み無く一定の縮尺で描画すのマップを用いることで，主要 AP からローカル AP までの路

ることが可能となる．また，各地図座標に動的に再配置関数を線経路と，ローカル AP から目的地までの歩行経路を 1 つの画

作成し，それに沿って Focus を生成することで，自由な形状の面で閲覧することができ，目的地まで行くために使用するロー

Focus を生成可能にしている．

カル AP や，その際に使う路線を柔軟に選択することが可能となる．

2. 2 EMMA における任意形状 Focus
準凸多角形 Focus 生成手法 [8] を用いることで，凹多角形

Focus の生成が可能となる．それまでは，円形や矩形のような凸多角形の形状の Focus しか生成できなかったが，この論文では，Focus の形状を準凸多角形へと変形することで凹多角形のFocus も生成可能となることを明らかにしている．しかし，この手法では，Glue における歪みついては考慮されていないため，不動点が観測点領域の端に定められた場合，Glue の歪みが大きくなり視認性が低下してしまう．さらに Focus が鋭角を含んでいる場合，その周辺の道路や鉄道などが Glue において大きく歪んで視認性が著しく低下するという問題も存在する．また，この手法では，Focus の形状はユーザーが頂点座標を全て入力することによって行っているが，本研究では，ユーザーが図 3 Access-Points-Based map

(2) 準凸多角形 Focus の生成
EMMA では図 4 に示すように，Focus を形成する各頂点を不動点と呼ばれる基準点と逆方向に遠ざけるように再配置することで Focus を生成する．この際，不動点は Focus を形成する多角形の外部を通ることなく全頂点と線分を結ぶことができる領域を持つ必要がある．このような領域を持つ形状を準凸多角形という．たとえば，図 5 において，左の形状は Focus を形成す
る多角形の外部を通ることなく不動点と全頂点を結ぶことができるため準凸多角形であるが，右の形状では不動点をどの位置に配置しても，多角形の外部を通ることなく不動点と多角形の全ての頂点を結ぶことができないため準凸多角形ではない．準凸多角形でない形状の Focus を生成すると，道路の繋がりが途

図6

システム構成図

切れてしまったり，地図上の各地点の位置が実際とは異なる位置で表示されてしまう．そのため，EMMA で生成する Focusの形状は必ず準凸多角形にする必要がある．

4. 提案システムの実現法
この章では，提案システムを実現するための各機能について
述べる．

4. 1 Focus 形状算出機能
4. 1. 1 Focus 形状の要件
以下に示す領域を Focus 内に含むことを，Focus 形状の要件とする．

•

指定地点の近傍指定地点の近傍は，ユーザーが閲覧したい可能性が

図 4 EMMA における Focus の生成最も高いため Focus に含むべきである．今回は近傍を指定地点から半径 500m と定めた．

•

指定地点から徒歩圏内にあるローカル AP
今回，ローカル AP を経由して指定地点へ行くことを想定した地図の生成を目的としているため，指定地点
から徒歩圏内のローカル AP を Focus に含める．今回
は徒歩圏内を指定地点から半径 1.5km と定めた．

図5

準凸多角形の例•

ローカル AP の周辺
ローカル AP から指定地点に行く過程で別の地点に寄

3. 2 提案システムの構成り道する可能性を考慮すると，ローカル AP 周辺のエ提案システムの構成を図 6 に示す．提案システムは，Focus

リアも，ユーザーにとって重要であるため Focus に含形状算出機能，Glue 画像サーバー，Context 補正機能によっめるようにする．今回は周辺範囲をローカル AP からて構成される．ユーザーはブラウザ上の地図で地点の指定を行い，その座標が提案システムへの入力となる．Focus 形状算出

半径 100m と定めた．

•

指定地点からローカル AP までの経路確認に必要な領域

機能では，入力された地点の座標をもとに Focus の形状を決定

ローカル AP から指定地点への経路は必要不可欠であする．まず，アクセスポイントデータベースより，目的地からり．それらの道路は Focus 内に含むべきである．

徒歩圏内にあるローカル AP の情報を取得する．それらの駅を

Focus 内に含み，かつ必要無い領域を除いた形状を求め，それ4. 1. 2 形状の決定に必要なローカル AP 情報の取得

を Focus の形状とする．そして，Glue 画像サーバーによって，交通機関のアクセスポイントに関する情報を格納したアク求めた Focus 形状に合わせて Glue 画像を生成する．Context

ションポイントデータベースを用いて，Focus の形状を決める補正機能では，アクセスポイントデータベースから取得した主のに使用するローカル AP を選別する．今回はローカル AP と

要 AP の位置情報をもとに，Context に主要 AP が含まれる

して，鉄道の駅を用いる．以下に，選別方法を示す．

ような地図の縮尺と表示範囲を計算し Context をその結果に合わせて補正する．そして最後に，地図描写システムによって

step1 指定地点の半径 1.5Km 以内にある鉄道のアクセスポ

Context 画像の上に Glue 画像，Focus 画像を適切な配置で重イントを，ローカル AP の位置情報として取得する．

ね合わせることによって Focus+Glue+Context マップを生成

step2 以下に示すような，Focus 形状の決定に不必要なローして出力する．

カル AP を，取得した情報の中から削除する．

•

複数の路線があるローカル AP

step4 指定地点，主要 AP，ローカル AP が全て画面内に収まるように Context の表示範囲を調整する．

複数の路線を持つ駅は，データベース上では路線ごとに別々の駅として登録されているが，Focus の形状を求めるにあたって必要な APの位置情報は，同地点に対して１つであれば良い．

•指定地点から 500m 以内にあるローカル AP
指定地点から 100m 以内の領域は，4.1.1 で設定した要件を満たしており必ず Focus に含まれるため，その領域にあるローカル AP は形状を求めるのには不必要である．

•

他のローカル AP と指定地点の経路上に存在するローカル AP
指定地点からローカル AP までの経路にあたる領域は 4.1.1 で設定した要件を満たしており必ず Focus に含まれる．よってその領域に存在するローカル AP は Focus の形状を求めるのには不必要である．

5. プロトタイプシステム
提案システムの機能を全て持つプロトタイプシステムを実装した．サーバサイドに Java，クライアントサイドに Javascriptを使用した．また，Web マップシステムとしてのインターフェースを実現するために，Javascript ライブラリである Lealet [9]を活用した．地図データに関しては，OpenStreetMap [10] から取得した．ローカル AP データと主要 AP データの検索にはPostgreSQL と PostGIS [11] を用いて構築したデータベースを使用した．また，ローカル AP として使用する鉄道駅のデータ
は駅.jp [12] から取得した．

5. 1 アクセスポイントデータベース
交通機関のアクセスポイントに関する情報を格納したアクセ
スポイントデータベースを構築した，表 1 にアクセスポイント
データベースのデータ構造を示す．今回の提案システムでは，

4. 1. 3 形状算出方法

ローカル AP として鉄道駅を，主要 AP として空港と新幹線のFocus の形状を求めるアルゴリズムを以下に示す．

駅を用いた．表 1 に示すようなデータを用意することで, 高速

step1 4.1.2 で求めたローカル AP をを中心とする半径 100m

道路の IC やバス停をローカル AP とすることも可能である．

の円と，指定地点を中心とする半径 500m の円を結ぶ

表 1 アクセスポイント DB テーブル

共通接線（基準線）を引く

step2 隣り合う頂点の基準線同士が交点を持つ場合は交点を

カラム

データ型

説明

AP id

int

アクセスポイントをを識別する ID

AP typevarchar

交通機関の種類

Focus の新頂点として加え，持たない場合は接点の間AP name varchar

アクセスポイント名

を円に近似する

line cd

int

路線コード

lon

int

アクセスポイントの緯度

lat

int

アクセスポイントの経度

5. 2 Glue 画像サーバー
OpenStreetMap の地図画像を用いた Glue 画像を生成する
Glue 画像サーバの実装を行った．基本的な構造は，文献 [1] と同じである．必要なパラメータを組み込んだ URL をサーバに
図7

形状決定までの流れ

リクエストすることで，様々な形状の Glue 画像を返すことが可能である．リクエストパラメータは以下の 5 つである．

4. 2 Context 補正機能•

centerLngLat : Focus 中心の緯度経度目的地から最も近い主要 AP と，そこからローカル AP まで•

focus zoom level : Focus の縮尺の路線経路が Context に表示されるように，Context の縮尺と•context zoom level : Context の縮尺

表示範囲を補正する．今回は主要 AP として，空港と新幹線の•shape inner polygon : Glue 内側の形状 (Focus 中心か駅を用いる．

step1 アクセスポイントデータベースより，ユーザーの指定した地点から最も近い主要 AP の位置情報を取得する．

step2 step1 で取得した主要 AP の位置情報と指定地点の位
置情報を基に両者の距離を算出する．

らの相対座標)•shape outer polygon : Glue 外側の形状 (Focus 中心からの相対座標)このようなリクエストパラメーターを持つ URL を Glue 画
像サーバーにリクエストすることで，図 8 のような Glue 画像

step3 step2 で求めた距離と地図を表示するブラウザのサイを取得することができる．一番内側の枠は拡大前の Focus 形状

ズを基に，指定地点，主要 AP，ローカル AP を全てを表す．その 1 つ外側の枠が拡大後の Focus 形状を表す．1 番

画面内に含み，かつ Context の縮尺が最大になるよう外側の枠は，Glue 部分を含めた形状を表す．そのため，中間の縮尺を定める．

枠と外側の枠の間の部分が Glue として使用される．

図 10

プロトタイプシステムの概観

図 8 Glue 画像– 全道路
5. 3 Focus+Glue+Context マップシステム
図 9 のように，ベースとなる Context 領域の上に，Glue 画
像サーバ−から取得した Glue 用の画像，その上に，Focus の地図画像を重ねて表示することで，Focus+Glue+Context マッ
プを実装した．従来の Focus+Glue+Contex マップでは，ユーザーが各領域に対して操作を行っていたが，今回実装した提案

全ての道路を使用する．

– 車
車が通れる道路を使用する．

– ストロークストロークと呼ばれる道なりに続く道路を使用する．

– コネクティビティ優先システムでは，ユーザーが指定した目的地と交通機関を考慮し

Focus と Context の道のコネクティビティを考慮し，Focus にて Focus の形状と Context の表示範囲，縮尺をシステム側で描画されている道路を優先的に使用する．

決定し，Focus+Glue+Context マップを生成する．

– 小関らによる選別手法 [1]
接続する道路のなす角の大きさで道なりかどうか判別し，道なりと判定された道路を優先的に使用する．

– 村瀬らによる選別手法 [5]ストロークの長さや道路周辺に位置する施設情報に基いてストロークの重要度を決定し，重要度の高いストロークを優先的に使用する．Focus 付近における道路の偏りが少ない．

•

円形 Focus 生成ボタン

ユーザーは右クリックにより地図上の地点にピンを立てることができる．その状態で円形 Focus 生成ボタンを押すことで，ピ
図 9 Focus+Glue+Context マップの構成ンを立てた地点を中心とする円形の Focus を生成する．生成した Focus は，マウス操作によって Focus 範囲の移動や，大きさ5. 4 システムのインターフェースの変更が可能である．また，Focus のみ縮尺を変更するといっ実装したプロトタイプシステムの概観を図 10 に示す．プロた操作を行うことも可能である．

トタイプシステムは地図画面，地図縮尺ボタン，Glue 道路選別•

AP Focus 生成ボタン

手法選択ボタン，円形 Focus 生成ボタン，AP Focus 生成ボタ

提案システムとして述べた機能を実現した部分．ユーザーは右ン，Clear ボタン，Context 補正ボタンによって構成され，こクリックにより地図上の地点にピンを立てることができる．ピ

れらのボタンとマウスによって操作を行う．各ボタンを押したンを立てた状態で AP Focus 生成ボタンを押すことで，ピン際の挙動を以下に示す.

の地点を目的地として交通機関のアクセスポイントを考慮した Focus+Glue+Context マップを生成する．Focsu は目的地•

地図縮尺ボタンから徒歩圏内にある全てのローカル AP とそこまでの経路を表

地図の縮尺を変更することが可能．縮尺の変更はマウスのホ示し，Context は目的地から最も近い主要 AP を含み，かつ最イールを操作によっても行うことができる．

大の縮尺で表示する．

•

Glue 道路選別手法選択ボタン•

Clear ボタン

Focus を生成する際，Glue に描画する道路の選別方法を選択す生成された Focus や右クリックで立てたピンを消去し，地図表ることが可能．選択項目は以下のとおりである．

示範囲，地図縮尺を全てデフォルトの状態に戻す．

•

Context 補正ボタン

ユーザーが指定指定した地点から最も近い主要 AP を地図上に実験内容含み，かつ縮尺が最大となるよう地図の表示範囲と縮尺を補正

被験者は上記の評価対象である３つの Web マップシステム

する．AP Focus 生成ボタンとは異なり，Focus は生成しない．

を使用してタスクを行う．その後，ユーザビリティに関するアンケートに回答する．以下に，被験者が行うタスクの詳細な手順を述べる．

5. 5 システムの動作
ユーザーはブラウザ上の地図で，マウスの右クリックによって図 11 のようにピンを立てて地点の指定を行う．その後，画面の左側に位置する AP Focus 生成ボタンを押すことで，Fo-

step1 使用する３つの Web マップシステムの使用方法に関する説明を受け，使い方を理解する

cus+Glue+Context マップの生成を行う．図 12 が生成された
Focus+Glue+Context マップである．4.1.1 で定めた領域を含

step2 こちらで予め出発地点と目的地を設定する．被験者はむ形状の Focus を生成している．図の例では，指定地点の徒歩

事前に配布された名古屋市内の路線図（図 13）と Web

圏内に 2 つのローカル AP(桜山駅，瑞穂区役所駅) があり，そマップシステムを用いて, 出発地点から病院 (何の病院れら周辺と，指定地点からそこまでの経路を含む Focus が生成でも構わない) を経由して目的地へ行く経路を決めるされていることが確認できる．また Focus 生成前の地図画面

step3 出発地点から目的地に行くのに使用する路線とローカには主要 AP が含まれていなかったが，Focus 生成後の地図画

ル AP，経由する病院名，ローカル AP から目的地ま面は，Context の縮尺と表示範囲が調整され，指定地点から最での歩行経路を紙に図示するも近い主要 AP(名古屋駅) を画面上に含んでいることが確認で目的地点を変えて，このタスクを計 2 回行う．

きる．

図 11 Focus 生成前

図 12 Focus 生成後

6. 提案システムの評価
図 13 配布した路線図

提案システムの有効性を実験的に評価する．

6. 1 評価実験の目的
遠方の目的地へと行く場合，新幹線や飛行機等の長距離移動

評価尺度に適した交通機関を使用して主要 AP へ行き，そこから鉄道で•タスク完了までに費やした作業時間

ローカル AP へ行き，そしてローカル AP から目的地まで徒歩•

タスク完了までの操作回数で移動する．このような場合における提案システムの有効性を– 縮尺の変更 (2 段階変更した場合も 1 回と数える)

検証する．

– 地図表示範囲の移動

6. 2 評 価 方 法– Focus の拡張，縮小

提案システムの有効性を評価するために実験を行う．以下に実験内容についてまとめる．
評価対象•

通常の OpenStreetMap

Focus 生成機能を持たず，全体を同一縮尺で表示する

ユーザビリティ（アンケート）
アンケートは 5 段階で行い，1(全く当てはまらない)〜5(非常に当てはまる) のうち，最も当てはまるものを選択してもらう形式とした．アンケートの項目を以下に示す．

•

使いやすかった

円 形 等 の 単 純 形 状 の Focus の み を 生 成 す る Fo-•

ストレスを感じなかった

cus+Glue+Context マップ•

歩行経路の確認を行いやすかった•

路線経路の確認を行いやすかった

交通機関のアクセスポイントを考慮し，目的地に合わせた Fo-•

使っていて楽しいと感じた

cus ＋ Glue ＋ Context マップを生成する•

これからも使いたいと感じた•

地図オブジェクト情報が見やすかった••

従来の Focus+Glue+Context マップ

提案システム被験

ステムが同程度の時間で，従来の Focus+Glue+Context マッ

者

大学生５名

プのみ長くかかるという結果になった．Focus の表示範囲の

6. 3 結果拡張を行うには，Glue 表示範囲と Focus 表示範囲それぞれ

タスク完了までの操作回数の平均を表 2 に，タスク完了までに対して拡張の操作をする必要があり，その操作に時間がかに費やした作業時間の平均を表 3 に，アンケート結果のグラフ

かるため，Focus の拡張，縮小の操作回数が多い従来の Fo-

を図 14 に示す．

cus+Glue+Context マップの作業時間が長くなってしまったと
表2考えられる．提案システムでは指定地点から徒歩圏内のローカ

操作回数の比較

ル AP を含むように Focus を生成するが，生成した Focus が縮尺の変更 地図範囲の移動 Focus の拡張，縮小 操作回数合計

病院を 1 つも含まない場合，Focus の表示範囲を拡張する必要

通常の OpenStreetMap

8.3

4.6

0

12.9

があり作業時間が増加した．しかし，それを踏まえても，3 シ

従来の F+G+C マップ

3.3

8.2

5.3

16.8

ステムの中で最も作業時間の平均が短かったため，提案システ

提案システム

3.1

2.8

1.2

7.1

ムは従来の Focus+Glue+Context マップが持つ「操作に時間を要する」という問題を改善しているといえる．

表3

次に，アンケート結果について述べる．グラフの縦軸は，各作業時間
作業時間 (秒)項目に当てはまる度合いを表し，数値が高いほどその項目に当てはまっていることを示す．提案システムは「使いやすかっ

通常の OpenStreetMap

253

従来の F+G+C マップ

416

た」，
「使っていて楽しいと感じた」，「これからも使いたいと感じ

提案システム234

た」の使用感に関する項目において他の 2 システムより良い評価を得ている．少ない操作回数で，ユーザーの求める情報を提供していることが，使用感の良さに繋がっていると考えられる．
また，「地図オブジェクト情報が見やすかった」という項目において，通常の OpenStreetMap が最も良い評価を得た．通常の OpenStreetMap は画面内の縮尺が全て一定で表示されるため，詳細な歩行経路を知りたい場合は画面全体の縮尺を大きくする．そのため，画面全体から詳細な地図オブジェクト情報を多く得ることができ，画面の一部分のみを拡大する従来のFocus+Glue+Context マップや提案システムより良い評価になったと考えられる．
また，従来の Focus+Glue+Context マップで生成される円形 Focus は，Focus 内に歩行経路を確認するのに不必要な領域
図 14 アンケート結果も多く含む．そのため，提案システムより Glue に圧縮される領域が大きい．提案システムは，形状の算出により，無駄な領

6. 4 考察域を含まない必要最低限の大きさの Focus を生成している．従

操作回数の平均は，提案システムが最も低く，従来の Focus ＋

来の Focus+Glue+Context マップと提案システムで「地図オGlue+Context マップシステムが最も多いという結果になった．

ブジェクト情報が見やすかった」の項目を比較すると提案シス

通常の OpenStreetMap は画面内の地図全てが同一の縮尺で描

テムのほうが良い評価を得ていることから，提案システムは画されるため，歩行経路と路線経路の確認を同時に行うことがGlue に圧縮されて失われる地図オブジェクト情報の量を従来出来ない．そのため，縮尺の変更を行う回数が多くなっている．

の Focus+Glue+Context マップより抑えているということが従来の Focus ＋ Glue+Context マップで生成される円形 Focus

わかる．よって，提案システムは従来の Focus+Glue+Contextの大きさはデフォルトで決まっている．その大きさが今回のタマップが持つ「地図オブジェクト情報の減少」という問題を改スクを行うには小さすぎたので，被験者は Focus の大きさを拡善しているといえる．

張したり，Focus の表示範囲を何回も動かす必要があった．そ今回の実験は Web マップシステムと路線図を用いて行ったのため，従来の Focus ＋ Glue+Context マップシステムの操が，地図上での路線の確認が難しいというコメントが被験者か

作回数が３システムの中で最も多くなったと考えられる．提案

ら得られた．OpenStreetMap の地図データでは JR などの地システムは，主要 AP を画面内に含むよう Context の補正を行

上を走る鉄道の路線は常に地図上に描画されているが，地下鉄

うので地図範囲の移動を行う必要がない．Focus に関しても，の場合は駅のみが地図に描画されており，路線は縮尺をかなり指定した地点に合わせた形状をシステム側で算出するため，従大きくしないと描画されない．駅だけではどの路線がどの駅を

来の Focus+Glue+Context マップより Focus の拡張，縮小を通るのか判断できないため，Web マップだけで経路確認を完結

行う回数が少ないことが確認できる．

させるには，地下鉄等の路線も地図上に描画する必要があると作業時間の平均を見ると，通常の OpenStreetMap と提案シ感じた．また，路線経路を決める際，地図からは得られない情報が欲しい時がある．地図を見ることで，使用する路線や乗換駅を知ることができるが，運賃や所要時間等の情報は地図からは得られない．1 つのシステムで歩行経路と路線経路の確認を完結させるには，乗り換え情報を詳しく検索できる機能を設ける必要があると感じた．また，提案システムでは，Context はとが可能になると考えられる．

謝辞

本研究は JSPS 科研費 26330136，25700009 および，科学技術振興機構 CREST の助成を受けたものです．

主要 AP を含み，かつできるだけ縮尺が大きくなるよう補正を行ったが，図 15 のように，Context から路線経路が外れてしまうことがあった．このような状況では路線経路の決定を正しく行うことができないため，路線経路も Context 内に含めるよ
う改善する必要がある．
また，今回の実験では想定よりも多くの経路が被験者によって決定された．病院という経由地を設けたことで，ただ最短経路を求めるのではなく様々なローカル AP を使うことが可能になったため，経路の選択肢に幅が生まれたと考えられる．被験者によって何に重きを置くかが異なり，乗り換え回数が少なくなるようルートを選択する者もいれば，歩行距離が最も短くなるルートを選択する者もいた．ユーザーによって重きを置く条
件が違うため，Focus 内に含める領域についても，ユーザーの好みに合わせて選択することができればより良いシステムになると感じた．

図 15

路線経路に関する問題

7. 終 わ り に
本稿では，ユーザーの目的地と交通機関のアクセスポイン
トを考慮した Focus+Glue+Context マップシステムを提案し，その実現法について述べた．ユーザーが指定した目的地に合わせて，Focus の形状，Context の縮尺，Context の表示範囲を決めることで，主要 AP からローカル AP までの路線経路と，ローカル AP から目的地までの歩行経路を同一画面上で１度に閲覧することが可能な地図を生成した．また，提案システムに基づいたプロトタイプシステムを実装し，評価実験を行った．
実験結果により，提案システムは従来システムより約 44%少ない操作時間と約 58%少ない操作回数で，地図利用者の要求に応じた Focus ＋ Glue+Context マップを生成することを示した．
そして，従来の Focus+Glue+Context マップシステムの持つ課題である，地図オブジェクト情報の減少を抑えることができた．今後の課題として，地図上への路線の描画がある．地図上に路線を描画することで，路線経路の把握がより容易に行うこ

文

献[1] 小関章太郎，高橋直久，focus+glue+context マップの glue 領域における道路ネットワーク総描法，第 6 回情報科学技術フォー
ラム講演論文集，D-025(2007)[2] Naohisa. Takahashi, An Elastic Map System with Cognitive
Map-Based Operations, International Perspectives on Maps
and Internet Vol.1, M. P. Peterson and J. Liu (Eds), Lecture
Notes in Geoinformation and Cartography,Springer-Verlag,
2008.
[3] Daisuke Yamamoto, Shotaro Ozeki, Naohisa Takahashi, Focus+Glue+Context: An Improved Fisheye Approach for
Web Map Services, Proceedings of the ACM SIGSPATIALGIS 2009, pp.101-110, 2009.
[4] 山本大介，小関章太郎，高橋直久，道なり道路選別手法に基づく
Fisheye View マップ総描手法，電子情報通信学会論文誌，pp.
1914-1925, 2010.
[5] 村瀬正樹，山本大介，高橋直久，Focus+Glue+Context マッ
プのためのストロークに基づく道路ネットワーク総描システム，
DEIM Forum 2016 H7-3.
[6] George W．Furnas，Generalized Fisheye Views，CHI’86，
pp．16-23， 1986．
[7] Manojit Sarkar，Marc H．Brown，Grapahical Fisheye viewsof graphs，CHI ’92 Conference Proceedings，pp．83-91，
1992．
[8] 加藤史也，山本大介，高橋直久，地図オブジェクトの形状を考慮した Focus 生成シス EMMA テムの実現，DEIM Forum 2014
E9-1.
[9] Leaflet
http://leafletjs.com/[10] OpenStreetMap
http://www.openstreetmap.org/[11] PostGIS
http://postgis.refractions.net/[12] 駅.jp
http://www.ekidata.jp/