Publication Date: 2017-10-20

Approval Date: 2017-08-17

Posted Date: 2017-06-27

Reference number of this document: OGC 16-098

Reference URL for this document: http://www.opengis.net/doc/PER/FCP1-ER

Category: Public Engineering Report

Editors: Kanishk Chaturvedi, Thomas H. Kolbe

Title: FCP1 Engineering Report


OGC Engineering Report

COPYRIGHT

Copyright © 2017 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/

WARNING

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

LICENSE AGREEMENT

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

Abstract

The Future City Pilot Phase 1 (FCP1) is an OGC Interoperability Program initiative in collaboration with buildingSMART International (bSI). The pilot aimed at demonstrating and enhancing the ability of spatial data infrastructures to support quality of life, civic initiatives, and urban resilience. During the pilot, multiple scenarios were set up based on real-world requirements and were put forward by the pilot sponsors: Sant Cugat del Vallès (Barcelona, Spain), Ordnance Survey Great Britain (UK), virtualcitySYSTEMS GmbH (Germany), and Institut National de l’Information Géographique et Forestière - IGN (France). The scenarios were focused on (i) the interoperability between the two international standards: Industry Foundation Classes (IFC) and CityGML; (ii) city flood modeling; and (iii) supporting real-time sensor readings and other time-dependent properties within semantic 3D city models. The solutions for the respective scenarios were developed by the pilot participants: University of Melbourne (Australia), Remote Sensing Solutions, Inc. (U.S.A), and Technical University of Munich (Germany). This Engineering Report (ER) focuses on the third scenario requiring the support of real-time sensors and other time-dependent properties within semantic 3D city models based on the CityGML standard. It highlights a new concept 'Dynamizer', which allows representation of highly dynamic data in different and generic ways and providing a method for injecting dynamic variations of city object properties into the static representations. It also establishes explicit links between sensor/observation data and the respective properties of city model objects that are measured by them. The Dynamizer concept has been implemented as an Application Domain Extension (ADE) of the CityGML standard. This implementation allows to use new dynamizer features with the current version of the CityGML standard (CityGML 2.0). The advantage with this approach is that it allows for selected properties of city models to become dynamic without changing the original CityGML data model. If an application does not support dynamic data, it simply does not allow/include these special types of features. The details and results of the pilot are mentioned in the following YouTube video: https://youtu.be/aSQFIPwf2oM

Business Value

The current generation semantic 3D city models are static in nature and do not support time-dependent properties. However, in reality, there are different types of changes that take place in cities over time. Some of these changes are slower in nature, e.g., (i) history or evolution of cities such as construction or demolition of buildings and (ii) managing multiple versions of the city models. Some of the changes may also represent high frequency or dynamic variations of object properties, e.g., variations of (i) thematic attributes such as changes of physical quantities (energy demands, temperature, solar irradiation levels); (ii) spatial properties such as change of a feature’s geometry, with respect to shape and location (moving objects); and (iii) real-time sensor observations. In this case, only some of the properties of otherwise static objects need to represent such time-varying values. Dynamizer is a new concept supporting the latter types of changes and allowing for enriching the city model by data from dynamic data feeds.

What does this ER mean for the Working Group and OGC in general

This ER summarizes the work performed during the FCP1 and provides an outlook on possible future activities. It serves as a starting point for the OGC community in general, and the CityGML Working Group in particular, to understand some of the latest discussions on supporting real-time sensors and other time-dependent properties within the CityGML standard. It highlights a number of references to more detailed materials to facilitate more in-depth research and analysis.

How does this ER relates to the work of the Working Group

The Dynamizer concept is already being discussed within the CityGML Standard Working Group (SWG) and is intended to be included as a new module in the next major release of the CityGML standard.

Keywords

ogcdocs, FCP1, CityGML, Dynamizer, Timeseries, Sensor Web Enablement

Proposed OGC Working Group for Review and Approval

CityGML SWG

1. Introduction

1.1. Scope

This Engineering Report (ER) focuses on a scenario requiring the support of real-time sensors and other time-dependent properties within semantic 3D city models based on the CityGML standard. During FCP1, guidelines were developed for the following concepts with respect to the scenario.

  • Developing prototype capabilities that associate sensor readings (e.g. air quality sensors, weather information, electricity consumption) or other aggregated indicators (e.g. solar potential power, energy performance indicators) to elements in the city models.

  • Making sensor and dynamic data available through interoperable OGC web services.

  • Extending static city models by supporting highly dynamic properties and real-time sensor observations.

  • Planning and conducting a final demonstration using the pilot scenarios.

1.2. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Table 1. Contacts
Name Organization

Kanishk Chaturvedi

Technical University of Munich, Germany

Thomas H. Kolbe

Technical University of Munich, Germany

Tatjana Kutzner

Technical University of Munich, Germany

Andreas Donaubauer

Technical University of Munich, Germany

Guy Schumann

Remote Sensing Solutions Inc., U.S.A.

Eve Ross

Remote Sensing Solutions Inc., U.S.A.

Mohsen Kalantari

University of Melbourne, Australia

Bruno Willenborg

