3. 3D都市モデルのXMLデータ

3.1　データモデルとの関係

データモデルは、ある目的に必要なデータを整理し、データの内容やその構造を記述した、データの定義です。地理空間データのデータモデルは、UML（Unified Modeling Language）というモデリング言語のUMLクラス図という記法を使って記述します。

UMLクラス図は、データの内容や構造を示したものであり、データのフォーマットを指定していません。そのため、データモデルに従って作成したデータを最終的にどのフォーマットで記述すればよいのかは、別途定める必要があります。これを符号化仕様といいます。

3D都市モデルでは、データのフォーマットとして汎用性の高いXMLを採用しています。よって、XMLスキーマが符号化仕様に該当します。XMLスキーマは、1対1でデータモデルと対応付いています。そのため、このXMLスキーマにしたがって作成されたXMLデータは、結果としてデータモデルに従ったデータとなります（図3-1）。

図 3‑1　データモデルとXMLスキーマとの関係

そこで本章では、まず3.2節において、3D都市モデルで使用するXMLスキーマの構成を概説します。次に、3.3節において、XMLスキーマとこれに基づいて作成される3D都市モデル（XMLデータ）について解説します。

なお、参考として、4章ではUMLクラス図で記述されたデータモデルをXMLスキーマに対応付けるためのマッピングルールを解説します。

3.2　3D都市モデルのXMLスキーマ

3.2.1　3D都市モデルで使用するXMLスキーマ

3D都市モデルは、CityGMLと呼ばれる、地理空間データに関する国際的な標準化団体であるOGC（Open Geospatial Consortium）が定めた3次元で都市を記述するためのデータモデルとフォーマットの国際標準に準拠して作成されています。

CityGMLは、GML（Geography Markup Language：地理マーク付け言語）を拡張した言語です。ここで、GMLはOGCが定めた地理空間データの記述に特化したXMLを拡張させた言語です。CityGMLはさらにGMLを拡張し、3次元で都市空間を記述することに特化した言語です。

CityGMLには都市を構成する基本的な地物とその属性しか定義されていません。そこで、3D都市モデルでより詳細に都市を表現するため、CityGMLを拡張したi-UR（i-Urban Revitalization）を使用しています。

つまり、3D都市モデルでは、CityGMLとi-URのそれぞれで定められたXMLスキーマを使用しています。さらに、CityGMLはGMLを使用していますので、結果として、3D都市モデルでは、GMLとCityGMLとi-URの大きく3種類のXMLスキーマを使用し、XMLデータとして記述されていることになります。

以降では、それぞれのXMLスキーマの概要を紹介します。

3.2.2　GMLの概要

GML（Geography Markup Language）は、OGCが定めた、地理空間データの記述に特化したXMLです。GMLで記述されたデータのファイルの拡張子は、gmlです。

GMLでは大きく2つのことが定義されています。

1つ目は、標準で定義されたデータモデルに従って、XMLでデータを記述するためのXMLスキーマです。標準で定義されたデータモデルとは、地理空間情報に関する国際標準であるISO19100シリーズにおいて定められたデータモデルです。ISO19100シリーズでは、「建物」や「道路」といった具体的な地物の定義は行いませんが、これらを定義するために必要な、点、線、面等の「幾何形状」をはじめとする、汎用的な概念のデータ構造を標準化しています。GMLはこのような標準で定義されたデータモデルに対応するXMLスキーマを定めています。例えば、幾何形状のXMLスキーマには、点、線、面、立体に対応する要素と複合型が定義されています。

2つ目は、データモデルからXMLスキーマを作成するためのマッピングルールです。GMLでは、データモデルの構成要素（例：クラス、地物の属性）ごとにマッピングルールが定められています。XML形式で地理空間データを符号化したい場合は、GMLが定めるマッピングルールに従って、データモデルに対応するXMLスキーマを作成する必要があります。このとき、建物や道路等の地物はデータモデルの作成者が名前空間や接頭辞を設定し、地物に対応する要素や複合型を作成します。一方、点、線、面のような幾何形状を表すクラスの要素や複合型は、上述したGMLが定めるXMLスキーマに定義されている要素や複合型を使用します。

以降の説明で、接頭辞としてgmlが付いている要素や型は、GMLで定義された要素や型です。

3.2.3　CityGMLのXMLスキーマ

