CityGML Overview

From SIMSTADT
Jump to: navigation, search

CityGML is the OGC standard for modelling of virtual 3D City models: OGC City Geography Markup Language (CityGML) Encoding Standard . It comes with so-called XML-Schema files which more or less strictly define the modelling of the virtual city objects. Based on this schema files an automatic validation of the modelled city objects is possible.

It is both a data format and an information model. The CityGML information model specifies how objects of a city have to be modelled. Each CityObject can consist of attributes and geometry in different resolutions (Level of Detail concept). The CityObjects are stored in XML-based/GML-based files (*.xml or *.gml).

Contents

[edit] CityGML modules

In CityGML, the city is semantically "split" into different modules to represent real world objects:

  • CityGML core - fundamental objects auch as geometry, used by all modules
  • Appearance - visual attributes auch as texture and material
  • Brigde - new in CityGML 2.0
  • Building
  • CityFurniture - small objects along the street, auch as trashbin, bank
  • CityObjectGroup - to group city objects
  • Generics - if it does not fit into any other category
  • LandUse
  • Relief - the terrain
  • Transportation - streets, etc.
  • Tunnel - new in CityGML 2.0
  • Vegetaion - Trees, Bushes, and the like
  • WaterBody - lakes and rivers


Please note that a software that can work with CityGML does not necessarly need to support all existing modules. The following table shows a survey of tools and supported modules.
[TODO] Falls jemand einmal Software testen möchte, wir haben fast alle Systeme im Hause.

CityGML-Module.png

[edit] CityObject

The following figure shows an UML diagram of the CityGML's top level class hierachy. A CityModel is a collection of CityObjects. A CityObject can be an AbstractBuilding, a CityFurniture object, etc. Each CityObject can have a set of attributes. TSome of these attributes can be "generic" and can be defined by the user if necessary. See application domain extension.

OGC-CityObject.png

[edit] Building Model

The building module is the most important for us. A building inherits from AbstractBuilding and can consist of BuildingParts.
It is defined by the CityGML Building Model Schema File. This is the basis for being able to automatically validate the correctness of the modelled building.
CityGML-Abstract-Building.png
As the attributes of a building are defined in AbstractBuilding, each BuildingPart has the same set of attributes as the Building. The set of attributes include:

  • class
  • function
  • usage
  • yearOfConstruction
  • yearOfDemolition
  • roofType
  • measuredHeight
  • storeysAboveGround
  • storeysBelowGround
  • storeysHeightsAboveGround
  • storeysHeightsBelowGround

Looks great, but in many existing city models, these attributes are not filled with values, especially storeysAboveGround and storeysBelowGround is missing quite often.



[edit] Level of Detail 1

A level of detail 1 geometry of a building is either a solid geometry (closed volume) or a MultiSurface geometry (unstructured collection of polygons). Usually, it should be a solid geometry, but very often, it is modeled as MultiSurface geometry in existing city models.

LOD1 UML BSP.png

[edit] Example Building LOD1

Here is an example of Building modelled in LOD1: File:TWINHOUSE LOD1.zip

CityGML-Solid.png
A solid geometry is modelled by an exterior surface defining the boundary of the solid. In principle, it can have holes defined by interior surfaces, but I never seen such kind of model so far. A Surface is defined by a set of polygons. Each polygon is defined by an exterior linear ring and many interior rings, if the polygon should have holes.


[edit] Level of Detail 2

In contrast to LoD 1, the level of detail 2 geometry can contain both solid and MultiSurface elements. The Solid should model the volumetric parts of the geometry, the MultiSurface the non-volumetric parts (such as overhaning roofs, etc.). Unfortunately, in existing city models the geometry is models as one MultiSurface geometry only, so it is a bit difficult for an algorithms to detect which polygons bound a volume, and which are additional elements.
In addition, the LoD2 geometry has a set of Boundary Surfaces defining Roof, Walls and Ground of the building. As defined in the CityGMl standard, the Boudary Surfaces have MultiSurface geometry. The polygons defining each MultiSurface geometry should be referenced by the Solid geometry of the building to avoid redundant polygons.

LOD2 UML BSP.png

[edit] Example Building LOD2

Here is an example of Building modelled in LOD2: File:TWINHOUSE1 LOD2.zip
Here is an example of a simple building in LoD2.


[edit] Level of Detail 3

LOD3 UML BSP.png

[edit] Example Building LOD3

Here are examples of a Building modelled in LOD3:
File:Twinhouse LOD3 final openings.zip
File:Twinhouse LOD3 dark.zip


[edit] Level of Detail 4

LOD4 UML BSP.png

[edit] Example Building LOD4

Here is an example of Building modelled in LOD4: File:TWINHOUSE LOD4.zip

[edit] How to create an LOD 4 Building Model

Explanation of the development process: How to create an LOD4 Model
Provision of the corresponding files (Sketchup, FME, CityGML): File:TWINHOUSE LOD4 process.zip

[edit] CityGML Application Domain Extensions

CityGML can be extended by anybody. Adding simple attributes can be done quite easily using generic attributes (see above). If you need more, you need to come up with an XML schema that inherits from the object that should be extended. The mechanism behind it is called Application Domain Extension (ADE). On aim of the project is to propose such an ADE for energy simulations. Claudia Schulte has developed an ADE for flood simulations in her Master Thesis some years ago, and already started a collection of useful attributes / extensions for heat demand simulation. So before somebody starts to develop an ADE, I would strongly recommend to get in touch with Claudia.

[edit] Further Information

Listing of available CityGML datasets: CityGML Model Collection

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox