レイヤ制御および図形編集の評価

市販のデジタルマップを用いて，レイヤ制御，図形編集に関する提案手法の評価実験を 行った．以下，評価仕様について説明する．

提案法の有効性を確認するため，3.1.1 に示した従来法との比較を行う．図 3-11 に示す ように，クライアントからサーバに表示対象のタイル画像の取得をリクエストし，当該タ イル画像を受信，表示するまでの時間（以下，「処理時間」）を計測し，評価に用いる．そ の際，ランダム関数を用いて生成した 100 回分の地図スクロールパスを用いて地図表示更 新を行う．このとき1回の地図スクロールは平均約200ピクセルである．

レイヤ毎のタイル画像を生成するコストは大きい．そのため，提案法では必要となるレ イヤ毎のタイル画像が生成済みかどうかで処理性能に違いが生じる．そこで，全レイヤの タイル画像がそろっている最良ケース（以下，「提案法ケース1」）と，レイヤ毎のタイル画 像がない状態から始める実際の利用場面を想定したケース（以下，「提案法ケース2」）で検 証を行う．従来法1-Aについて重畳レイヤ数と処理時間合計値との関係を把握する（実験1）． 次に100回分の表示更新を行う移動パスを計9パターン用意し，それぞれに対して従来法 2-A，提案法ケース1，提案法ケース2の比較を行う（実験2）．この時，実際の利用場面を 想定し，10 回地図表示する毎に表示レイヤ切り替え処理を行う．また，一度生成したタイ ル画像は動的にキャッシュし，次回以降，レイヤの切り替えなどがない限りこの画像を再 利用する．

図 3-11 レイヤ制御処理時間の計測範囲

次に実験条件について示す．地図データには，地方都市（面積約 40km²）の市販地図を 用いた．使用レイヤは，地図データを有する78レイヤとした．地図表示エリアは幅600ピ クセル，縦480ピクセル，またタイル画像は，幅と縦が共に250ピクセルの透過対応のPNG

１ﾀｲﾙ毎の処理時間

ｸﾗｲｱﾝﾄ サーバ

タイル画像要求 タイル画像返信

タイル画像描画

タイル画像要求

･･････

35

形式を採用した．図 3-12に実験で用いたAjax-GISクライアントの表示例を示す．画面左 側にレイヤ制御を行うためのレイヤパネル，画面中央に地図表示エリア，画面右側に図形 編集操作パネルを設けている．また表 3-2 に本実験で使用したサーバ，クライアント環境 を示す．

図 3-12 評価実験で使用するクライアントシステム画面

表 3-2 評価実験に用いるハードウェアスペック クライアント サーバ

CPU AMD Athlon 64 X2 4800+ Intel Core 2 Quad Q6600

RAM 4096MB 4096MB

OS Windows XP SP2 Windows XP SP2

[1] 実験１

従来法1-Aにおける実験1の結果を表 3-3に示す．表示レイヤ数を変えて，100回分の 地図スクロールパスによる上記処理時間を計測した．またレイヤ数と処理時間合計値の関

係を図 3-13に示す．処理時間合計値とは，地図スクロールパスで必要となった全タイル画

像の上記処理時間の合計値であり，順次地図画像を生成表示しつつスクロールパスを一巡 する時間である．また，1タイル画像あたりの平均処理時間とは，処理時間合計値をタイル 画像数で割ったもので，タイル画像の平均的な処理時間を示している．従来法 1-A はレイ ヤ数に応じてタイル画像を重畳表示するため，処理時間合計が比例的に増加する．図 3-13 で示したレイヤ数と処理時間合計値は重相関係数R²が 0.9403 であり，両者に強い正の相 関があることが分かる．以上より従来法 1-A は表示するレイヤ数が多くなるほど処理時間

地図使用承認©昭文社第50G107号

36

が増加し，その結果表示性能が劣化することが分かる．レイヤ数 3 の場合でも，処理時間 合計値は後述する提案法の 5 倍以上を要し，地図スクロールが大幅に劣化する．これは，

例えばレイヤ数の多い大規模施設管理を行う場合には，従来法 1-A の適用は困難であるこ とを示している．

