本章は、より詳しくデータモデルと符号化仕様との関係を理解したい技術者や、CityGML 2.0に対応するADEを作成したい技術者を対象とした発展的な内容となります。
データモデルは、データの内容やその構造を、UMLクラス図を使って記述したものです。データモデルではフォーマットの指定を行いませんので、符号化仕様においてフォーマットを定める必要があります。
3D都市モデルでは、XMLスキーマを符号化仕様として指定しています。このXMLスキーマはデータモデルと1対1で対応付いています。そのため、このXMLスキーマにしたがって作成されたXMLデータは、結果としてデータモデルに従ったデータとなります。
データモデルに対応するXMLスキーマを作成するためには、UMLクラス図を構成するクラスや属性、クラス間の関係等をどのようにXMLスキーマに対応付けるのかというマッピングルール（図4-1）が必要です。
図 4‑1 マッピングルールの役割
このマッピングルールがあれば、どんなデータモデルであっても、規則性のあるXMLスキーマに変換できます。データモデルをXMLスキーマに変換する際のマッピングルールは、GMLに定められています。
そこで、本章では、UMLクラス図で記述されたデータモデルから、符号化仕様であるXMLスキーマを作成するためのマッピングルールを解説します。
ただし、3D都市モデルの作成とは、すでに用意されたXMLスキーマを使用してXMLデータを作成することであり、3D都市モデルの利用とは、このXMLスキーマを使用してXMLデータを読み込むことですので、3D都市モデルの作成及び利用の場面では、XMLスキーマそのものを作成することは行いません。
そのため、本節は、より詳しくデータモデルと符号化仕様との関係を理解したい技術者や、CityGML 2.0に対応するADEを作成したい技術者を対象とした発展的な内容となります。
なお、UMLクラス図からXMLスキーマへのマッピングルールには複数の選択肢がありますが、本チュートリアルでは、3D都市モデルのデータモデル及び符号化仕様のベースとなっているCityGMLに適用されているマッピングルールを説明します。
UMLクラス図をXMLスキーマで記述するためのマッピングルールの概要を表4-1に示します。
表 4‑1 UMLクラス図からXMLスキーマへのマッピングルール概要
詳細は後述しますが、クラス、属性及び関連は要素（element）としてマッピングされます。つまり、クラス、属性そして関連役割はタグとしてXMLデータに出現することになります。
クラスは、ステレオタイプに応じてマッピングルールが定められています。
<<FeatureType>>クラスは、要素宣言をします。
要素名はクラス名と一致させることが基本となります。ただし、クラス名が日本語になっている場合のように、クラス名をそのまま要素名とすると不具合が生じる場合はクラス名と要素名が一致しなくてもかまいません。ただし、クラス名と要素名の対応表を別途示す必要があります。これは、以降の属性名等についても同様です。
※本チュートリアルではわかりやすくするため、UMLクラス図は日本語で記述し、これに対応するXMLスキーマやXMLデータも日本語としています。
マッピングルール2 要素をcore:_CityObjectのsubstitutionGroupとします。
<<FeatureType>>クラスは「地物」です。そこでXMLスキーマでは、地物を表す要素のsubstitutionGroupとすることでこの要素も地物であることを定義します。具体的には、CityGMLに定義されたcore:_CityObjectという要素のsubstitutionGroupであると指定します。この要素は、CityGMLの中で地物を表す最も抽象度の高い概念です。
図4-2に例を示します。
図 4‑2 <<FeatureType>>クラスの要素宣言の例
「区域」という地物をクラスとして定義したとします。要素宣言を行い、名前にクラス名を使用しています（name=”区域”）。また、substitutionGroupにcore:_CityObjectを指定しています（substitutionGroup=”core:_CityObject”）。
なお、substitutionGroupの指定は、直接的でも間接的でも構いません。詳細は4.5節で説明します。
ステレオタイプが<<FeatureType>>となるクラスは、複合型宣言をします。
このとき複合型の名前は、わかりやすさのために「要素名+Type」とします。詳細は、4.3節と4.4節で説明しますが、複合型の内容にはクラスに定義された属性や関連役割の要素宣言が含まれることになります。
マッピングルール4 複合型は、core:AbstractCityObjectTypeを拡張（extension）します。
<<FeatureType>>クラスは「地物」です。そこで、XMLスキーマでは、地物を表す複合型を拡張することで、この複合型も地物であることを定義します。具体的には、CityGMLに定義されているもっとも抽象度の高い地物の複合型であるcore:AbstractCityObjectTypeを拡張します。
core:AbstractCityObjectTypeを拡張すると、その拡張された複合型もcore:AbstractCityObjectTypeに定義された要素や属性を持つことになります。詳細は4.5節において説明しますが、特徴的なものは、gml:id属性です。これは、XMLデータのファイルの中でそのデータを識別するためのIDです。
図4-3に例を示します。
図 4‑3 <<FeatureType>>クラスの複合型宣言の例
宣言した複合型は、要素の型として使用します。宣言した複合型を使用する場合には、複合型には接頭辞が必要です。図4-2の例でも、「区域」の要素宣言の型として指定されている「区域Type」には、「ex:区域Type」というように、接頭辞が付いています。
マッピングルール5 抽象クラスは、要素及び複合型のabstract属性の値を“true”とする。
抽象クラスも、マッピングルール1からマッピングルール4までに従い、要素宣言及び複合型の宣言を行います（図4-4）。加えて、これらの宣言の中でabstract属性を追加します。抽象クラスですので、abstract属性の値はtrue（abstract=”true”）となります。
abstract属性は、記述が省略されている場合は、”false“を意味するため、抽象クラスの場合には、”true”であることを明示します。
図 4‑4 抽象クラスの要素宣言及び複合型宣言の例
なお、abstract属性が”true”となっている要素宣言は、XMLデータのタグになることができません。
マッピングルール6 要素名＋PropertyTypeの複合型を作成する。
これはID参照のための複合型です。複合型の名前は、「要素名＋PropertyType」とします。
この複合型は、UMLクラス図の関連をXMLスキーマにマッピングするときに使用します。UMLクラス図に関連が定義されていない場合も、将来的にそのクラスが他のデータモデルから参照され、関連が定義されることがあるかもしれません。その場合に備え、ID参照のための複合型を用意します。
図4-5に例を示します。PropertyTypeの内容として、要素（ex:区域）を呼び出しています（element ref=”ex:区域”）。
図 4‑5 PropertyTypeの例
ここで、「sequence」の開始タグにminOccurs=”0”という記載がありますので、この「sequence」で囲まれた内容は省略してもよい、つまり、「ex:区域」要素は出現しなくてもよい、ということになります。また、PropertyTypeは属性グループであるgml:AssociationAttributeGroupを呼び出しています（attributeGroup ref=”gml:AssociationAttributeGroup”）。
GMLでは、地物や幾何形状のような、識別可能なオブジェクトは、gml:id属性を持つことができ、これはXMLデータファイルの中でユニークな識別子になります。このgml:AssociationAttributeGroupという属性グループは、gml:idを参照する仕組みであり、参照にはxlink:hrefという属性を使用します。xlink:hrefは、XLinkというXMLデータ間のリンクを定義するためのW3Cが定めた仕様（接頭辞xlink）です。
マッピングルール1 要素宣言をします。要素宣言は、直接又は間接的にgml:_GMLのsubstitutionGroupとなります。
ステレオタイプが<<Type>>となるクラスは、要素宣言をします。要素名はクラス名と一致させることを基本とします。
<<Type>>となるクラスは、地物ではありませんが、他と区別することができる識別子を持ちます。そこで、GMLの中で識別可能な要素として定義されているgml:_GMLのsubstitutionGroupであると指定します。これにより、新しく定義したクラスも識別可能であるということを意味します。
なお、このクラスが別の<<Type>>となるクラスを継承している場合は、「substitutionGroup=”接頭辞:継承するクラスの要素の名前”」と記述します。
図4-6に例を示します。「境界」というクラスを<<Type>>として定義しています。要素宣言を行い、名前にクラス名を使用しています（name=”境界”）。また、substitutionGroupにgml:_GMLを指定しています。
図 4‑6 <<Type>>クラスの要素宣言の例
マッピングルール2 複合型を作成します。複合型は、直接又は間接的にgml:AbstractGMLTypeを拡張（extension）します。
ステレオタイプが<<Type>>となるクラスは、複合型宣言をします。
このとき複合型の名前は、「要素名+Type」とします。そして、識別可能なオブジェクトの複合型であるgml:AbstractGMLTypeを拡張（extension）します。gml:AbstractGMLTypeには、識別子であるgml:idが定義されています。<<Type>>となるクラスは、このgml:AbstractGMLTypeを拡張して作成しますので、gml:idを持つことになります。
複合型の内容にはクラスに定義された属性や関連役割の要素宣言を記述します（図4-7）。
図 4‑7 <<Type>>クラスの複合型宣言の例
宣言した複合型は、要素の型として使用します。宣言した複合型を使用する場合には、複合型には接頭辞が必要です。
マッピングルール3 抽象クラスは、要素及び複合型のabstract属性の値を“true”とします。
<<FeatureType>>のクラスと同様に、抽象クラスの場合は、要素及び複合型の宣言に「abstract=”true”」を記載します。
マッピングルール4 PropertyTypeを作成する。
<<FeatureType>>クラスと同様に、<<Type>>クラスはID参照のための複合型を作成します。複合型の名前は、「要素名＋PropertyType」とします。
マッピングルール1 要素宣言をします。
ステレオタイプが<<DataType>>となるクラスは、要素宣言をします。要素名はクラス名と一致させることを基本とします（図4-8）。
図 4‑8 <<DataType>>クラスの要素宣言の例
マッピングルール2 複合型を作成します。
ステレオタイプが<<DataType>>となるクラスは、複合型宣言をします。
このとき複合型の名前は、「要素名+Type」とします。
複合型の内容にはクラスに定義された属性や関連役割の要素宣言を記述します（図4-9）。
図 4‑9 <<DataType>>クラスの複合型宣言の例
宣言した複合型は、要素の型として使用します。宣言した複合型を使用する場合には、複合型には接頭辞が必要です。
マッピングルール3 抽象クラスは、要素及び複合型のabstract属性の値を“true”とします。
<<FeatureType>>のクラスと同様に、抽象クラスの場合は、要素及び複合型の宣言に「abstract=true」を記載します。
マッピングルール4 PropertyTypeを作成する。
<<DataType>>クラスも、PropertyTypeを作成します。ただし、<<DataType>>クラスは地物の部品として使用するのみであり、識別をしませんのでIDは持ちません。よって、PropertyTypeについてもID参照のため仕組みは持たず、当該要素の出現を許可する記述のみを行います。
図4-10に<<DataType>>クラスの場合に作成するPropertyTypeのXMLスキーマの例を示します。
図 4‑10 PropertyTypeの例
<<FeatureType>>、<<Type>>そして<<DataType>>は、必ず要素宣言を行います。これにより、クラス名がXMLデータの中でタグとして出現することになります。また、各クラスの複合型を宣言します。詳細は後述しますが、この複合型の中に地物の属性や関連役割に該当する要素宣言を行うことで、クラス名を親要素として、属性名や関連役割名を子要素として記述する入れ子構造でデータを記述できるようになります。
<<FeatureType>>、<<Type>>そして<<DataType>>それぞれのXMLスキーマの大きな違いは、<<FeatureType>>と<<Type>>はID（gml:id）を、持つことであり、<<DataType>>はIDを持たないことです。
また、<<FeatureType>>と<<Type>>の違いは、<<FeatureType>>は地物ですので、CityGMLで「地物」を意味する要素であるcore:_CityObjectと複合型であるcore:AbstractCityObjectを使って要素と複合型をそれぞれ定義しますが、<<Type>>は地物ではないので、これらを使わずに定義することです。
UMLクラス図に定義されたクラスの属性は、クラスの複合型の中で要素として宣言されます。このとき、属性の型によってマッピングルールが異なります。
基本的な型とは、文字列型（xs:string）や整数型（xs:integer）、コード型（gml:CodeType）のような型です。基本的な型には、表4-2に示すものがあります。詳細は、「GIS標準データモデルのチュートリアル」を参照してください。
表 4‑2 基本的な型
クラスの属性の型が基本的な型である場合は、クラスの複合型宣言の中で要素として宣言します。
要素の名前は、UMLクラス図の属性名と一致させることを基本とします。また、要素の型にはUMLクラス図の属性の型を指定します。UMLクラス図に多重度が記載されている場合は、多重度に対応するminOccursとmaxOccursを指定します。
図4-11に例を示します。
図 4‑11 基本的な属性のXMLスキーマ
「階段型」クラスには、2つの属性が定義されており、いずれも整数型（xs:integer）です。これら2つに対応する要素宣言を、「階数型」クラスに対応する複合型（階数型Type）の中で行います。要素の名前には属性名である「地上階数」と「地下階数」をそれぞれ指定します。要素の型には、属性の型であるxs:integerを指定します。「地上階数」はUMLクラス図では多重度の記載が省略されていますので、必ず1となります。XMLスキーマでも1の場合は記述を省略可能です。一方、「地下階数」はUMLクラス図では多重度が[0..1]となっています。そこで、XMLスキーマでは「minOccurs=”0”」と記述します。
クラスの属性の型が他のクラスである場合も、クラスの複合型の中で要素として宣言します。
要素の名前は、UMLクラス図の属性名と一致させることを基本とします。属性の型が<<DataType>>クラスや<<Type>>クラスのようにクラスとして定義されている場合は、要素の型として、そのクラスのPropertyTypeを指定します。また、UMLクラス図に多重度に対応するminOccursとmaxOccursを指定します。
図4-12に例を示します。
図 4‑12 属性の型がクラスの場合のXMLスキーマ
「建物」クラスには2つの属性が定義されています。「用途」と「階数」です。このうち、属性「用途」の型は「gml:CodeType」であり、これは基本的な型です。一方、属性「階数」の型は「階段型」であり、これは<<DataType>>クラスとして定義されています。
この「建物」クラスに対応するXMLスキーマを、UMLクラス図の右側に示しています。「建物」クラスの複合型である「建物Type」の中では、UMLクラス図の属性に対応する「用途」と「階数」がそれぞれ要素として宣言されています。「階数」の要素の型には「階数型PropertyType」を指定します。
「階数型PropertyType」のXMLスキーマ（図4-10）に従うと、XMLデータには必ず「階数型」の要素が出現しなければなりません。図4-12に示す複合型を型としても持つ要素「建物」のXMLデータを図4-13に示します。
図 4‑13 属性の型がクラスの場合のXMLスキーマ
このように、UMLクラス図において属性の型として別のクラスが指定されている場合は、XMLスキーマではそのPropertyTypeを指定します。
UMLクラス図でのクラスとクラスの関連には、対等な関係である「関連」、全体と部品の関係である「集成」、さらに、全体と部品の強い関係である「合成」があります。これらいずれのクラス間の関連も、クラスの複合型宣言の中で要素として宣言します。
このとき、要素の名前として使用するのは、関連役割名です。要素の型として、関連相手クラスのPropertyTypeを指定します。また、UMLクラス図に多重度に対応するminOccursとmaxOccursを指定します。このとき、要素名に使用する関連役割名も、関連相手クラスの役割名になることに注意してください。
図4-14に例を示します。
図 4‑14 関連役割のXMLスキーマ
「建物」クラスと「出入口」クラスが、集成により関連付けられており、「出入口」の関連役割名は「出入り」です。この場合、「建物」クラスの複合型宣言には、関連相手先である「出入口」クラスの関連役割名「出入り」を要素名とする要素宣言が含まれます。そしてこの要素の型は、「出入口」クラスに対応するPropertyTypeを指定します。また、多重度はUMLクラス図では[1..*]となっていますので、「maxOccurs=”unbounded”」と指定します。
なお、この集成は、「建物」クラスから「出入口」クラスへの片方向になっています。そのため、「建物」クラスから「出入口」クラスを参照できますが、「出入口」クラスから「建物」クラスは参照できません。よって、これに対応するXMLスキーマでも、「建物」クラスに対応する複合型宣言には、「出入口」クラスを参照するためのPropertyTypeを型とする要素を宣言しますが、「出入口」クラスに対応する複合型宣言には、「建物」クラスを参照するための要素宣言は行いません。
この関連役割名を使用したマッピングルールは、「関連」、「集成」及び「合成」のいずれでも同じです。そのため、XMLスキーマ上は同じになってしまいます。ただし、「関連」の場合は、IDによる参照、「合成」の場合は要素の呼び出し、「集成」の場合は、IDによる参照または要素の呼び出しのいずれも可というように、XMLデータを記述するときに使い分けます。
XMLデータでIDによる参照を行う場合と要素の呼び出しを行う場合との比較をしてみましょう。
図4-15はIDを参照する場合の例です。
図 4‑15 関連役割のXMLデータ（参照する場合）
この場合、「建物」のXMLデータと「出入口」のXMLデータはそれぞれ独立して存在します。「建物」と「出入口」は地物ですので、それぞれ識別子であるgml:idを持ちます。XMLデータは「建物」のXMLデータの中には、「出入り」というタグの属性としてxlink:href属性を記述し、その値として、参照する「出入口」のXMLデータのgml:idを、「#」を付けて記述します。「#」はIDを参照しているという意味です。
「建物」のXMLデータは、「出入口」のXMLデータを参照していますが、「建物」のXMLデータと「出入口」のXMLデータは独立して存在していますので、「建物」のXMLデータを削除したとしても、「出入口」のXMLデータは残ることになります。
このようなIDを参照する方法は、「関連」と、「集成」のうちIDを参照する場合に使用します。
図4-16は要素を呼び出す場合の例です。
図 4‑16 関連役割のXMLデータ（要素を呼び出す場合）
この場合、「建物」のXMLデータの子要素として「出入口」のXMLデータが存在します。「建物」と「出入口」は地物ですので、それぞれ識別子であるgml:idを持ちますが、関連役割に対応する「出入り」の子要素として、「出入口」のデータを直接記述します。
「出入口」のXMLデータは、「建物」のXMLデータの子要素として記述しますので、「建物」のXMLデータを削除すると、「出入口」のXMLデータも削除されることになります。
このような要素を呼び出す方法は、「合成」と、「集成」のうち要素を呼び出す場合に使用します。
UMLクラス図の継承は、継承により作成した特化クラス（下位クラス）の要素宣言と複合型宣言にそれぞれ反映します。
継承により作成した特化クラス（下位クラス）の要素宣言では、substitutionGroup属性に継承元となる汎化クラス（上位クラス）に対応する要素を指定します。また、複合型宣言では、extensionを用いて、base属性に継承元となる汎化クラス（上位クラス）に対応する複合型を指定します。
図4-17に例を示します。
図 4‑17 継承のXMLスキーマ
「地下街」クラスは「建物」クラスを継承しています。そこで、「地下街」クラスの要素宣言では、「建物」クラスの要素をsubstitutionGroup属性に指定します。また、「地下街」クラスの複合型宣言では、「建物」クラスの複合型をextensionのbase属性に指定します。
substitutionGroup属性とextensionの記述がどのようにXMLデータに影響するか、図4-18のようなUMLクラス図を例に見てみましょう。このUMLクラス図では、「建物」クラスを継承して「地下街」クラスが定義され、また、「人」クラスが「建物」クラスと集成により関連付けられています。
図 4‑18 継承のXMLスキーマ
このUMLクラス図に従うと、「人」は「建物」を「所有物」として参照することができます。このとき、「地下街」は「建物」を継承していますので、「人」は「地下街」も「所有物」として参照することができます。
ここで、「人」クラスの複合型宣言とこれを型とする要素宣言、「建物PropertyType」の複合型宣言を示します（図4-19）。
図 4‑19 「人」クラスの複合型宣言
「人」クラスの複合型宣言には、関連役割名（「所有物」）が要素名となった要素宣言が含まれ、その型には関連相手先クラスである「建物」のID参照の仕組みである「建物PropertyType」が指定されることになります。
図4-19に「建物PropertyType」の複合型宣言も示しています。この複合型は建物の要素を呼び出す「element ref=”ex:建物”」の記述を含みます。ここで、「地下街」の要素宣言では、「建物」のsubstitutionGroupであると宣言しています。これは、「地下街」も「建物」の要素の代わりに出現できるという意味です。そのため、「element ref=”ex:建物”」は、「建物」の要素だけではなく、このsubstitutionGroupである「地下街」も要素として呼び出すことができます。
結果として、XMLスキーマでも、「地下街」を「建物」として取り扱うことができ、UMLクラス図における継承の概念（「人」は「建物」だけではなく、「建物」を継承する「地下街」を「所有物」とすることができる）をXMLデータに反映することができます。
次に、extensionした結果を見てみましょう。図4-20に「地下街」クラスに対応する複合型宣言とこれを型とする要素宣言を示します。
図 4‑20 「地下街」クラスのXMLスキーマとXMLデータの例
「地下街」クラスは、「建物」クラスを継承していますので、複合型宣言では、「建物」クラスに対応する複合型である「建物Type」をbase属性に指定して拡張（extension）します。
「地下街Type」を型として指定した要素である「地下街」のXMLデータを見てみましょう。「地下街」の子要素として出現するのは、拡張元となる「建物Type」に定義された要素（「名前」「完成年」「階数」）に加え、「地下街」クラスに定義された属性「地下鉄駅有無」に対応する要素です。このとき、先に出現するのは拡張元となる複合型に定義された要素であり、自身に定義された要素は後ろに追加されることに注意してください。
最後に「人」が「地下街」を所有している場合のXMLデータを図4-21に示します。図の通り、「人」の「所有物」という属性として、「地下街」の要素が出現しています。
図 4‑21 「人」が「地下街」を所有している場合のXMLデータ
パッケージには、XMLスキーマのファイルが対応します。パッケージごとにXMLスキーマを作成します。
パッケージ間の関係は、importやincludeに対応します。import又はincludeを用いて、依存するパッケージに対応するXMLスキーマに定義された要素や型を使用できるようにします。
例えば、3.2節で説明したように、GMLでは点、線、面といった幾何形状を表す要素や型を定義しています。データモデルに幾何形状を使用している場合には、GMLのXMLスキーマをimportしなければなりません。importすることにより、GMLが定義する幾何形状の要素や型を使用できるようになります（図4-22）。
図 4‑22 データモデルとXMLスキーマとの関係
パッケージには名前空間と接頭辞を設定します。このパッケージの中で定義するクラスに対応する要素や複合型を別の場所で使用するときには、接頭辞を付けて使用します。
3D都市モデルのデータモデルは、CityGMLとi-URに定義されたデータモデルから、必要なクラスやクラス間の関係を抽出したプロファイルであり、独自にクラスや属性あるいは関係を追加していません。そのため、XMLスキーマも、CityGMLとi-UR、また、これらが使用しているGMLで定義されているXMLスキーマを使用しています。
本節では、3D都市モデルが使用しているXMLスキーマを、土地利用を事例にUMLクラス図と対応付けて解説します。
CityGMLのデータモデルにはBuilding（建築物）やLandUse（土地利用）といった都市空間を構成する基本的な地物がクラスとして定義され、それぞれのクラスには、基本的な属性も定義されています。また、各地物のクラスはLOD別に幾何形状を表すクラスとの関連が定義されています。CityGMLのXMLスキーマは、このUMLクラス図に対応する符号化仕様です。
XMLスキーマはパッケージごとに作成されます。ここでは、土地利用（LandUse）パッケージに定義された土地利用（LandUse、接頭辞：luse）のUMLクラス図を参考に、CityGMLのXMLスキーマを見てみましょう。
まず、図4-23にLansUseクラスのUMLクラス図を示します。
図 4‑23 LandUseのUMLクラス図（出典：CityGML 2.0）
LandUseは、CityGMLに定義された地物の抽象概念であるcore::_CityObjectを継承しています。また、自身にはclass、function、usageの3つの属性が定義されています。さらに、面の集まりであるgml::MultiSurfaceと関連付いています。関連は、LOD0からLOD4の5段階に対応する計5つの関連が定義されています。
このUMLクラス図に対応するXMLスキーマ（図4-24）を見てみましょう。
図 4‑24 LandUseのXMLスキーマ
LandUseは地物ですので、要素宣言と複合型宣言を行います。要素宣言では、core:_CityObjectのsubstitutionGroupとして指定し、複合型宣言では、core:AbstractCityObjectTypeを拡張します。
LandUseクラスに定義された属性は、複合型宣言の中でそれぞれ要素宣言されます。同様に関連役割も要素宣言されます。関連役割では、関連相手クラスであるMultiSurfaceのPropertyTypeを要素の型として指定します。
なお、LandUseクラスの複合型宣言の中では、属性と関連役割に対応する要素宣言以外に、_GenericApplicationPropertyOfLandUseという要素が呼び出されています。これは、ADE（Application Domain Extension）という拡張の仕組みを使用するための要素です。
_GenericApplicationPropertyOfLandUseは、抽象（abstract=”true”）の要素であり、その型は何でもよい（type=”xs:anyType”）となっています。LandUseを拡張し、新しい属性や関連役割を追加したい場合には、新しく追加したい属性や関連役割を要素宣言として定義し、この_GenericApplicationPropertyOfLandUseのsubstitutionGroupとすることで、_GenericApplicationPropertyOfLandUseの代わりに、新しく追加した要素が出現できるようになります。これにより、LandUseの子要素として追加した属性や関連役割を記述できます。
このADEによる拡張の仕組みを使用して定義されているのが、次項で説明するi-URのXMLスキーマです。
i-UR（i-Urban Revitalization）は、CityGMLの拡張であるADE（Application Domain Extension）の1つです。
i-URは、都市計画や都市再生に必要なデータの相互流通性を高めるため、CityGMLを拡張した4つのパッケージから構成されています。このうち、3D都市モデルのデータモデルとして利用されているのは、Urban Object（接頭辞：uro）とUrban Function（接頭辞：urf）という2つのパッケージです。
では、i-URにおける土地利用（LandUse）の拡張を参考に、i-URのXMLスキーマを見てみましょう。
まず、図4-25にCityGMLに定義されたLandUseクラスをi-URで拡張したUMLクラス図を示します。ここでは、「LandUseDetailAttribute」というステレオタイプが<<DataType>>となるクラスを定義し、LandUseクラスと合成で関連付けています。
図 4‑25 i-URのUMLクラス図
このUMLクラス図に対応するXMLスキーマを見てみましょう。
まず、図4-26にLandUseDetailAttributeクラスに対応するXMLスキーマを示します。要素宣言と複合型宣言を行いますが、PropertyTypeの記述は<<DataType>>ですので要素の呼び出しのみを行う複合型となります。
図 4‑26 LandUseDetailAttributeのクラスXMLスキーマ
次に、図4-27にLandUseクラスからLandUseDetailAttributeクラスへの関連に対応するXMLスキーマを示します。
図 4‑27 関連役割landUseDetailAttributeのXMLスキーマ
関連役割ですので要素宣言を行います。要素名には、関連役割名であるlandUseDetailAttributeを指定し、型にはLandUseDetailAttributePropertyTypeを指定します。このとき、substitutionGroupには、拡張する仕組みである_GenericApplicationPropertyOfLandUseを指定します。これにより、LandUseクラスの複合型に定義される_GenericApplicationPropertyOfLandUseの代わりにlandUseDetailAttributeを記述できるようになります。
拡張したXMLスキーマに従って作成した土地利用のXMLデータの例を図4-28に示します。
図 4‑28 拡張したLandUseのXMLデータ
LandUseのXMLスキーマは、図4-24を参照してください。複合型LandUseTypeに定義された要素の順序に従って、タグが出現します。また、_GenericApplicationPropertyOfLandUseの位置には、この代替グループであると指定されたlandUseDetailAttributeが出現します。さらに、landUseDetailAttributeの子要素として、LandUseDetailAttributeが出現します。
CityGMLで定義された地物のクラスには、全て_GenericApplicationPropertyOf○○○（○○○にはクラス名が入る）という拡張のための要素が定義されています。ADEで属性や関連役割を追加したい場合には、追加したい属性や関連役割に該当する要素を、そのクラスの_GenericApplicationPropertyOf○○○のsubstitutionGroupとして宣言することで、追加した要素を記述できるようになります。