Technical University of Munich, Germany

Maximilian Sindram

Technical University of Munich, Germany

Claus Nagel

virtualcitySYSTEMS GmbH, Germany

Emmanuel Devys

Institut National de l’Information Géographique et Forestière - IGN, France

1.3. Future Work

The work described by this document serves as a basis for the development of the next major version of CityGML (CityGML 3.0). The Dynamizer ADE is intended to become a part of the CityGML 3.0.

This work may also be of importance to the TimeseriesML Standards Working Group for future revisions to the TimeseriesML standard.

No future work is planned to this document, but a number of work items and recommendations have been identified that shall be addressed in future initiatives, see Section 10.2.

1.4. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

2. References

The following documents are referenced in this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

  • OGC: OGC 06-021r4, OGC® Sensor Web Enablement (SWE) Architecture, 2008

  • OGC: OGC 10-004r3, OGC® Observations and Measurements, Version 2.0, 2013

  • OGC: OGC 12-000, OGC® SensorML: Model and XML Encoding Standard, Version 2.0, 2014

  • OGC: OGC 12-006, OGC® Sensor Observation Service Interface Standard, Version 2.0, 2012

  • OGC: OGC 12-019, OGC® City Geography Markup Language (CityGML) Encoding Standard, Version 2.0.0, 2012

  • OGC: OGC 15-043r3, OGC® TimeseriesML 1.0 - Timeseries Profile of Observations and Measurements, Version 1.0, 2016

  • OGC: OGC 15-078r6, OGC SensorThings API Part 1: Sensing, Version 1.0, 2016

  • OGC: OGC-16-097, FCP1: Recommendations on Mapping IFC/CityGML to 3DIM Engineering Report, 2017

  • OGC: OGC-16-099, FCP1: Urban planning rules checking using WPS to WPS SWG Engineering Report, 2017

  • OGC: OGC 16-130, The OGC CityGML EA UML Model – An ISO-compliant definition of the CityGML 2.0 UML model using Enterprise Architect [Not yet published]

  • ISO: ISO 19108:2002, Geographic Information – Temporal Schema, 2002

  • ISO: ISO 19123:2005, Geographic information — Schema for coverage geometry and functions, 2005

3. Terms and definitions

For the purposes of this report, the definitions specified in Clause 4 of the CityGML Encoding Standard [OGC 12-019] shall apply.

3.1. Abbreviated terms

  • ADE - Application Domain Extension

  • API - Application Programming Interface

  • bSI - buildingSMART International

  • CityGML - City Geography Markup Language

  • Climate KIC - Knowledge & Innovation Community on Climate Change and Mitigation

  • COLLADA - COLLAborative Design Activity

  • EIT - European Institute of Innovation & Technology

  • ER - Engineering Report

  • FCP1 - Future City Pilot Phase 1

  • glTF - GL Transmission Format

  • GML - Geography Markup Language

  • IFC - Industry Foundation Classes

  • IoT - Internet of Things

  • ISO - International Organization for Standardization

  • KML - Keyhole Markup Language

  • LoD - Level of Detail

  • OCL - Object Constraint Language

  • OGC - Open Geospatial Consortium

  • O&M - Observations & Measurements

  • SOS - Sensor Observation Service

  • SRDBMS - Spatial Relational Database Management System

  • SSD - Smart Sustainable Districts

  • SWE - Sensor Web Enablement

  • UML - Unified Modeling Language

  • W3C - Web 3D Consortium

  • WFS - Web Feature Service

  • XML - Extensible Markup Language

  • XPath - XML Path Language

4. Overview

This ER is a starting point to understand the Dynamizer concept. The concept has been implemented as an Application Domain Extension (ADE) of the CityGML standard. The ER describes the overall development and implementation process of this concept in order to solve the real life issues identified within the scope of the FCP1 scenarios.

The main document starts with a short overview of the FCP1, the scenarios put forward by the pilot sponsors, and the respective solutions developed by the pilot participants. However, the details of each solution are provided in the individual ERs prepared by the participants as mentioned in Chapter 5. This ER focuses on the scenario requiring the support of real-time sensor observations and other time-dependent properties within semantic 3D city models. Chapter 6 provides an overview of the new concept 'Dynamizer' which has been conceptualized in order to extend semantic 3D city models by representing highly dynamic data in different ways and providing a method for injecting dynamic variations of city object properties into the static representation. The Dynamizer concept has been implemented as an ADE of the CityGML standard. During the pilot, the UML model of the Dynamizer ADE was developed. The details and explanations of each UML class have been described in Chapter 7. Chapter 8 shows the XML schema definition files derived from the UML model. The XML schema definition files were used for creation of the CityGML instance documents used in the pilot. Chapter 9 lists the components and the software systems used within the pilot, followed by the implementations which were used for the result demonstrations. In the end, Chapter 10 provides an outlook on the achievements and future activities that require more research to further increase the usability of dynamizers in different applications.

5. FCP1 scenarios and requirements