表 3-3 表示レイヤ数に応じた処理時間の変化 レイヤ数 タイル数 総処理時間(s) １ﾀｲﾙ毎の

平均処理時間(ms)

ﾀｲﾙ画像ﾃﾞｰﾀｻｲ ｽﾞ合計(kb)

3 1129 378.3 335.0 816.9

6 2082 483.2 232.1 1145.9

9 3881 955.7 256.6 3396.6

12 4890 1490.1 304.7 3911.4

図 3-13 レイヤ数と処理時間合計値の関係

[2] 実験２

表 3-4は実験 1で使用した地図スクロールパスを用いた実施結果である．本実験では，

平均6レイヤを表示している．いずれの手法も従来法 1-Aと比較すると大幅に処理時間が 短いことが分かる．1タイル画像平均処理時間は，レイヤ毎のタイル画像の生成を行わない 提案法ケース1が最も短い．従来法2-A は，地図データを読み込んでタイル画像に描画す るコストが大きく，提案法ケース 1 に比べると処理時間が長くなっている．また提案法ケ ース 2 は，開始時にはレイヤ毎にタイル画像を描画生成することになり，さらにタイル画 像合成処理を行うため，3手法の中では最も処理時間が長くなった．なお，同じパスを移動 したにもかかわらずタイル画像数に若干の違いが見られるのは，クライアントの読み込み タイミングに差があるためであるが，全体の3%程度であるため特に問題とはならない．

37

次に実験1で使用した地図スクロールパスを含んだ計9パターンの実験結果を図 3-14に 示す．実験は，地図スクロールパス1から順に実施した．従来法2-A の処理時間は大きく 変化することがないのに対し，提案法ケース 2 では，移動パスが進むにつれて処理時間が 短くなっている．

提案法ケース2では，地図スクロールパス1は，レイヤ毎のタイル画像を全くキャッシ ュしていない状態から始まる．そのため，地図スクロールパス 5 までは，生成するタイル

画像数が2,000以上あり，タイル画像生成処理コストが大きく，従来法2-Aより1タイル

画像当たりの処理時間が長い．しかし地図スクロールパス 6 を超えてからは，移動パス内 のタイル画像が既にキャッシュされているため，新規に生成するタイル画像数が減少する．

そのため，提案法ケース2の処理時間は従来法2-Aよりも短くなり，徐々に提案法ケース1 に近づいていく．地図スクロールパス9では新規に生成したタイル画像数が65であり，提 案法ケース1との差は約5msまで縮まっている．

表 3-4 従来法と提案法による処理時間の比較 タイル数 総処理

時間(s)

１ﾀｲﾙ毎の 平均処理時間(ms)

ﾀｲﾙ画像ﾃﾞｰﾀｻｲｽﾞ 合計(kb) 従来法

2-A 1160 78.9 68.0 3105.5

提案法

ケース1 1190 50.9 42.8 3101.1

提案法

ケース2 1200 87.5 73.0 3060.8

図 3-14 地図スクロール操作に伴う処理時間の変化

38

次に図形編集に関する評価について述べる．図形編集プロセスを実装し，提案法の有効 性について検証する．

先ずクライアントにてレイヤ及び検索範囲から検索条件を作成し，サーバに送信する．

この検索条件をもとに，サーバで地図データから図形検索を実施し，該当する図形一覧を クライアントに返信する．クライアントはこの図形一覧から編集対象図形をひとつ選択し，

編集処理を行う．図形が有する幾何は，図形を構成する頂点上に配置された矩形を操作す ることで実現し，また描画設定は線種，色などを設定するパネルを操作することで実現す る．

図形編集処理イベントを非同期通信処理することで，クライアントはサーバレスポンス を待たずに別の地図操作を行うことが可能となった．また図形描画にブラウザのベクトル 描画機能を使用しないため，図形回転や拡大・縮小など複雑な図形操作が容易に行えるこ とが確認できた．クライアントにおいて，例えば図形の面色変更や頂点追加などの図形編 集を指示すると，瞬時にサーバが作成した編集後図形が受信でき表示される．一例として，

サーバサイドで座標数100 の塗りつぶしポリゴンを生成する時間は100ms以下であった．

これより，リアルタイム性が確認され，ユーザストレスなしに図形編集を実現できること が検証された．

39