CityGMLのデータモデルにはBuilding（建築物）やLandUse（土地利用）といった都市空間を構成する基本的な地物がクラスとして定義され、それぞれのクラスには、地物の基本的な属性も定義されています。また、各地物のクラスはLOD別に幾何形状を表すクラスとの関連が定義されています。CityGMLのXMLスキーマは、このUMLクラス図に対応する符号化仕様です。

CityGMLのパッケージ図を図3-2に示します。

図 3‑2　CityGMLのパッケージ図（出典：CityGML 2.0 一部加工）

このうち、青枠内に含まれる14のパッケージが、CityGMLで定義するパッケージです。ただし、TextureSurfaceは後方互換性確保を目的として定義されており、その使用は推奨されていませんので、3D都市モデルでは使用していません。

パッケージごとにXMLスキーマが作成され、パッケージごとに名前空間と接頭辞が付与されます。CityGMLで定義された各XMLスキーマの接頭辞、名前空間及びXMLスキーマファイルの所在（schemaLocation）を表3-1 に示します。schemaLocationに示されたURLにアクセスすると、XMLスキーマファイルをブラウザで閲覧することができます。

表 3‑1　CityGMLのXMLSchema

以降の説明で、接頭辞としてbldgやcoreが付いている要素や型は、CityGMLで定義された要素や型です。

3.2.4　i-URのXMLスキーマ

i-UR（i-Urban Revitalization）は、CityGMLを拡張し、都市計画や都市再生に特化した地物や属性を定義したデータモデルと、データモデルに対応するXMLスキーマが定義されています。CityGMLでは、都市を構成する基本的な地物と属性のみを定義しており、目的に応じて必要な地物や属性を拡張する仕組みを持っています。この仕組みをADE（Application Domain Extension）と呼びます。i-URはCityGMLに示されたルールに従い、これを拡張したADEの1つであり、Urban Planning ADEとも呼ばれています。

i-URは、CityGMLを拡張した4つのパッケージから構成されています。このうち、3D都市モデルのデータモデルとして利用されているのは、Urban ObjectとUrban Functionという2つのパッケージです（図3-3 ）。

図 3‑3　i-URのパッケージ図

CityGMLと同様に、パッケージごとにXMLスキーマが作成され、パッケージごとに名前空間と接頭辞が付与されます。i-URで定義された各XMLスキーマのうち、3D都市モデルのデータモデルで使用する接頭辞、名前空間及びXMLスキーマファイルの所在（schemaLocation）を表3-2 に示します。

表 3‑2　i-URのXMLスキーマ

以降の説明で、接頭辞としてuroやurfが付いている要素や型は、i-URで定義された要素や型です。

3.3　3D都市モデルのXMLデータ

3.3.1　3D都市モデルのフォルダ構成

3D都市モデルは、建築物、道路、土地利用、都市計画区域、災害リスクのような様々な地物のXMLデータから構成されています。データを格納するフォルダの構成は、CityGMLなどのXMLスキーマでは指定されていませんが、3D都市モデル標準製品仕様書において定められていますので、これに従います。

図3-4に3D都市モデルの成果物のフォルダ構成を示します。

図 3‑4　3D都市モデルのフォルダ構成

3D都市モデルのXMLデータは、ルートフォルダ（階層型ファイル構造における最上階層のフォルダ）の直下におかれた、「udx」フォルダの中に格納します。「udx」フォルダの中には、地物の種類ごとにサブフォルダが作成されており、各サブフォルダに対応する地物のXMLデータを格納します。例えば、「bldg」フォルダには建築物のXMLデータを格納します。

3D都市モデルの成果物のルートフォルダは、都市ごとにフォルダ名が異なりますが、「udx」とその直下の図3-4に示すサブフォルダは、各都市共通です。

詳細は、3D都市モデル標準製品仕様書の7.2.4項を参照してください。

3.3.2　3D都市モデルのファイル構成

3D都市モデルは、建築物、道路、土地利用、都市計画区域、災害リスクのような様々な地物のXMLデータから構成されています。データを格納するファイルの構成は、CityGMLなどのXMLスキーマでは指定されていませんが、3D都市モデル標準製品仕様書において定められていますので、これに従います。

図3-5に3D都市モデルのファイル単位を示します。

図 3‑5　3D都市モデルのファイル単位

3D都市モデルのXMLデータは、3D都市モデル標準製品仕様書に示すデータモデル（応用スキーマ）の単位、かつ、JISX0410 において定められた地域メッシュの単位にファイルを分割し、所定のフォルダ（3.3.1項参照）に格納します。