This section provides a brief overview of different scenarios and objectives defined within the FCP1. The objective of the OGC pilot project was to demonstrate how the use of the international standards such as CityGML and IFC together can provide stakeholders with information, knowledge and insight which enhances financial, environmental, and social outcomes for citizens living in cities. During the pilot, three scenarios were set up based on the real-world requirements put forward by the pilot sponsors and solutions were developed and demonstrated by the pilot participants. A short overview of the FCP1 scenarios is provided below.

  1. Interoperability between the standards CityGML and IFC: CityGML [OGC 12-019] is an international standard for representing 3D city and landscape models. IFC [1] describes building information. This scenario is focused on providing interoperability between the CityGML and the IFC standards. During the pilot, the solutions were developed by University of Melbourne to map the IFC file to the CityGML file, which can further be validated based on Web Processing Service standard against a set of urban planning requirements. More details about this scenario are documented in [OGC 16-097] and [OGC 16-099].

  2. Inundation Modeling with 3D city models: This scenario highlights on inundation models developed by Remote Sensing Solutions Inc. (U.S.A.) and collaborating partners that can simulate real-time water flow characteristics over time and space at multiple resolutions (e.g., cm to km grid spacing). The solutions involved transformation from traditional inundation display to an interoperable city model inundation layer in the CityGML standard. In this way, detailed flooding scenarios can be developed, e.g., to determine which city objects such as buildings are at risk of flooding. The details of this scenario are provided by by Remote Sensing Solutions Inc. (U.S.A.) and can be found in Appendix A.

  3. Making city models dynamic: This ER focuses on the results and findings of this scenario, highlighting how dynamic city models can provide better services to the citizens as well as help for performing better analysis. The solutions were provided using the Dynamizer ADE of the CityGML standard, developed by the Chair of Geoinformatics, Technical University of Munich. During the pilot, two use cases were identified, as described below.

5.1. Integrating sensors with semantic 3D city models

This use case was set up by Ordnance Survey Great Britain and was based on the Royal Borough of Greenwich, London. The main objectives were (i) to provide better services to the citizens of the Royal Borough of Greenwich; (ii) to enable departments within the Royal Borough of Greenwich to share and coordinate data more effectively and to be recognized as an example of use of smarter working practices; and (iii) to improve collaboration between London boroughs by creating more interoperable data, content, and insight. The use of interoperable standards creates the opportunity to develop a cross-department platform to collaborate and share data. Furthermore, the potential integration with real-time sensor observations (e.g., monitoring humidity, temperature, etc.) within council housing can lead to decisions for matching human needs to the right housing/resources.

During the pilot, the 3D building objects were developed according to the CityGML LoD1 specifications, which were enriched by various thematic properties such as building address, details of the building residents, adult care, and housing stock information. The links to multiple sensors were defined in the CityGML building objects using dynamizers. The implementation and demonstration details can be found in Section 9.2.1.

5.2. Integrating time-dependent properties with semantic 3D city models

This use case was set up by IGN and virtualcitySYSTEMS GmbH and was based in the commune of Bruz, located 11 km southwest of Rennes in Brittany, France and is a part of Rennes Metropole. The main objectives were to provide better services to the citizens and the energy planners by making sophisticated solar potential analysis. The use case aimed at answering questions such as (i) How many buildings have solar irradiation of more than a specific unit (e.g. 5000 MWh)?, (ii) Which buildings are well suited for installing solar panels?, and (iii) How does the irradiation for a building vary through the year?.

During the pilot, the buildings and their wall and roof surfaces were registered according to the IGN REF3DNAT specification based on the CityGML LoD2 profile. The solar irradiation values for the roofs and facades were calculated using the Solar Potential Analysis tool (c.f. section 9.1.6). The simulation tool allows estimation of the solar power from direct, diffuse, and global sunlight irradiation for individual months and years. Such time-dependent values can now be represented within the CityGML datasets in standardized ways using dynamizers. The implementation details are provided in Section 9.2.2.

6. Making city models dynamic

The current generation semantic 3D city models are static in nature and do not support time-dependent properties. Apart from the scenarios mentioned in Chapter 5, there are many other application and simulation scenarios (e.g., environmental simulations, disaster management, training simulators), where time plays an important role. It is also important to distinguish between different types of changes that take place in cities over time. Some of these changes may be slower in nature, e.g., (i) history or evolution of cities such as construction or demolition of buildings and (ii) managing multiple versions of the city models. [2] propose an approach based on the CityGML standard to manage versions and history within semantic 3D city models. Some of the changes may also represent high frequency or dynamic variations of object properties, e.g., variations of (i) thematic attributes such as changes of physical quantities (energy demands, temperature, solar irradiation levels); (ii) spatial properties such as change of a feature’s geometry with respect to shape and location (moving objects); and (iii) real-time sensor observations (e.g., air quality sensors, weather stations, or smart meters). In this case, only some of the properties of otherwise static objects need to represent such time-varying values. Dynamizer is a new concept supporting the latter types of changes. Within the FCP1, the concept has been implemented to extend the CityGML information model using the built-in mechanism of the Application Domain Extension (ADE) in order to dynamize features and properties allowing for enriching the city model by data from dynamic data feeds.

