その他の課題対応について

76

77

表 2-14  対応候補一覧

案 対応策 内容

（１） transformで分類する  アイコンを使用する場合には、SVG Tiny1.2

Ref 仕様にてエンコードを強制する、という方 法を記述する。

 現行の「参考情報」を「規格」に格上げする。

（２） classを利用する  背景画像要素またはアイコンのいずれか、ある いは両方に区別のための class 属性を挿入す るという方法。

（３） 文書構造に頼る  文書の構造に頼って区分してもらう旨の方針を 記述する。

表 2-14 の通り、アイコンの記述方法としては 3 通りの候補から検討したが、どの手

法を採用するとしてもアイコンの記述は可能であり、かつ特に問題はないということが わかる。

（１）transform による分類は、SVG Tiny1.2Ref 仕様に定められている通り、規格

上も問題はなく、（２）class属性を利用する手法でも、XMLの仕様上特に問題はなか った。（３）においては、昨年度版の流通フォーマットの仕様をそのまま継承するもので あるが、前述のとおり、昨年度版の流通フォーマットの文書構造のままでも、アイコンと 背景画像は区別できるという状況であった。

したがって、アイコンに関しては、特に仕様の追加や変更をすることなく、従来通り の文書構造を保持したままとし、運用上の対応においてアイコンの記述に関して補足 するにとどめた。

（２） 構造物の表現の対応 

現行の流通フォーマットでは、フロアの外郭、店舗間の間仕切り、柱、フロア代表点、

施設代表点等の情報を記述することができる。また、目的地の場所を強調表示するこ とができるように、必要に応じて店舗等の領域を識別するための「区画」をポリゴンで表 現することができる。

しかし、昨年度、流通フォーマットに基づいたデータを描画した地図を利用し、被験 者による目的地まで移動する実証実験を行った結果、「エレベータ」、「エスカレータ」、

「階段」、「スロープ」、「段差」などのフロア移動に関わる地図上の目印となる情報を表 示してほしいとの声が多く寄せられた。²

したがって、今年度の改訂作業においては、「エレベータ」、「エスカレータ」等の建

2 平成21年度３次元DB基盤整備検討委員会（第３回）、３次元DB実証実験WG（第２回）など

78

物内の構造物に関しても描画できるよう、SVG 作成時に既存図面上をなぞって各種 構造物のデータを取得することとした。その際、各種構造物の図形要素（polyline）に 関しては背景図と同様の扱いとし、「そこに構造物があるかどうか」、を視覚的に判別 可能とするための対応とした。

一方、内部的に各種構造物を判定、検索するためのしくみとしては、polyline 図形 ではなく、各種構造物に対応したアイコン等の point 図形に対し、各種属性情報を関 連付けることで対応することとした。

具体的には、昨年度定義した、「Picket」により建物内の各種構造物を分類する手 法を踏襲する。SVG Tiny1.2の仕様に準拠し、g要素のclass属性により、各種構造 物を区別している。表 2-15に、picketの一覧を示す。

表 2-15  PicketのSVG定義

Picketの種類 属性

名称 SVG定義 名称 種類 SVG定義 フロア代表点 floor_point - - -

出入口点  entrance_p oint

施設代表点ID （文字列） （施設代表点ID）

なし （※１） none ノードID （文字列） （ノードID）

種別 屋内出入口 indoor 屋外出入口 outdoor

設備 なし none

階段 stairs

エレベータ elevator エスカレータ escalator 改札フラグ 改札あり ticket-gate

改札なし normal

非常口フラグ 非常口あり emergency-gate 非常口なし normal

施設代表点 institution_

point

識別情報 （文字列） （識別情報）

種別 テナント tenant 付帯設備 equipment 区画（※２） section 用途 （文字列） （用途）

ノード node - - -

79

（３） 新たな空間への対応 

今年度の実証実験においては、「吹き抜け空間を含む複雑な構造」に対応すること がひとつの大きな目標であった。吹き抜け空間に関しては、区画ポリゴンをドーナツ状 のくり抜かれたポリゴンとすることで対応可能であると想定し、検討を進めた。

結果としては、区画ポリゴンはくり抜き形状を問題なく実現できることが判明したため、

吹き抜け空間に関してはくり抜きポリゴンを作成することで対応した。描画する際は、フ ロア輪郭のSVG描画要素に対し、SVGのfill-ruleプロパティを適切に設定し、複数 のポリゴン図形を組み合わせることで対応することとした。

背景図にラスタ画像を用いる場合は、吹き抜けに対応する部分の描画色を「透過」

に設定すること等も検討したが、背景図に用いる画像ファイルのフォーマットが必ずし も透過色をサポートしていない場合も考慮し、フロア輪郭ポリゴンを正式な仕様とし、

透過画像に関しては「使用してもよい」とする記述にとどめた。

（４） 精度情報の取り扱い 

流通フォーマットに準拠した案内図面を記述する際、作成する元となる既存図面

（CAD やイラストマップ等）には様々な種類があり、また必ずしも詳細な案内が可能に なる既存図面が入手できるとは限らない。たとえば、フロアマップのような簡易平面図 は、人間の視覚に訴えるようデフォルメされている場合が多く、CAD図面と比較した場 合に数学的な精度を持っているとは言い難い。

そこで、利用する図面（図面のリソースや入手経緯）を明らかにし、流通フォーマット を利用して何らかの案内を行う利用者向けに精度情報を提供すべきであると考えた。

具体的には、①何らかの基準により、精度レベルを文字列で示す（例：松竹梅）、② 縮尺等の基準値を用いて、精度レベルを数値で示す、③精度レベルを流通フォーマ ット内に記載せず、外部の精度情報を参照する、という 3 つの手法を提示した（表 2-16）。

80

表 2-16  対応候補一覧

案 対応策 内容

（１） 文字列を使った指定  図面の種別に関して、例えばMIME Typeの ようなコンパクトな文字列によって規定できる場 合を想定したもの。

（２） 数値による指定  図面の種別を数値で表現するような尺度が存 在するとすれば、そのような数値を利用する。

例えば、屋外地図の「縮尺」のような概念で図 面の精度を指定するような方法。

（３） URIを使った指定  図面の種別が外部で規定されており、その規

定をURIで参照できる、といった場合を想定し たもの。

案（１）に関しては、図面の種別に関して、予め規定した「リテラル文字列」を指定す るものである。RDFでは一般的な手法であるが、事前に「種別」を網羅的に定義するこ とが必要であり、サービス普及のためには、規格等の標準化が望まれるが、図面は 様々な種類があること、さらに国際化を視野に入れた場合には、整備が困難になるこ とが容易に予測できるので、多くの事業者が利用することを想定している、本事業の目 的には相応しくない。

案（２）に関しては、図面の種別に関して、屋外地図の「縮尺」のような概念で、図面 の精度を指定する方法である。この方法も RDF では一般的な手法であり、精度を数 値化することで、利用者に提供するサービスの対象範囲が明確化されるメリットがある。

他方で、デフォルメの大きい地図に関しては、数値化するのが困難（対象外となってし まう）であり、網羅的な対応が行えない。

案（３）に関しては、図面の種別に関して、外部で規定されており、その規定を URI で参照するものである。この方法もRDFでは一般的な手法であり、事後的に種別を追 加したり、国によって使用する種別を変更する、といった柔軟な対応が可能である。

以上の検討の結果、本事業では案（３）の「URIを使った指定」を採用した。

以下に実装例を示す。

81

図 2-44  URIを使用した図面種別のエンコード例

（参考）：dcterms:conformsTo

・  この図面が「rdf:resource属性によって指定される URIで規定される何らかの標 準」に準拠している、ということを宣言するためのボキャブラリ

・  参照先は「標準」であれば何でも構わない

・  列挙することで、複数の標準に準拠することも想定

（５） 入れ子構造の取り扱い 

昨今の複合型大規模商業施設（郊外のアウトレットやショッピングモールなど）では、

大まかなエリアの案内図と、各エリア内の店舗案内図など、いくつかの案内図が入れ 子構造になっている場合も多い。たとえば、大手ショッピングモールなどでは、子供服 の店舗がある特定のエリアに集中して店舗を展開し、その中にゲームセンターやフー ドコートがあり、フードコート内の店舗マップが別に存在する、といった例も多い。

このような場合、一つの案内図だけではなく、まず施設全体の大まかなレイアウトを 示した案内図があり、特定のエリア内における別の案内図がある、という状況（案内図 の入れ子構造あるいは親子、孫構造）となる。改訂版の流通フォーマットにおいては、

上記の入れ子構造に対応すべく、案内レベルは異なるが、個々の案内図が親子や孫 の関係にあることを再現できるよう、対応を行った。

具体的には、親（全体図）から子（詳細図）への参照、もしくは子（詳細図）から親（全 体図）への参照のいずれかを記述することで、相互の親子関係を保持することを可能 とした。なお、親子の関係は１：１ではなく、複数図面間において対応可能とし、かつ親 子（1階層）だけでなく複数階層をたどることも可能な構造とした。

<svg>

…

<metadata>

<cc:Work>

<dcterms:conformsTo rdf:resource=“{uri‐to‐specify‐standard}”/>

…

</cc:Work>

</metadata>

…

</svg>