Workshop Topics

In various meetings and discussions SIG 3D, OGC CityGML SWG and TUM have collected several topics which are important for the further development of the CityGML standard. However, before starting with the development of a new major version of CityGML, it was regarded as useful to first discuss these topics in a workshop with a broader audience.
In the following paragraphs we describe each topic in more detail and indicate why the topic is important. Since during the two-day workshop there won’t be enough time to discuss all topics, we suggest that in this workshop only the topics “LOD Concept of CityGML”, “Improved Support for Simulations”, “Stronger Harmonisation with 2D Cadastre and Models” and “Extension of CityGML by new objects” should be discussed and that the topics “Improvement of Harmonisation with BIM” and “Structure of the Specification Document” should be delayed to a later workshop.

Improved Support for Simulations

On the one hand CityGML is a very useful and important source of information for different types of simulations, whereas on the other hand the results of simulations can be fed back to the original CityGML data for thematic enrichment and data fusion. Therefore, semantic 3D city models and simulations should become tighter coupled in the future.
In most simulations time plays an important role, i.e. dynamic / time-varying feature properties (spatial and thematic, e.g. electrical energy demand or production potential for a building along the course of the day / week / year), which are not yet supported in CityGML.
Furthermore the quality of individual attributes needs to be represented and propagated when different attributes are combined (e.g. multiplied). This requires the definition of qualified attributes (metadata at individual attribute level like lineage, accuracy, unit of measure, date of acquisition etc.) This concept is similar to the INSPIRE complex attributes but the definition should be done in a more systematic way.

LOD Concept of CityGML

Currently the CityGML specification defines five LODs. However, several works exist which suggest modifications or even a replacement of the current LOD concept. These include the separation of the current LODs into semantic and geometric LODs, complementing the current concept by separate indoor LODs, or introducing more / less / continuous LOD levels.
This topic induces a fundamental change to the current structure of CityGML and thus needs to be discussed thoroughly in a larger round of developers, users and data providers before any decision will be made. The alternative suggestions have to be analysed and their advantages and disadvantages over the current concept have to be identified. Only afterwards it will be possible to decide whether the current LOD concept should be kept or modified. This decision has also to take into account the opinion of the users of CityGML, i.e. if the acceptance of a new LOD concept will be given by them, if the new concept will be easy to understand and if the investments for implementing the new concept are bearable.

Extension of CityGML by new objects

CityGML only provides some basic objects and attributes. If for a certain application more specific objects and attributes are required, they can be added to CityGML by means of an ADE or by generics. However, it has been proposed to add permanent support for other types of constructions like walls, fences etc., by defining specific feature types for these objects. These objects are required by several CityGML users and also exist in the INSPIRE Buildings theme.

Stronger Harmonisation with 2D Cadastre and Models

CityGML currently does not allow 2D geometries to be added to the data. Furthermore, buildings cannot be represented by 3D points and 2,5D geometries always have to be defined with a constant z value. Due to the increasing importance of INSPIRE and the migration of national frameworks to 3D, where these geometries are admissible, it needs to be discussed whether 2D geometries are to be allowed in CityGML as well and whether the definition of LOD0 should be modified to allow unique z values and 3D points.

Improvement of Harmonisation with BIM

CityGML and BIM represent similar but not identical concepts. To support a smoother conversion between the two concepts, the CityGML Buildings module needs to be extended by relevant BIM concepts such as volumetric elements. Furthermore, suggestions have been made to extend the Buildings module by Storeys, BuildingUnits, building components and further attributes. These concepts exist in the INSPIRE Buildings theme and they have also been requested by several CityGML users.
Due to the extensiveness of this topic we suggest to delay the discussion to a later workshop in about seven to nine months or even to organise a workshop dealing specifically with this topic only and addressing primarily the BIM community.

Structure of the Specification Document

The current CityGML specification consists of one document comprising normative and informative parts (description of the concepts of CityGML for all modules, conformance requirements, UML diagrams, XSD schemas, illustrative examples). All these contents make the document very comprehensive and huge, which leads to the question, whether a) the specification of version 3.0 should be developed again as one big document or b) the contents should be separated into several smaller specification documents. In case of a) it has to be discussed if possibly the contents need to be arranged in a different way to make the whole document more clearly structured. For b) it has to be discussed in which way the individual contents are divided up into separate documents. When deciding on one of the two options, the opinion of the users of the specification has to be taken into account, i.e. will it be more convenient for them to use one big document or several smaller interconnected documents.
This topic should either be delayed to a later workshop or be discussed in the CityGML SWG, since we don’t consider it to be as substantial and urgent as the other topics described here.