6.1. Dynamizer - Introduction

Dynamizer allows modeling and integrating dynamic properties within semantic 3D city models. As shown in figure 1, the dynamizer serves three main purposes, as described below.

  1. Dynamizer is a data structure to represent dynamic values in different and generic ways. Such dynamic values may be given by tabulation of time/value pairs; patterns of time/value pairs; or by referencing an external file. These values can be obtained from sensors, simulation specific databases, and also external files such as CSV or Excel spreadsheets.

  2. Dynamizer delivers a method to enhance static city models by dynamic property values. It references a specific property (e.g. spatial, thematic, or appearance properties) of an object within a 3D city model providing dynamic values overriding the static value of the referenced object attribute.

  3. Dynamizer objects establish explicit links between sensor/observation data and the respective properties of city model objects that are measured by sensors. By making such explicit links with city object properties, the semantics of sensor data become implicitly defined by the city model.

In this way, dynamizers can be used to inject dynamic variations of city object properties into an otherwise static representation. The advantage in using such an approach is that it allows only selected properties of city models to be made dynamic. If an application does not support dynamic data, it simply does not allow/include these special types of features. More details on this concept can be found in peer-reviewed papers [3] and [4] .

DynamizersConceptualDiagram
Figure 1. Conceptual representation of Dynamizers allowing (i) the representation of time-variant values from sensors, simulation specific databases, and external files and (ii) enhancing the properties of city objects by overriding their static values. Image taken from [3].

7. Development of the UML Class Diagram for the Dynamizer ADE

Within the FCP1, dynamizers were implemented as an ADE for the CityGML standard. The ADE mechanism allows for the systematic extension of each CityGML object type by additional attributes as well as the introduction of new object types. This implementation allows dynamizers to be used with the current version of the CityGML standard (version 2.0).

Figure 2 shows the complete UML model of the Dynamizer ADE. The color scheme paints classes in different colors, depending on the UML package they belong to, and is defined as follows. A Class painted in yellow belongs to a CityGML UML package. A Class painted in light blue belongs to the GML package different to that associated with the yellow color. Classes painted in orange are newly introduced classes implemented as an ADE of the CityGML standard. However, there are two new classes which are not a part of [OGC 12-019] and belong to other OGC standards. Classes shown in dark blue represent OGC TimeseriesML 1.0 [OGC 15-043r3] and classes in pink belong to OGC Sensor Observation Service [OGC 12-006].

DynamizerADE Complete
Figure 2. Complete UML model of the Dynamizer ADE.

The individual components of the Dynamizer ADE UML model are explained in the following sub-sections.

7.1. Dynamizer - A new FeatureType

Dynamizer is a new feature type which is a sub-class of AbstractCityObject. In addition, AbstractDynamizerCityObject extends the class AbstractCityObject by the additional association dynamizers. This means that all the city objects such as buildings, roads, vegetation, etc. can now include their Dynamizer features either inline or as links to their respective dynamizer features. The class Dynamizer consists of three attributes: (i) attributeRef, (ii) startTime, and (iii) endTime. attributeRef refers to a specific attribute of a city object by XPath [5]. XPath is a W3C recommendation used to navigate through the elements and attributes within an XML document. startTime and endTime are absolute time points denoting the time span for which the dynamizer provides dynamic values. The time points are modeled as TM_Position defined by [ISO19108:2002], and are referenced to a specific time reference system (e.g. Gregorian Calendar). In addition, dynamizers contain dynamic data in the form of a timeseries. The dynamic data is modeled as AbstractTimeseries, which allows representing time-variant or dynamic values in different and generic ways. The timeseries may be modeled in two ways: (i) AtomicTimeseries and (ii) CompositeTimeseries (see Figure 3).

DynamizerADE FeatureType
Figure 3. Dynamizers modeled as a new FeatureType

7.2. Atomic Timeseries

Dynamizers can represent dynamic values in generic ways. The source of dynamic data may vary for different applications. The values may be obtained from (i) external files (e.g., CSV files) or data from external files included inline, (ii) external databases (e.g., tabulated values of simulation specific data), or (iii) real-time sensor observations (e.g., air quality sensors and smart meters). The dynamizers provide an explicit way to model such dynamic variations using AtomicTimeseries. They utilize different encodings defined according to OGC TimeseriesML 1.0 [OGC 15-043r3]. Utilizing TimeseriesML, the timeseries can be represented as interleaved time/value pairs or by a domain range encoding which is supported by dynamicdataTVP and dynamicDataDR (see figure 4). Since the TimeseriesML domain range encoding is an implementation of the [ISO 19123:2005] Discrete Coverages, it allows defining different data types for the specific time positions. Such data types may be numeric values, categories, spatial coordinates, or links to external files. Dynamizers also utilize TimeseriesML in defining interpolation and aggregation types for each point in the timeseries, which helps in mapping missing values or multiple values to specific time points.

DynamizerADE AtomicTimeseries
Figure 4. Representation of Atomic Timeseries, supporting different encodings from OGC TimeseriesML 1.0 as well as supporting sensor observations encoded in OGC O&M from a Sensor Observation Service response.