なお、ファイルの境界となる地域メッシュの境界線上の地物は分割しません。複数のメッシュに跨って存在する地物は、それぞれのメッシュに平面投影した形状が含まれる面積の割合を算出し、この割合が最も大きいメッシュに対応するファイルに含みます。面積が同じ場合はメッシュ番号の小さいファイルに含みます。詳細は、3D都市モデル標準製品仕様書の7.2.1項及び7.2.2項を参照してください。

3.3.3　3D都市モデルのXMLデータ

ここでは、3D都市モデルのXMLデータの内容を対応するXMLスキーマと対比しながら解説します。

まず、3D都市モデルのXMLデータの全体（図3-6）を概観します。

図 3‑6　3D都市モデルのXMLデータの全体像

1.6節でも説明したように、まず、このデータがXMLであることを宣言します。次に、ルート要素を記述します。3D都市モデルのルート要素は、core:CityModelです。このルート要素の子要素として地物のデータを記述します。

ルート要素であるcore:CityModelの開始タグの中には、このXMLデータで使用する接頭辞とそれが指す名前空間、そして、名前空間に対応するXMLスキーマファイルの所在を記述します。

さらに、core:CityModelの子要素として、まず、このXMLデータに含まれる地物の空間的な範囲をgml:boundedByという要素を使って記述します。

以降で、地物のデータを記述します。地物のデータは、core:cityObjectMemberの子要素として記述します。例えば、建築物（Building）のデータを記述したい場合は、core:cityObjectMemberの子要素としてbldg:Buildingを記述します。1つのXMLファイルの中に複数の建築物のXMLデータを記述したい場合は、このcore:cityObjectMemberを繰り返し、それぞれの子要素としてbldg:Buildingを記述します。

図3-7に、実際の建築物のXMLデータのファイルの冒頭部分を示します。

図 3‑7　3D都市モデルのXMLデータ（冒頭部分）

まず、XMLであるという宣言を行い、次にルート要素を記述します。ルート要素であるcore:CityModelには、接頭辞と名前空間、また、名前空間に対応するXMLスキーマのファイルの所在を記述します。このとき、接頭辞と名前空間のXMLスキーマファイルの所在は、このXMLデータで使用する全ての接頭辞と名前空間について記述しなければなりません。

建築物のXMLデータを記述する場合、建築物という地物はCityGMLのBuildingパッケージ（接頭辞はbldg）において要素等が定義されていますが、このBuildingパッケージのXMLスキーマだけではなく、他にも以下に示すような様々なXMLスキーマが必要になります。

l  建築物の詳細な属性を記述する：i-URのUrban Objectパッケージ（接頭辞はuro）

l  建築物の形状を記述する：GML（接頭辞はgml）

l  任意の属性を追加する：Genericsパッケージ（接頭辞はgen）

l  ルート要素のcore:CityModel：Coreパッケージ（接頭辞はcore）

l  建築物の壁面等にテクスチャを貼る：Appearanceパッケージ（接頭辞はapp）

l  建築物の屋内の階を表現する：CityObjectGroupパッケージ（接頭辞はgrp）

他にも、XMLデータを記述するためのXMLスキーマ等が必要になるので、接頭辞や名前空間の記述に関しては、G空間情報センターから公開されている3D都市モデルのXMLデータを参照し、これをコピーして使うとよいでしょう。

ただし、既に公開されている3D都市モデルのXMLデータは、バージョンが異なるi-URを参照している場合があります。バージョンが異なると名前空間もXMLスキーマのファイルの所在も異なりますので、自分が作る3D都市モデルが準拠している3D都市モデル標準製品仕様書に指定されたXMLスキーマの名前空間とファイルの所在と一致するよう、必要に応じて書き換えてください。

次に、地物のXMLデータを見てみましょう。前述したとおり、ルート要素であるcore:CityModelの子要素としてcore:cityObjectMemberを記述し、core:cityObjectMemberの子要素として地物のXMLデータを記述します。ここでは建築物（bldg:Building）を例とします。図3-8に建築物のXMLデータの一部を示します。

図 3‑8　建築物のXMLデータ（一部：前半）

