パッケージはクラスやUMLクラス図をまとめる概念であり、パッケージ図を見ることで、データモデルの大まかな構成を把握できます。
3D都市モデルのデータモデル全体のパッケージ図を見てみましょう（図3-1）。
図 3‑1 3D都市モデルのデータモデルとCityGML及びi-URとの関係
3D都市モデルのデータモデルは、CityGMLとi-URというデータモデルを利用しています。
CityGMLにはBuilding（建築物）やLandUse（土地利用）といった都市空間を構成する基本的な地物がクラスとして定義されています。また、i-URにはCityGMLに定義された地物の詳細な属性や、CityGMLにはない地物がクラスとして定義されています。
また、CityGMLとi-URは、GMLを利用していますが、GMLには、地物を構成する部品となるクラス（例：点、線、面、立体などの幾何形状を表すクラス）が定義されています。
なお、後述しますが、3D都市モデルのデータモデルでは、新しいクラスの定義は行っていません。CityGMLやi-URで定義されたクラスから、使用したいクラスとクラス間の関係のみを抽出し、利用しています。
次に、3D都市モデルのパッケージの中を見てみましょう。3D都市モデルのパッケージの中には、さらに20のパッケージが定義されています（図3-2）。各パッケージには、建築物や交通（道路）のように、ある地物に着目し、その地物に必要な属性や関係を抽出し、抽出した地物や地物の属性、関係性のみを示したUMLクラス図が格納されています。
図 3‑2 3D都市モデルのパッケージ図
CityGMLは、都市空間を構成する基本的な地物とその属性を定義したデータモデルです。Building（建築物）やBridge（橋梁）といった目に見える都市を構成するオブジェクト（具体的なもの）を地物に分類し、それぞれをパッケージに分けて定義しています（図3-3）。
図 3‑3 CityGMLのパッケージ図（出典：CityGML2.0 一部加工）
各パッケージに定義されたクラスには、それぞれどのパッケージで定義されているかがわかるように、接頭辞が付与されます（表3-1）。
表 3‑1 CityGMLの接頭辞
i-UR（i-Urban Revitalization）は、CityGMLの拡張であるADE（Application Domain Extension）の1つです。
i-URは、都市計画や都市再生に必要なデータの相互流通性を高めるため、CityGMLを拡張した4つのパッケージから構成されています。このうち、3D都市モデルのデータモデルとして利用されているのは、Urban ObjectとUrban Functionという2つのパッケージです（図3-4）。
図 3‑4 i-URのパッケージ図
Urban Objectには、CityGMLに定義済の地物を拡張した新たな地物や、地物に付与する詳細な属性が定義されています。例えば、Buildingを拡張して新たにUndergroundBuilding（地下街）という地物を定義したり、Buildingの属性として、「構造種別」や「空き家区分」などの詳細な属性を定義したりしています。
Urban Functionは、CityGMLには定義されていない目に見えない概念的な地物を定義しています。目に見えない概念的な地物とは、例えば、都市計画区域や土砂災害警戒区域が該当します。CityGMLでは、建築物、橋梁、道路といった都市空間を構成する物理的なモノを網羅的に定義していますが、このような概念的な地物は定義していません。一方で、都市計画や都市再生を考える上では、ゾーニングの情報は重要です。そこで、i-URでは概念的な地物を定義するために、Urban Functionパッケージを用意しています。
各パッケージに定義されたクラスには、それぞれどのパッケージで定義されているかがわかるよう接頭辞が付与されています（表3-2）。
表 3‑2 i-URの接頭辞
3D都市モデルのデータモデルは、CityGMLとi-URで定義されたクラスを利用しており、3D都市モデルのデータモデル自体で新しいクラスは定義していません。3D都市モデルのデータモデルに定義されている各パッケージには、CityGMLとi-URから必要なクラスとその関係を抽出したUMLクラス図が格納されています（図3-5）。
図 3‑5 3D都市モデルのデータモデル
3D都市モデルのデータモデルは、20のパッケージから構成されています。次項では、主なパッケージとして、「建築物モデル」、「交通（道路）モデル」及び「都市計画決定情報モデル」を例に、UMLクラス図を解説します。
「建築物モデル」と「交通（道路）モデル」は、CityGMLに定義された地物を表すクラスと、i-URに定義された地物の属性となるクラスを利用しています。「都市計画決定情報」モデルは、CityGMLに該当する地物が定義されていないため、i-URに定義された地物を表すクラスを利用しています。
建築物モデルのデータモデルは、CityGMLのBuildingパッケージとi-URのUrbanObjectパッケージを利用しています。建築物を構成する地物と地物間の関係、地物の形状及び基本的な属性はCityGMLに定義されています。また、i-URには建築物の詳細な属性が定義されています。
建築物モデルのデータモデルは、同じ構造物である橋梁モデル、トンネルモデル及びその他の構造物モデルと似ていますので、建築物モデルのデータモデルを理解できれば、類似する他のデータモデルも理解できるでしょう。
Buildingパッケージには、建築物と、建築物を構成する屋根や外壁、窓といった部品となる地物が定義されています。このうち、建築物を表す地物は、bldg::Buildingです。
bldg::Buildingはbldg::_AbstractBuildingを継承しています（図3-6）。
図 3‑6 bldg::_AbstractBuildingとbldg::BuildingのUMLクラス図
よって、bldg::Buildingもbldg::_AbstractBuildingに定義された属性や関係を持ちます。ここで、bldg::_AbstractBuildingはクラス名が斜体になっていますので、抽象クラスです。そのため、bldg::_AbstractBuildingはデータを作成することはできません。建築物のデータを作成したい場合には、必ずbldg::Buildingを使用しなければなりません。
なお、CityGMLでは、抽象クラスの場合は、そのクラス名称の頭に、_（アンダースコア）を付けています。アンダースコアから始まるクラスがあれば、それは抽象クラスですので、実際にデータを作成することができるのはそれを継承する具象クラスであることに注意してください。
bldg::_AbstractBuildingには、このクラスを全体とする集成の関係が定義されています。集成の関係のみを抜き出したUMLクラス図を図3-7に示します。建築物の部品となるクラスには、以下の5つがあります。
l bldg::BuildingInstallation（付属物）
l bldg::_BoundarySurface（境界面）
l bldg::Room（部屋）
l bldg::IntBuildingInstallation（屋内の付属物）
l bldg::BuildingPart（建築物部分）
図 3‑7 bldg::_AbstractBuildingとその部品となる地物
bldg::BuildingInstallationは、建築物の本体に付けられ、建築物の外観を特徴付ける付属物であり、屋外の階段やバルコニーなどを地物として分けたい場合に使用します。
bldg::_BoundarySurfaceは建築物の立体的な形状を構成する境界面です。bldg::_BoundarySurfaceは抽象クラスですので、データとして作成されるのはこれを継承する以下のクラスになります。
l bldg::RoofSurface（屋根面）
l bldg::OuterCeilingSurface（屋外にある天井面）
l bldg::WallSurface（外壁面）
l bldg::OuterFloorSurface（屋外にある床面）
l bldg::ClosureSurface（閉鎖面）
l bldg::GroundSurface（底面）
l bldg::InteriorWallSurface（内壁面）
l bldg::FloorSurface（床面）
l bldg::CeilingSurface（天井面）
bldg::Roomは部屋です。建築物の屋内を表現する場合に使用します。
bldg::IntBuildingInstallationは、建築物の屋内に存在する付属物です。屋内にある階段やエレベータ等が該当します。
bldg::BuildingPartは、建築物を複数に分けて表現したい場合に使用します。bldg::BuildingPartは、bldg::_AbstractBuildingの部品として集成の関係にありますが、同時にbldg::_AbstractBuildingを継承しています。つまり、bldg::BuildingPartもbldg::_AbstractBuildingに定義された属性や関係を持ちます。bldg::BuildingPartは、高層棟と低層棟のように階数の異なる棟から構成されていたり、商用施設と居住用施設というように用途の異なるエリアから構成されていたりする複雑な建築物において、それぞれを属性として表現しつつ1棟の建築物のデータとして取り扱いたい場合に使用することができます。
なお、CityGMLでは、屋外の表現に使用する地物と、屋内の表現に使用する地物を分けています。そのため、付属物を表現したい場合、屋外にあるものはbldg::BuildingInstallationを使用し、屋内にあるものはbldg::IntBuildingInstallationを使用しなければなりません。境界面も同様です。外壁を表現する場合は、bldg::InteriorWallSurfaceを使用しますが、内壁を表現する場合は、bldg::IntWallSurfaceを使用します。
先ほど、建築物は全体となり、様々な部品となる地物があるという説明をしました。この部品となる地物に、さらに部品が含まれる場合があります。
例えば、建築物の境界面（bldg::_BoundarySurface）は、その部品としてbldg::_Opening（開口部）を持つことができます（図3-8）。
図 3‑8 bldg::_BoundarySurfaceとbldg::_Openingの関係
開口部は、抽象クラスであり、具体的にはbldg::Door（扉）やbldg::Window（窓）となります。bldg::_BoundarySurfaceを継承するbldg::WallSurface（外壁面）やbldg::RoofSurface（屋根面）などは、bldg::Door（扉）やbldg::Window（窓）を部品として持つことができます。つまり、建築物は、外壁などから構成され、その外壁の一部として扉や窓がある、というデータが記述されることになります。
同様にして、部屋（bldg::Room）も見てみましょう（図3-9）。
図 3‑9 bldg::Roomとその部品となる地物
部屋には、部品としてbldg::IntBuildingInstalltion（屋内の付属物）、bldg::BuildingFurniture（家具、設備）及びbldg::_BoundarySurface（境界面）を持つことができます。部屋における境界面とは、bldg::InteriorWall（内壁面）、bldg::FloorSurface（床面）又はbldg::CeilingSurface（天井面）となります。これらの境界面にも窓や扉などの開口部（bldg::_Opening）を設けることができます。
bldg::IntBuildingInstallationやbldg::_BoundarySurfaceは、bldg::_AbstractBuildingとも集成の関係にあります。そのため、これらの地物のデータは、bldg::Buildingの部品として記述される場合と、bldg::Roomの部品として記述される場合があります。
次に、建築物と幾何形状を表現するクラスとの関係を見てみましょう（図3-10）。
図 3‑10 bldg::_AbstractBuildingと幾何形状の関係
CityGMLは、目的に応じて幾何形状の詳細度を変えることのできるLOD（Level of Detail）という仕組みを持っています。この仕組みは、UMLクラス図では、地物のクラスと幾何形状を表すクラスとの関連により表現されています。
例えば、建築物（gml::_AbstractBuilding）の場合は、LOD0は面（gml::MultiSurface）で表現できます。これは、UMLクラス図では、gml::MultiSurfaceへの関連として表現されています。関連役割lod0RoofEdgeとlod0FootPrintがこれに該当します。LOD0の面を屋根の外形を使って表現したい場合は、関連役割lod0RoofEdgeを用いて面のデータを記述します。建築物の外壁の外形を使って表現したい場合は、関連役割lod0FootPrintを用いて面のデータを記述します（図3-11）。
図 3‑11 建築物のLOD0の表現
また、LOD1からLOD4までは、gml::_Solid（立体）で表現できます。これは、UMLクラス図では、gml::_Solidへの関連として表現されています。関連役割lod1Solid、lod2Solid、lod3Solid、lod4Solidがこれに該当します。LOD1からLOD4の建築物の形状を表現したい場合は、それぞれの関連役割を用いて立体のデータを記述します。
さらに、LOD4の場合は、面の集まりとしても記述することができます。これは、UMLクラス図では、gml::MultiSurfaceへの関連として表現されています。関連役割lod4MultiSurfaceがこれに該当します。LOD4の場合は、立体又は面の集まりとして記述することができることがUMLクラス図からわかります。一方、LOD1からLOD3までは、建築物の形状を表現したい場合には、必ず立体で記述しなければなりません。立体と面の集まりの違いについては、3.3.2項で説明します。
このように、地物を表すクラスと幾何形状を表すクラスとの関連がLODごとに定義されていることで、地物は、LOD別の幾何形状のデータを保持することができるようになっています。
同様にして、Buildingパッケージに定義された、bldg::Roomやbldg::_BoundarySurfaceといった部品となる地物も、LODごとに幾何形状を表現するクラスと関連付いています。
例として、bldg::BuildingInstallationを見てみましょう（図3-12）。
図 3‑12 bldg::BuildingInstallationの形状表現
bldg::BuildingInstallationには、lod2Geometry、lod3Geometry、lod4Geometryの3つの関連役割により、gml::_Geometryと対応付いています。gml::_Geometryは抽象クラスであり、実際にはこれを継承する、gml::MultiSurfaceのような具象クラスにより形状がデータとして記述されます。ここで、bldg::BuildingInstallationは、LOD2からLOD4までのLODに対応付く関連役割しか定義されていません。つまり、LOD0やLOD1ではbldg::BuildingInstallationを表現できません。
このように、地物によっては表現可能なLODが制限されている場合があります。
3D都市モデルでは、地物の形状は、主に立体又は面の集まりとして表現されます。表3-3によく使用される幾何形状を表すクラスを示します。
表 3‑3 地物の幾何形状を表すクラス
次に、建築物モデルで利用されている、i-URに定義されたクラスを見てみましょう。建築物モデルでは、i-URに定義された地物の詳細な属性を表すクラスを利用しています。
例として、uro::BuildingIDAttribute（建物ID属性）とuro::RealEstateIDAttribute（不動産ID属性）を見てみます（図3-13）。これらは、建築物に付与したい属性を束ねたクラスとしてi-URに定義されています。これらのクラスは地物の属性であり、地物そのものではありませんので、ステレオタイプは<<DataType>>となっています。
図 3‑13 建築物モデルで利用している属性を表すデータ型の例
uro::BuildingIDAttributeとuro::RealEstateIDAttributeは、いずれも建築物を識別するための属性です。
l uro::BuildingIDAttributeは、3D都市モデルの中で1棟の建築物を識別するために使用されるため、個々の建築物のデータとして必ず作成しなければならないデータとして位置付けられています。そのため、多重度は、[1]となっています。
l uro::RealEstateAttributeは、ユースケースの必要に応じて付与することができるデータですので、多重度は[0..1]となっています。
さらに、uro::BuildingIDAttributeの属性を見てみると、属性buildingIDとcityは必須（多重度の記述が省略されているため[1]となる）になっています。よって、全ての建築物のデータには、buildingIDとcityは属性として必ず入っていることを意味します。また、uro::RealEstateAttributeの属性を見てみると、属性realEstateIDOfBuilding（不動産ID）は必須となっています。よって、建築物のデータに対して、不動産IDのデータはある場合とない場合がありますが、ある場合には必ずrealEstateIDOfBuildingが属性として入っていることを意味します。
このように、CityGMLで定義された地物に対して詳細な属性を付与するためのクラスが、3D都市モデルのデータモデルとして利用されています。ほかにも、都市計画基礎調査の建物利用現況のデータを格納するためのuro::BuildingDetailAttributeや、浸水想定区域図などをもとに建築物の災害リスクを計算した結果を格納するためのuro::DisasterRiskAttributeなどの属性を表すクラスが含まれています。
交通（道路）モデルのデータモデルは、CityGMLのTransportationパッケージとi-URのUrbanObjectパッケージを利用しています。道路を構成する地物と地物間の関係、地物の形状及び基本的な属性はCityGMLに定義されています。また、i-URには道路の詳細な属性が定義されています。
交通（道路）モデルのデータモデルは、同じく交通に関する地物である交通（鉄道）モデル、交通（徒歩道）モデル、交通（広場）モデル及び交通（航路）モデルと似ていますので、交通（道路）モデルのデータモデルを理解できれば、類似する他のデータモデルも理解できるでしょう。
Transportationパッケージには、道路と、道路を構成する歩道や車道といった部品となる地物が定義されています。このうち、道路を表す地物は、tran::Roadです。
tran::Roadは、tran::TrafficComplexを継承しています（図3-14）。よって、tran::Roadもtran::TrafficComplexに定義された属性や関係を持ちます。
図 3‑14 tran::RoadのUMLクラス図
tran::TrafficComplexには、このクラスを全体とする集成の関係が定義されています。tran::TrafficComplexの部品となるクラスには、以下の2つがあります。
l tran::TrafficArea（交通領域）
l tran::AuxiliaryTrafficArea（交通補助領域）
tran::TrafficAreaは、通行に使用される領域を指します。道路の場合は、車道や歩道がこれに該当します。tran::AuxiliaryTrafficAreaは、通行に使用される領域を保護する役割を持つ領域を指します。道路の場合は、路肩や植樹帯がこれに該当します。
CityGMLでは、歩道や車道、車線といった地物を表すクラスは定義されておらず、tran::TrafficAreaやtran::AuxiliaryTrafficAreaといった汎用的な地物として定義されています。歩道や車道、車線といった区別は、この地物に定義された属性tran::class、tran::function及びtran::usageを使って行うことになっています。地物の細分をどのように行うかはCityGMLでは定義されておらず、このデータモデルを利用する人が自由に決めることができます。
3D都市モデルのデータモデルでは、独自に細分をコードリストとして定めています。細分を定めることができる属性は、属性の型がgml::CodeTypeになっています。コードリストにどのような値が定義されているかは、3D都市モデル標準製品仕様書の中に示されています。
次に、道路と幾何形状を表現するクラスとの関係を見てみましょう（図3-15）。
図 3‑15 tran::Roadと幾何形状の関係
CityGMLは、目的に応じて幾何形状の詳細度を変えることのできるLOD（Level of Detail）という仕組みを持っています。この仕組みは、UMLクラス図では、地物のクラスと幾何形状を表すクラスとの関連により表現されています。
道路を表すtran::Roadには、幾何形状との関連が定義されていませんが、tran::Roadが継承するtran::TrafficComplexには幾何形状との関連が定義されています。つまり、tran::Roadもこの関連を継承しています。
tran::TrafficComplexには、LOD0からLOD3までの4段階の幾何形状との関連を持っています。
LOD0は線の集まりとして表現できます。これは、UMLクラス図では、gml::GeometricComplexへの関連として表現されています。関連役割lod0Networkがこれに該当します。gml::GeometricComplexは3.3.2項で説明しますが、幾何形状の集まりであり、ここでは線の集まりを意味します。
また、LOD1からLOD3までは、gml::MultiSurface（面の集まり）で表現できます。これは、UMLクラス図では、gml::MultiSurfaceへの関連として表現されています。関連役割lod1MultiSurface、lod2MultiSurface、lod3MultiSurfaceがこれに該当します。LOD1からLOD3の道路の形状を表現したい場合は、それぞれの関連役割を用いて面の集まりのデータを記述します。
このように、地物を表すクラスと幾何形状を表すクラスとの関連がLODごとに定義されていることで、地物は、LOD別の幾何形状のデータを保持することができるようになっています。
同様にして、tran::TrafficAreaやtran::AuxiliaryTrafficAreaといった部品となる地物も、LODごとに幾何形状を表現するクラスと関連付いています。
tran::TrafficAreaとtran::AuxiliaryTrafficAreaもgml::MultiSurfaceと関連付いていますが、関連役割はlod2MultiSurfaceとlod3MultiSurfaceの2つのみです。つまり、LOD0やLOD1ではtran::TrafficAreaとtran::AuxiliaryTrafficAreaを表現できません。
すなわち、LOD0からLOD3までの道路の形状表現は、以下のようになります。
l LOD0：道路ネットワーク
l LOD1：道路の面
l LOD2、LOD3：歩道の面や車道の面の集まりとしての道路の面
3D都市モデルでは、LOD0は道路を線で表現し、LOD1では道路を面として表現します。このLOD1では歩道や車道の区別はできません。LOD2とLOD3では、道路の中を車道や歩道として細分することができ、細分された歩道や車道がそれぞれ面として表現され、その集まりとして道路全体を面として表現できます。
なお、3D都市モデルでは、LOD2とLOD3の区別として、歩道や車道の区分など、道路内部の区分の詳細度を変えています。例えば、LOD2では、歩道と車道の区別のみ、LOD3では車道を車線に細分することができます。どのような細分が可能かは、3D都市モデル標準製品仕様書を参照してください。
CityGMLは鉄道や徒歩道といった、その他の交通に関する地物も道路と同様に、tran::TrafficComplexを継承して定義されています。そのため、これらの地物についてのモデルも道路と同様のデータ構造を持ちます。
次に、交通（道路）モデルで利用されている、i-URに定義されたクラスを見てみましょう。交通（道路）モデルでは、i-URに定義された地物の詳細な属性を表すクラスを利用しています。
例として、uro::TrafficVolumeAttribute（交通量属性）とuro::RoadStructureAttribute（道路構造属性）を見てみます（図3-16）。これらは、道路に付与したい属性を束ねたクラスとしてi-URに定義されています。これらのクラスは地物の属性であり、地物そのものではありませんので、ステレオタイプは<<DataType>>となっています。
図 3‑16 交通（道路）モデルで利用している属性を表すデータ型の例
uro::TrafficVolumeAttributeは道路の交通量に関する情報を格納するためのクラスです。一方、uro::RoadStructureAttributeは、幅員や車線数など、道路構造に関する情報を格納するためのクラスです。これらの情報は、都市計画基礎調査のデータ項目である「C0502 道路の状況」や「C0601 主要な幹線の断面交通量・混雑度・旅行速度」において調査されます。ただし、これらのデータ項目は全ての都市において調査が実施されているわけではありません。また、道路の規模によっては調査対象外となる場合があります。そのため、道路に対して必ず付与できる情報とは限りませんので、多重度は[0..1]となっています。
都市計画決定情報モデルのデータモデルは、i-URのUrbanFunctionパッケージを利用しています。都市計画区域や用途地域といった区域は、CityGMLには定義されていません。そのため、i-URでは、UrbanFunctionパッケージの中にこれらの地物をクラスとして定義しています。
UrbanFunctionパッケージには、都市計画区域や用途地域といった概念的な地物が定義されています。図3-17にUrbanFunctionパッケージの概要を示します。
図 3‑17 urf::_UrbanFunctionとurf::UrbanPlanningArea
urf::_UrbanFunctionは、UrbanFunctionパッケージでもっとも抽象度の高い汎化クラスです。このクラスは、CityGMLで定義されたクラスの中でもっとも抽象度の高いクラスである、core::_CityObjectを継承して定義されています。UrbanFunctionパッケージに定義される各地物は、urf::_UrbanFunctionというクラスを継承して定義されます。
例えば、urf::Zoneは、法令で定められた区域を示すクラスです。都市計画の各区域は、都市計画法をはじめとする関連法令で定められた区域ですので、このurf::Zoneを継承して定義されています。例えば、urf::UrbanPlanningAreaは都市計画区域を表すクラスです。都市計画決定情報モデルでは、都市計画関連法令で定められた各区域がクラスとして含まれています。また、各クラスに定義された属性は、根拠となる法令でその区域に関して都市計画で「定めるべき事項」や「定めることが望ましい事項」に該当します。
そのため、都市計画図書に含まれる各種の情報をデータ化したい場合は、対応するクラスやその属性を使用して記述することができます。
最後に、CityGMLとi-URが参照するGMLのデータモデルを紹介します。
GMLは、Geography Markup Language（地理マーク付け言語）の略であり、地理空間データをXML形式で記述するための言語です。GMLのデータモデルは、地理空間情報に関する国際標準であるISO19100シリーズにおいて定められています。特に、幾何形状のデータモデルは、ISO 19107（空間スキーマ）において定められています。幾何形状とは図形のことであり、点、線、面、そして立体があります（表3-4）。3D都市モデルでは、主に、面と立体を使って地物の幾何形状を表現しますが、立体は面から構成され、面は線から構成され、線は点から構成されるというように、それぞれの幾何形状は関連付いています。
表 3‑4 幾何形状の例
空間スキーマでは、様々な幾何形状をクラスとして定義していますが、CityGMLではその中から使用するクラスのみを矛盾なく抽出して使用しています。
この節では、CityGMLで使用している幾何形状のクラスを紹介します。
なお、幾何形状の詳細については、標準作業手順書のAnnex Bに詳解していますので、参考にしてください。
基本となる幾何形状は、点（gml:Point）、折れ線（gml:LineString）、多角形（gml:Polygon）及び立体（gml:Solid）です（図3-18）。
図 3‑18 基本となる幾何形状
点を表すgml:Pointは、1つの属性positionを持っています。属性positionの型はgml:DirectPositionであり、これは座標を指します。3D都市モデルの場合には、原則として、緯度経度と標高により座標を記述します。
折れ線を表すgml:LineStringは、1つの属性positionを持っています。属性positionの型は点と同様、座標を指すgml:DirectPositionです。多重度が[2..*]となっていますので、折れ線は2つ以上の座標から構成されていることがわかります。gml:LineStringは、最小で始点と終点の2つの座標を持ち、その間の中間点をいくつでも持つことができます。gml:LineStringの属性positionは、始点から終点に向かう順序で座標が並ばなければなりません。また、gml:LineStringは折れ線ですので、点と点との間を直線で結びます。
多角形を表すgml:Polygonは属性を持っていませんが、他のクラスとの関連を持っています（図3-19）。
図 3‑19 面の構造
他のクラスとの関連は、多角形の外周と内周を表します。gml:Polygonは、外周（exterior）を必ず1つ持たなければなりません。また、ドーナツ型の図形の場合には内周（interior）を持つことができます。内周は持つこともできますが、持たなくてもかまいません。また、内周を持つ場合には複数持つことができます。
外周と内周は、gml:Polygonが関連する相手であるgml:_Ringにより表現します。gml:_Ringは、輪です。輪とは、始点と終点が一致する線です。gml:_Ringは抽象クラスであり、これを継承するgml:LinearRingを用いてデータが作成されます。gml:LinearRingには属性positionが定義されています。属性の型は座標を示すgml:DirectPositionです。この多重度は[4..*]です。つまり、gml:LinearRingは、4点以上の座標から構成される輪です。gml:LinearRingは、始点と終点は必ず同じ座標でなければならず、始点から終点に向かって各点を直線でつないで輪を構成します。例えば、4点の場合は三角形となり、5点の場合は四角形となります。
gml:Polygonにはいくつかのルールがあり、これを満たさないgml:Polygonのデータはエラーとなります（図3-20）。
図 3‑20 正しいgml:Polygonと誤ったgml:Polygon
例えば、内周を持つ場合、必ず、内周は外周に包含されていなければなりません。また、内周が外周と接していてもかまいませんが、接することにより多角形を分断してはなりません。また、内周の内側にさらに内周を設け島のような部分を作ることは許されません。さらに、外周や内周は、それぞれが自己交差したり、始点と終点以外の点で一致したりすることも許されません。
さらに、gml:Polygonの外周と内周を構成する点の順序は、必ず多角形の内側を左に見る順序でなければなりません（図3-21）。
図 3‑21 gml:Polygonを構成する点の順序
立体を表すgml:Solidも属性を持っていませんが、他のクラスとの関連を持っています（図3-22）。
図 3‑22 立体の構造
立体はその境界面を記述することで表現します。立体の外側を構成する面は関連役割exteriorにより立体と関連付けられます。また、立体も内空を持つことができます。この内空の境界を構成する面は関連役割interiorにより関連付けられます。外側の境界（exterior）は必ず持たなければならず、多重度は[1]です。内側の境界（interior）は持っても持たなくてもよく、また複数持ってもよいため、多重度は[0..*]です。
ここで、立体の外側と内側の境界面を表すクラスは、gml:_Surfaceを継承したgml:CompositeSurfaceにより表現されます。gml:CompositeSurfaceについては、3.3.2項で説明します。
gml:Point（点）、gml:LineString（折れ線）、gml:Polygon（多角形）、gml:Solid（立体）は単純な幾何形状を表すクラスです。空間スキーマには、点の集まり、線の集まり、面の集まりといった複合的な幾何形状を表すクラスが用意されています。ここでは、3D都市モデルでよく使用される面の集まりについて説明します。
gml:MultiSurfaceは、面の集まりを表すクラスです（図3-23）。
図 3‑23 面の集まりの構造
関連役割surfaceMemberにより複数の面を集めます。gml:MultiSurfaceに含まれるgml:Polygonは単純な多角形ですが、これを組み合わせることで立体的な凹凸を持つ複雑な形状を表現できます。
gml:MultiSurfaceは面の集まりを表すクラスですが、これを構成する個々の面が、重なっていても、離れていてもかまいません（図3-24）。
図 3‑24 重なっている面と離れている面の例
一方、ISO 19107では、立体の境界となる面に、隙間や重なりがあってはならない、というルールがあります。そのため、立体の境界となる面の記述には、隙間や重なりを許容しない面の集まりである、gml:CompositeSurfaceを使用します（図3-25）。
図 3‑25 立体の境界となる面の集まりの構造
立体（gml:Solid）と面の集まり（gml:MultiSurface）の概念を図3-26に示します。
図 3‑26 立体（gml:Solid）と面の集まり（gml:MultiSurface）の概念図
gml:CompositeSurfaceは、関連役割surfaceMemberにより構成要素となる面（gml:_Surface）と関連付きます。gml:_Surfaceは抽象クラスですので、これを継承する具象クラス（例：gml:Polygon）と関連付きます。データを作成する場合、gml:CompositeSurfaceを構成する各面は、お互いに重なったり、離れたりしていてはなりません。また、面の法線方向が同じでなければなりません。面の法線方向とは、面に対して垂直の方向をいいます。このとき面には表と裏がありますが、面の外周を構成する点の順序が左回りになる側の面に垂直な線を法線方向としています（図3-27）。
図 3‑27 gml:CompositeSurface
先ほど、立体の境界を構成する面には隙間や重なりがあってはならない、というルールがあると説明しました。加えて、この境界面の法線方向が同じでなければなりません。立体の外側を構成する面の法線方向は、立体の外側を向いていなければなりません（図3-28）。これは、ISO 19107で定められたルールであり、このルールがあることにより、ある点が立体の内部にあるのか、外部にあるのかといった判定などが容易になります。
図 3‑28 立体の外側を構成する境界面の法線方向
立体の外側を構成する境界面となるgml:CompositeSurfaceは、立体の外側を向く法線方向の面、かつ、互いに重なったり離れたりしない面の集まりとなります。
なお、gml:_Surfaceを継承するgml:OrientableSurfaceは、ある面の反対向きの面を作成するためのクラスです。gml:OrientableSurfaceは、関連役割baseSurfaceにより、gml:_Surfaceを参照します。具体的には、gml:_Surfaceを継承するgml:Polygonを参照します。gml:OrientableSurfaceは、参照するgml:Polygonと反対向きの面を表します。そのため、gml:OrientableSurface自体は、直接的に外周や内周といった形状を構成する座標の情報は持ちません。このとき、gml:OrientableSurfaceの属性orientation（向き）の値は－（マイナス）の値をとります。
この反対向きの面であるgml:OrientableSurfaceは、隣り合う立体が同じ面を境界として共有したい場合に使用します。例えば図3-29では、Solid1とSolid2という隣り合う2つの立体がある場合、2つの立体が接する面はそれぞれの立体の境界面となります。ただし、立体の外側の面は、必ず立体の外側を向く法線方向でなければなりません。そのため、境界として存在する面（Poly1）を、そのままSolid2の境界面として使用できません。このような場合に、Poly1の反対向きの面であるOrientableSurface1を作成し、これをSolid2の境界面となるgml:CompositeSurfaceの構成要素として使用します。
図 3‑29 gml:Polygonとgml:OrientableSurfaceとの関係