Apart from TimeseriesML, AtomicTimeseries also allows for the inline representation of the Observations and Measurements (O&M) data within a timeseries using observationData. O&M [OGC 10-004r3] is one of the core standards for the response models of the OGC Sensor Web Enablement (SWE)-based standards such as Sensor Observation Service [OGC 12-006] and SensorThings API [15-078r6]. In this way, dynamizers can represent real-time sensor observations. Please note that these representations are mutually exclusive for each AtomicTimeseries object. This condition is formally expressed using the Object Constraint Language (OCL) in the UML diagram. OCL is a declarative language for describing rules that apply to UML models. The constraint is defined as:

context AtomicTimeseries inv :
    (self.dynamicDataDR->notEmpty() xor self.dynamicDataTVP->notEmpty() xor self.observationData->notEmpty())
    and
    (not(self.dynamicDataDR->notEmpty() and self.dynamicDataTVP->notEmpty() and self.observationData->notEmpty()))

According to the expression, this OCL constraint would result in true only when exactly one of the properties has a value [6].

7.3. Composite Timeseries

Dynamizers support absolute start and end points referencing a specific time reference system. The absolute time points can be mapped to the attribute values and can be represented as tabulation of the measured data. One common example illustrating such scenario is mapping of the energy consumption values of a building for every hour in a day. However, in many applications, it is not sufficient just to provide a means for the tabulation of time-value pairs. The applications may require patterns to represent dynamic variations of properties based on statistics and general rules. In such scenarios, time cannot be described by absolute positions, but relative to the absolute positions. In these cases, time may be defined for a non-specific year (e.g., averages over many years), but still classified by relative time of an year. For example, January monthly summaries for the energy consumption of a building might be described as ”all-Januaries 2001-2010”. Similarly, the energy consumption values may reflect generic patterns for individual weekdays/weekends in a week or a month. Another example scenario may also be determining patterns for specific seasons (such as spring, summer, autumn, and winter) over ten years.

DynamizerADE CompositeTimeseries
Figure 5. Representation of Composite Timeseries, allowing representing patterns of dynamic variations of properties.

In order to support such patterns, dynamizers include the concept of composite timeseries as shown in figure 5. CompositeTimeseries is modeled in such a way that it composes of an ordered list of AbstractTimeseries. CompositeTimeseries includes a component called TimeseriesComponent, which denotes the number of repetitions for a timeseries component. repetitions is an integer type which determines how many times the nested timeseries should be iterated. For example, in order to determine the pattern of a building’s electricity consumption for weekdays, a composite timeseries may include five repetitions of atomic timeseries of a single weekday consumption. It also contains an attribute additionalGap, which is a type TM_Duration. It allows defining customized patterns by providing the gaps within the existing timeseries. For instance, for an entire monthly timeseries of energy consumption for all days of a week, the gaps can be provided for the weekends in order to define the patterns of energy consumption only for the weekdays. Furthermore, this attribute also allows connecting nonoverlapping timeseries that have been separately collected, in order to make a single timeseries. For example, if the latest two months of timeseries data is transferred from one system to a major archive, the series must be connected in order to make a full series over which the patterns can be determined (e.g., to determine yearly patterns). However, for a composite timeseries, it is necessary to model the time positions according to a relative time reference system. According to ISO 19108, they may be defined as TM_OrdinalEras within TM_OrdinalReferenceSystems. The use of composite timeseries allows defining local reference systems for the specific use cases. The demonstration of composite timeseries has not been covered within the FCP1, however, its details and examples can be found in [4].

7.4. Sensors and observations

Apart from different timeseries representations, dynamizers provide support for sensors and sensor observations within them. Within the OGC SWE standards suite [OGC 06-021r4], sensor descriptions are encoded in the SensorML format [OGC 12-000] and sensor observations in the O&M format [OGC 10-004r3]. The web services such as Sensor Observation Service and SensorThings API allow retrieval of the sensor descriptions and observations using different requests. Dynamizers leverage such standards and allow integrating sensors with semantic 3D city models in two ways.

  • By including sensor observations within dynamizers: The different standards such as SOS and SensorThings API allow encoding sensor observations in the O&M format. Dynamizers support inlining of the O&M data representing sensor observation values using AtomicTimeseries [c.f. section 7.2], which, are then injected into the attributes of the specific city objects. This approach is useful to exchange sensor readings for a past time period together and consistently within the city model. However, in the case of very high frequent observations (e.g., sensor readings at every 30 seconds), data management within the databases may lead to storage related issues.

  • By linking dynamizers with sensors: In order to avoid such storage related issues in the case of high frequent observations, dynamizers support direct links to sensors and observations utilizing different sensor based services such as SOS and SensorThings API. There are already well-defined data models and implementations available for storing and managing large and frequent sensor observations (see section 9.1.7). The sensor based services such as SOS include different requests: e.g., DescribeSensor and GetObservation. With such requests, sensor descriptions and observations are retrieved in standardized ways and their URL links can also be defined within the city objects. A sensor connection is defined by a unique sensor ID, the type of sensor service (e.g., OGC SOS and Sensor Things API), and URL links for the two different requests named above. Applications consuming CityGML plus dynamizer data can utilize these links to retrieve the sensor data for the referenced web services.