core:cityObjectGroupの子要素として、bldg:Buildingの要素が記述されています（行番号10）。さらに子要素として、core:creationDate（行番号11）、gen:stringAttribute（行番号12以降、4回繰り返し出現）、bldg:class（行番号24）、bldg:usage（行番号25）、bldg:measuredHeight（行番号26）、bldg:storeysAboveGround（行番号27）、bldg:storeysBelowGround（行番号28）、bldg:lod0RoofEdge（行番号29）、bldg:lod1Solid（行番号42）が出現しています。

ここで、このbldg:BuildingのXMLスキーマを図3-9に示します。

図 3‑9　BuildingとBuildingTypeのXMLスキーマ

Buildingが要素宣言されていますので、タグとしてBuildingが出現することができます。このBuildingの子要素として何が出現できるかを見るために、この型であるBuildingTypeも見てみましょう。BuildingTypeはAbstractBuildingTypeを拡張（extension base=”AbstractBuildingType”）しています。これに追加して_GenericApplicationPropertyOfBuildingを呼び出しています。

では、拡張する元となっている複合型であるAbstractBuildingType（図3-10）を見てみましょう。

図 3‑10　AbstractBuildingTypeのXMLスキーマ

AbstractBuildingTypeは、core:AbstractSiteTypeを拡張（extension base=”core:AbstractSiteType”）しています。これに追加して、class、function、usageなどの要素が定義されています。AbstractBuildingTypeに定義された要素は、全て多重度が0以上（minOccurs=”0”）となっています。つまり、これは要素を省略してもかまわないことになります。実際に、XMLスキーマで定義されたyearOfConstruction（建築年）やroofType（屋根の種類）などの要素は図3-8に示したXMLデータには出現していません。ただし、これらの要素が出現する場合には、図3-10に示すXMLスキーマに記載された順序で出現しなければなりません（2.2.2項参照）。

さらに、AbstractBuildingTypeを拡張する元となっている複合型であるAbstractSiteType（図3-11）を見てみましょう。

図 3‑11　AbstractSiteTypeのXMLスキーマ

AbstractSiteTypeは、core:AbstractCityObjectTypeを拡張（extension base=”AbstractCityObjectType”）しています。

次に、core:AbstractCityObjectType（図3-12）を見てみましょう。

図 3‑12　AbstractCityObjectTypeのXMLスキーマ

core:AbstractCityObjectType はgml:AbstractFeatureTypeを拡張（extension base=”gml:AbstractFeatureType”）しています。これに追加して、creationDateなどの要素が宣言されています。gml:AbstractFeatureTypeは、接頭辞にgmlが付いていますので、GMLで定義された複合型です。

次に、gml:AbstractFeatureType（図3-13）を見てみましょう。

図 3‑13 AbstractFeatureTypeのXMLスキーマ

gml:AbstractFeatureTypeは、さらに、gml:AbstractGMLType（extension base=”gml:AbstractGMLType”）を拡張しています。これに追加して、boundedByなどの要素が宣言されています。

図3-14はgml:AbstractGMLTypeのXMLスキーマです。この複合型にはextensionがありません。よって、gml:AbstractGMLTypeが全ての元となる複合型といえます。

図 3‑14　AbstractGMLTypeのXMLスキーマ

図3-15に拡張する複合型の関係を図示します。

図 3‑15　bldg:BuildingTypeの拡張元と要素の出現順序との関係

gml:AbstractGMLTypeを拡張し、gml:AbstractFeatureTypeが定義されています。これら2つはGMLで定義された複合型であり、gml:AbstractFeatureTypeは地物を表す複合型です。

この地物を表す複合型（gml:AbstractFeatureType）を拡張し、CityGMLにおける地物としてcore:AbstractCityObjectTypeが定義されています。CityGMLで地物として定義されている全ての複合型は、このcore:AbstractCityObjectTypeを拡張して定義されます。

core:AbstractCityObjectTypeを拡張し、構造物を表すcore:AbstractSiteTypeが定義されています。

さらにこれを拡張して抽象的な建築物の概念を表す地物であるbldg:AbstractBuildingTypeが定義されています。

このbldg:AbstractBuildingTypeをさらに拡張したbldg:BuildingTypeをタグとなる要素bldg:Buildingの型として使用します。