DynamizerADE SensorConnection
Figure 6. Representation of the data type SensorConnection, allowing to define the details of sensor based services within the CityGML document.

As shown in figure 6, dynamizers provide links to external sensors with the help of the new datatype SensorConnection. It contains four attributes: (i) sensorID - the unique identification of the sensor within the referenced sensor service, (ii) serviceType - the type of sensor based service such as SOS and SensorThings API, (iii) linkToObservation - URL link to the request for retrieving sensor observations, and (iv) linkToSensorML - URL link to the request for retrieving the sensor descriptions and metadata. OGC SOS involves different requests for retrieving the sensor descriptions and observations. DescribeSensor is used to retrieve sensor descriptions and metadata in the SensorML format. GetObservation is used to retrieve sensor observations encoded in the O&M format. The request parameter also allows the specification of spatial and temporal filters. The association sensorLocation allows specifying which city object this sensor belongs to. For example, if a solar panel is installed on a building roof surface with a sensor estimating heat demand of the building, the datatype SensorConnection would not only provide direct links to the sensor description and observations but also specify the link to the roof surface of the CityGML building object on which the solar panel is installed.

8. Dynamizer ADE XML Schema

This section includes the XML schema definition for the Dynamizer ADE. For the conceptual schema development, the model driven approach based on the ISO 19100 series of standards is applied, which allows for automatically deriving the XML schema documents from the conceptual schema. Upon development of the UML conceptual schema of the Dynamizer ADE, the XML schema was derived using the tool ShapeChange (see section 9.1.2). The details of the automatic derivation of the XML schema will be published in [OGC 16-130]. Based on the XML schema documents, valid CityGML Dynamizer ADE instance documents were developed according to specified use cases and used for the demonstrations as described in section 9.2.

Header of the Dynamizer ADE Schema definition file

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:dyn="http://www.citygml.org/ade/dynamizer_ade/1.0"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://www.citygml.org/ade/dynamizer_ade/1.0"
	elementFormDefault="qualified"
	version="1.0"
  xmlns:tsml="http://www.opengis.net/tsml/1.0"
  xmlns:sos="http://www.opengis.net/sos/2.0"
  xmlns:core="http://www.opengis.net/citygml/2.0"
  xmlns:gen="http://www.opengis.net/citygml/generics/2.0"
  xmlns:gml="http://www.opengis.net/gml" >
  <xsd:import namespace="http://www.opengis.net/tsml/1.0"
    schemaLocation="http://schemas.opengis.net/tsml/1.0/timeseriesML.xsd"/>
  <xsd:import namespace="http://www.opengis.net/sos/2.0"
    schemaLocation="http://schemas.opengis.net/sos/2.0/sosGetObservation.xsd"/>
  <xsd:import namespace="http://www.opengis.net/citygml/2.0"
    schemaLocation="http://schemas.opengis.net/citygml/2.0/cityGMLBase.xsd"/>
  <xsd:import namespace="http://www.opengis.net/citygml/generics/2.0"
    schemaLocation="http://schemas.opengis.net/citygml/generics/2.0/generics.xsd"/>
  <xsd:import namespace="http://www.opengis.net/gml"
    schemaLocation="http://schemas.opengis.net/gml/3.1.1/base/gml.xsd"/>
  <xsd:import namespace="http://www.opengis.net/om/2.0"
    schemaLocation="http://schemas.opengis.net/om/2.0/observation.xsd"/>
...
</xsd:schema>

DynamizerPropertyType

  <xsd:element name="dynamizers"
               substitutionGroup="core:_GenericApplicationPropertyOfCityObject"
               type="dyn:DynamizerPropertyType"/>
  <!-- ================================================= -->
  <xsd:complexType name="DynamizerPropertyType">
    <xsd:sequence minOccurs="0">
      <xsd:element ref="dyn:Dynamizer"/>
    </xsd:sequence>
    <xsd:attributeGroup ref="gml:AssociationAttributeGroup"/>
  </xsd:complexType>

DynamizerType, Dynamizer

  <xsd:element name="Dynamizer" substitutionGroup="core:_CityObject"
               type="dyn:DynamizerType"/>
  <!-- ================================================= -->
  <xsd:complexType name="DynamizerType">
    <xsd:complexContent>
      <xsd:extension base="core:AbstractCityObjectType">
        <xsd:sequence>
          <xsd:element name="attributeRef" type="xsd:anyURI"/>
          <xsd:element name="startTime" type="gml:TimePositionType"/>
          <xsd:element name="endTime" type="gml:TimePositionType"/>
          <xsd:element minOccurs="0" name="dynamicData"
                       type="dyn:AbstractTimeseriesPropertyType"/>
          <xsd:element minOccurs="0" name="linkToSensor"
                       type="dyn:SensorConnectionPropertyType"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>

SensorConnectionType, SensorConnection

  <xsd:element name="SensorConnection" substitutionGroup="gml:_Object"
               type="dyn:SensorConnectionType"/>
  <!-- ================================================= -->
  <xsd:complexType name="SensorConnectionType">
    <xsd:sequence>
      <xsd:element name="sensorID" type="xsd:string"/>
      <xsd:element name="serviceType" type="xsd:string"/>
      <xsd:element minOccurs="0" name="linkToObservation" type="xsd:anyURI"/>
      <xsd:element minOccurs="0" name="linkToSensorML" type="xsd:anyURI"/>
      <xsd:element minOccurs="0" name="sensorLocation"
                   type="core:AbstractCityObjectType"/>
    </xsd:sequence>
  </xsd:complexType>
  <!-- ================================================= -->
  <xsd:complexType name="SensorConnectionPropertyType">
    <xsd:sequence>
      <xsd:element ref="dyn:SensorConnection"/>
    </xsd:sequence>
  </xsd:complexType>

AbstractTimeseriesType, AbstractTimeseries

  <xsd:element abstract="true" name="AbstractTimeseries"
               substitutionGroup="gml:_Feature"
               type="dyn:AbstractTimeseriesType"/>
  <!-- ================================================= -->
  <xsd:complexType abstract="true" name="AbstractTimeseriesType">
    <xsd:complexContent>
      <xsd:extension base="gml:AbstractFeatureType">
        <xsd:sequence/>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <!-- ================================================= -->
  <xsd:complexType name="AbstractTimeseriesPropertyType">
    <xsd:sequence minOccurs="0">
      <xsd:element ref="dyn:AbstractTimeseries"/>
    </xsd:sequence>
    <xsd:attributeGroup ref="gml:AssociationAttributeGroup"/>
  </xsd:complexType>

AtomicTimeseriesType, AtomicTimeseries

  <xsd:element name="AtomicTimeseries" substitutionGroup="dyn:AbstractTimeseries"
               type="dyn:AtomicTimeseriesType"/>
  <!-- ================================================= -->
  <xsd:complexType name="AtomicTimeseriesType">
    <xsd:complexContent>
      <xsd:extension base="dyn:AbstractTimeseriesType">
        <xsd:sequence>
          <xsd:element minOccurs="0" name="dynamicDataTVP"
                       type="tsml:TimeseriesTVPPropertyType"/>
          <xsd:element minOccurs="0" name="dynamicDataDR"
                       type="tsml:TimeseriesDomainRangePropertyType"/>
          <xsd:element minOccurs="0" name="observationData"
                       type="sos:GetObservationResponsePropertyType"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <!-- ================================================= -->
  <xsd:complexType name="AtomicTimeseriesPropertyType">
    <xsd:sequence minOccurs="0">
      <xsd:element ref="dyn:AtomicTimeseries"/>
    </xsd:sequence>
    <xsd:attributeGroup ref="gml:AssociationAttributeGroup"/>
  </xsd:complexType>

CompositeTimeseriesType, CompositeTimeseries

  <xsd:element name="CompositeTimeseries" substitutionGroup="dyn:AbstractTimeseries"
               type="dyn:CompositeTimeseriesType"/>
  <!-- ================================================= -->
  <xsd:complexType name="CompositeTimeseriesType">
    <xsd:complexContent>
      <xsd:extension base="dyn:AbstractTimeseriesType">
        <xsd:sequence>
          <xsd:element maxOccurs="unbounded" name="component"
                       type="dyn:TimeseriesComponentPropertyType"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <!-- ================================================= -->
  <xsd:complexType name="CompositeTimeseriesPropertyType">
    <xsd:sequence minOccurs="0">
      <xsd:element ref="dyn:CompositeTimeseries"/>
    </xsd:sequence>
    <xsd:attributeGroup ref="gml:AssociationAttributeGroup"/>
  </xsd:complexType>

TimeseriesComponentType, TimeseriesComponent

  <xsd:element name="TimeseriesComponent" substitutionGroup="gml:_Feature"
               type="dyn:TimeseriesComponentType"/>
  <!-- ================================================= -->
  <xsd:complexType name="TimeseriesComponentType">
    <xsd:complexContent>
      <xsd:extension base="gml:AbstractFeatureType">
        <xsd:sequence>
          <xsd:element name="repetitions" type="xsd:positiveInteger"/>
          <xsd:element minOccurs="0" name="additionalGap" type="xsd:duration"/>
          <xsd:element name="timeseries" type="dyn:AbstractTimeseriesPropertyType"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>
  </xsd:complexType>
  <!-- ================================================= -->
  <xsd:complexType name="TimeseriesComponentPropertyType">
    <xsd:sequence minOccurs="0">
      <xsd:element ref="dyn:TimeseriesComponent"/>
    </xsd:sequence>
    <xsd:attributeGroup ref="gml:AssociationAttributeGroup"/>
  </xsd:complexType>

9. FCP1 Demonstrations

This section provides a brief overview of the components used and the solutions developed for demonstrating the FCP1 scenarios.

9.1. Components development

In this section, the details of the software systems and components have been provided which were used and also modified for the demonstrations of the FCP1 scenarios. The list of the components used is as follows.