複合型を拡張すると、元となる複合型に定義された属性や要素を、拡張した複合型でも記述できるようになります。つまり、bldg:BuildingTypeを型として持つbldg:Buildingの子要素として、bldg:BuildingTypeに定義された要素だけではなく、これが拡張する元となるbldg:AbstractBuildingTypeに定義された要素を記述できることを意味します。bldg:AbstractBuildingTypeに定義された要素には、これが拡張するcore:AbstractSiteTypeに定義された要素も含まれます。このようにして、bldg:BuildingTypeを型として持つbldg:Buildingの子要素として、bldg:BuildingTypeだけではなく、bldg:AbstractBuildingType、core:AbstractSiteType、core:AbstractCityObjectType、gml:AbstractFeatureType及びgml:AbstractGMLTypeで定義された、全ての要素を記述することができます。

ここで注意すべきは、複合型を拡張する場合は、拡張する複合型に定義された要素が先に出現するということ、また、多重度も引き継がれますので、必須となっている要素や属性は、拡張した先の複合型を型とする場合にも必ず記述しなければならないことの2点です。

図3-8の建築物のXMLデータと見比べていただきたいのですが、まずbldg:Buildingの開始タグにgml:idという属性があります。これは、gml:AbstractGMLTypeに定義されている属性です。次に、core:creationDateとgen:stringAttributeという子要素が出現しています。これは、core:AbstractCityObjectTypeに定義されている要素です。このとき、gen:stringAttributeは、core:AbstractCityObjectType（図3-12）では直接的に宣言はされていません。実は、gen:stringAttributeは、core:AbstractCityObjectTypeに定義されている_GenericApplicationPropertyOfCityObjectの代替グループ（substitionGroup）の要素として、GenericsパッケージのXMLスキーマの中で宣言されています（図3-16）。

図 3‑16 GenericsモジュールのXMLスキーマ

core:_GenericApplicationPropertyOfCityObjectのsubstitionGroupとして、_genericAttributeが定義され、この_genericAttributeのsubstitionGroupとしてgen:stringAttributeが定義されていますので、gen:stringAttributeもcore:_GenericApplicationPropertyOfCityObjectの代わりに出現することができます。

このようにXMLスキーマで定義されているので、bldg:Buildingの子要素としてgen:stringAttriuteが出現できていることになります。

さらに、そのあとに続くbldg:classなどの子要素は、bldg:AbstractBuildingTypeに定義された要素です。

図3-17に建築物のXMLデータの後半を示します。

図 3‑17　建築物のXMLデータ（一部：後半）

左側の行番号552にbldg:Buildingの終了タグがあり、553にcore:cityObjectMemberの終了タグがあります。つまり、図3-8の行番号10から図3-17の行番号552までが、1つの建築物のXMLデータです。

この終了タグの直前には、接頭辞としてuroがついた子要素が記述されています。これは、i-URのUrban Objectパッケージで定義された要素です。

図3-18にUrban ObjectのXMLスキーマを示します。

図 3‑18　Urban ObjectのXMLスキーマ

先ほどのgen:stringAttributeと同じように、Urban ObjectのXMLスキーマでも、bldgDataQualityAttributeやbldgKeyValuePairAttributeといった要素がbldg:_GenericApplicationPropertyOfAbstractBuildingのsubstitionGroupとして定義されています。このbldg:_GenericApplicationPropertyOfAbstractBuildingはbldg:AbstractBuildingTypeにおいて定義されています（図3-10）。つまり、これの代替グループの要素であるUrban Objectの要素もbldg:AbstractBuildingTypeの内容として記述することができ、この複合型を拡張するbldg:BuildingTypeを型として持つbldg:Buildingの子要素としてUrban ObjectのXMLスキーマで定義された要素を記述できるようになっています。

このようにして、3D都市モデルでは、個々の地物のXMLデータを記述する場合は、その子要素の記述順序に注意する必要があります。子要素として記述するのは型となる複合型に定義された要素になりますが、この複合型が拡張されている場合には、拡張元の複合型に定義された要素を先に記述する必要があります。特に3D都市モデルの場合には、CityGMLに定義された拡張の仕組みである”_GenericApplicationPropertyOfXXX”（XXXには地物の要素名が入る）があるため、これの代替グループとして定義した要素も”_GenericApplicationPropertyOfXXX”で指定された場所に出現できることに注意するとよいでしょう。

図3-19に要素の出現順序を示します。この順序は、建築物に限らず、CityGMLやi-URで定義された他の地物も同様です。

図 3‑19　要素の出現順序

3D都市モデルのXMLデータを作成するときは、その要素の出現順序がXMLスキーマに適合していることを確認してください。また、XMLデータを読み込む場合には、その要素の出現順序がXMLスキーマに従っていることを参考にするとよいでしょう。