9.1.1. Enterprise Architect

Enterprise Architect (EA) [7] is a UML design tool. Since EA supports a model-driven approach for defining geospatial data, the UML data models of the CityGML standard have already been developed using EA. The new dynamizer ADE classes were developed using this software, which were stored using the .eap file name extension.

9.1.2. ShapeChange

ShapeChange[8] is an open-source Java tool which can process the UML models for geographic information and derives the GML application schemas (and other transfer formats) from these UML models. The tool can directly read the UML models defined using EA via the EA Java API. The guidelines and examples for how to derive the XML schemas from the EA file and for how to create the ADEs and to derive the corresponding XML schema using ShapeChange will be documented in [OGC 16-130].

9.1.3. Feature Manipulation Engine (FME)

FME [9] is a software developed by Safe Software and facilitates the transformation of spatial data into a variety of formats, data models, and repositories for transmission to end users. This software is widely used for reading and writing different geospatial data formats including CityGML and CityGML ADEs. For creation of the CityGML instance documents including the Dynamizer ADE, the FME transformer 'XMLTemplater' was used. This transformer takes an XML schema definition file as input and creates sample XML instance documents. However, FME is a proprietary software and requires an appropriate license. There is an open source Java API called 'citygml4j' [10] which can also be used for creating instance CityGML documents along with their ADEs.

9.1.4. 3D City Database

In order to store and manage the CityGML datasets, an open-source geodatabase called '3DCityDB' [11] is used. 3DCityDB stores, represents, and manages the large CityGML datasets on top of a standard spatial relational database management systems (SRDBMS) such as Oracle Spatial and PostgreSQL. It provides a Java front-end application named '3DCityDB Importer/Exporter', which allows for high performance importing and exporting the CityGML datasets with arbitrary file sizes. It also allows exporting the contents in the form of different visualization formats such as KML, COLLADA, and glTF, allowing the 3D objects to be viewed and interactively explored in the web applications. For integration into an OGC Web Service environment, the 3DCityDB contains a Web Feature Service (WFS) interface, using which the CityGML features can be requested in standardized ways. 3DCityDB also allows extending the functionalities in a modular way by the installation of plugins, which add specific abilities to interact with the 3D city database. For instance, by using the Spreadsheet Generator Plugin, arbitrary subsets of the city model data such as generic attributes can be exported in tabular form having the selected attributes from 3D city database instance whether as a CSV file or directly be uploaded as a Google Spreadsheet Document or Google Fusion Table. Furthermore, 3DCityDB also provides a functionality to validate CityGML documents.

9.1.5. 3DCityDB Visualization Clients

For high-performance 3D visualization and interactive exploration of arbitrarily large semantic 3D city models based on the CityGML standard, there are different web-based visualization clients available and used within the pilot. 3DCityDB-Web-Map-Client Pro ([12]) developed by the Chair of Geoinformatics, Technical University of Munich, is a web-based front-end client of 3DCityDB, which not only allows exploring and interacting with large semantic 3D city models, but also provides thematic querying capabilities on the 3D objects. It supports linking the 3D visualization models (KML/glTF) with the cloud-based Google Spreadsheet documents or Google Fusion Table allowing for querying the thematic data of every 3D object. virtualcityMAP [13] is also a web based visualization client developed by virtualcitySYSTEMS GmbH for working with large semantic 3D city models. 3DCityDB-Web-Map-Client [14] is a free and open-source visualization client developed by the Chair of Geoinformatics, Technical University of Munich in cooperation with virtualcitySYSTEMS GmbH. This client provides rich 3D visualization and interactive exploration of arbitrarily large semantic 3D city models based on the CityGML standard. However, it does not support querying capabilities unlike other mentioned visualization clients.

All of the visualization clients use the Cesium [15] virtual globe as their visualization engines. Cesium is an open source JavaScript package supporting the presentation of 3D contents within the web browser where users can dynamically switch between 3D globe visualization and 2D map projection. It utilizes HTML5 and WebGL to provide hardware acceleration and plugin independence and provides cross-platform, cross-browser, and cross-device functionalities.

9.1.6. Solar Potential Analysis Tool

The Solar Potential Analysis Tool [16] is a simulation tool developed by the Chair of Geoinformatics, Technical University of Munich for assessing and estimating solar energy production for the roofs and facades of the 3D building objects in different ways. The simulation tool operates on the semantic 3D city models defined according to the CityGML standard. By combining a transition model, sun position calculation, and an approximation of the sky dome, the solar power from direct, diffuse, and global sunlight irradiation are estimated for individual months and years. The shadowing effects of the surrounding topographic features are considered by applying a ray tracing approach. The Sky View Factor (SVF), a measure indicating the visible fraction of the sky hemisphere, is determined for each surface.

As a result, each building surface is being enriched by its individual irradiation values. These are also aggregated to the building level. Finally, a point cloud is generated from sampling points that have been generated for each building surface for the simulation. Each point is parameterized with the direct, diffuse, and global irradiation values over the different months and can thus, be visualized in different colors according to the respective solar power as shown in figure 7.