Get 20M+ Full-Text Papers For Less Than $1.50/day. Start a 14-Day Trial for You or Your Team.

Learn More →

CityGML 3.0: New Functions Open Up New Applications

CityGML 3.0: New Functions Open Up New Applications The development of the next major version 3.0 of the international OGC standard CityGML is nearing its end. CityGML 3.0 will come up with a variety of new features and revisions of existing modules that will increase the usability of CityGML for more user groups and areas of application. This includes a new space concept, a revised level-of-detail (LOD) concept, the representation of time-dependent properties, the possibility to manage multiple versions of cities, the representation of city objects by point clouds, an improved modelling of constructions, the representation of building units and storeys, an improved representation of traffic infrastructure as well as a clear separation of the conceptual model and the data encod- ings that allow for providing further encoding specifications besides GML. This paper gives an overview of these new and revised concepts, and illustrates their application through selected use cases. Keywords CityGML 3.0 · 3D city models · Space concept Zusammenfassung CityGML 3.0: Neue Funktionen eröffnen neue Anwendungen. Die Entwicklung der nächsten Hauptversion 3.0 des internationalen OGC-Standards CityGML nähert sich dem Ende. CityGML 3.0 wird mit einer Vielzahl an neuen Funktionen und der Überarbeitung bestehender Module aufwarten, die die Benutzerfreundlichkeit von CityGML für weitere Benutzer gruppen und Anwendungsbereiche verbessern. Dazu gehören ein neues Space-Konzept, ein überarbeitetes Level-of-Detail (LOD)-Konzept, die Darstellung von zeitabhängigen Eigenschaften, die Möglichkeit, mehrere Versionen von Stadtmodellen gleichzeitig zu verwalten, die Darstellung von Stadtobjekten durch Punktwolken, eine verbesserte Modellierung von sonstigen Bauwerken, die Darstellung von Gebäudeeinheiten und Etagen, eine verbesserte Darstellung der Verkehrsinfrastruktur sowie eine klare Trennung des konzeptuellen Modells von der Datenhaltung, die es erlaubt, neben GML weitere Datenformate bereitzustellen. Dieser Artikel gibt einen Überblick über die neuen und überarbeiteten Konzepte und veranschaulicht ihre Anwendung anhand ausgewählter Beispiele. 1 Overview and Development of CityGML city furniture, water bodies, and vegetation. One well-known 3.0 standard for modelling, storing, and exchanging semantic 3D city models is the international standard CityGML issued Semantic 3D city models are nowadays commonly used for by the Open Geospatial Consortium (OGC) (Gröger et al. representing the real-world entities of cities and landscapes, 2012). The current version 2.0 of the standard was adopted such as buildings, bridges, tunnels, transportation objects, by OGC in March 2012. To increase the usability of City- GML for more user groups and areas of application, the OGC CityGML SWG and the Special Interest Group 3D * Tatjana Kutzner (SIG 3D) of the initiative Geodata Infrastructure Germany kutzner@tum.de (GDI-DE) started in 2013 to work on the next major version Kanishk Chaturvedi CityGML 3.0. kanishk.chaturvedi@tum.de Since the release of CityGML 2.0, several change Thomas H. Kolbe requests have been submitted to OGC. Further require- thomas.kolbe@tum.de ments and ideas were gathered and discussed at an interna- tional workshop jointly hosted by OGC and SIG 3D in June Chair of Geoinformatics, Technical University of Munich, 80333 Munich, Germany Vol.:(0123456789) 1 3 44 PFG (2020) 88:43–61 2013. Both, the outcomes of this discussion and the change requests, were organised into 14 Work Packages (WPs) that defined the overall work scope for CityGML 3.0. Persons interested in participating could do so as either work pack- age lead, editor, co-editor, contributor, or reviewer. Some WPs consistently progressed and produced useful results, whereas other WPs were not active at all. By the end of 2017, the results of the active WPs were integrated into a consolidated version of the CityGML 3.0 Conceptual Model (Kutzner and Kolbe 2018). Afterwards, a process of refining and resolving open issues took place until the end of 2019. Thus, it is a good point in time now to take a closer look at the new concepts and improvements CityGML 3.0 will offer. The current version of the conceptual UML model as well as the GML encoding (XML schemas) can be freely accessed in the github repositories OGC (2019a) and OGC (2019b), respectively. The CityGML model has been fully revised to reflect the increasing need for better interoperability with other relevant standards in the field like Industry Foundation Fig. 1 CityGML 3.0 module overview. The vertical boxes show the different thematic modules. Horizontal modules specify concepts that Classes (IFC) (ISO 16739 2013), IndoorGML (Lee et al. are applicable to all thematic modules 2016), Land Administration Domain Model (LADM) (ISO 19152 2012), INSPIRE (European Parliament and Council 2007), as well as with linked data and Semantic Web Tech- nologies like the Resource Description Framework (RDF) the modelling language UML (ISO 19505-2 2012), and (2) (W3C 2014). External object references have been rephrased the automatic derivation of transfer formats from these UML and are now better aligned to an RDF representation. Like models by applying predefined transformation rules. This before, each city object can have an arbitrary number of approach has been applied, e.g. in the development of the references to other objects in other datasets or databases, European INSPIRE Data Specifications (JRC 2014) and the but these can now be additionally qualified by a relation type German AFIS–ALKIS–ATKIS (AAA) Reference Model (that can point to a definition from an external ontology, e.g. (AdV 2009). The following tools are used to implement the the sameAs relation from OWL) given by an additional URI model-driven approach: Enterprise Architect (Sparx Sys- and allow for mapping to RDF triples. tems 2015) for defining the CityGML 3.0 UML model and The CityGML 3.0 standard will consist of two parts: ShapeChange (Interactive Instruments 2019) for deriving the the CityGML 3.0 Conceptual Model specification, which GML application schemas. Also, the feature catalogue with is planned to be released early 2020, and the CityGML 3.0 a detailed overview and explanation of all classes, attributes, GML Encoding specification, which is to be published a and relationships is derived automatically. couple of months after. Further encoding specifications UML data models developed for the GI domain are usu- (e.g. relational database schema, JSON-based representa- ally based on relevant standards from the ISO 191xx series tion) may follow in the future. The CityGML 3.0 Conceptual of geographic information standards. The data model of Model defines 17 modules as shown in Fig.  1. All mod- CityGML 3.0 is now based on these standards as well. This ules from CityGML 2.0 are part of CityGML 3.0. In addi- means that the geometry types from ISO 19107 as well as tion, the new modules Dynamizer, Versioning, PointCloud, the data types from ISO 19103 are used and that the rules for and Construction were introduced, and the modules Core, defining application schemas in UML from ISO 19109 are Generics, Building, and Transportation have been revised. applied. In addition, the transformation rules for converting The other modules have been updated to work with the new UML models to GML application schemas from ISO 19136 Core module. are applied in the GML encoding. CityGML 3.0 applies a model-driven approach in the cre- The application of the ISO-compliant transformation ation of the data model and exchange formats. Over the last rules inevitably leads to some changes in the XML encod- decade, this approach has become the standard procedure for ing compared to CityGML 2.0 and 1.0. Even if CityGML defining geospatial application schemas. The model-driven 3.0 would not change anything on the conceptual model with approach involves two steps: (1) the definition of data mod - regard to CityGML 2.0, the encoding would be slightly dif- els at the conceptual level, which is commonly done using ferent and datasets would have to be converted and software 1 3 PFG (2020) 88:43–61 45 for CityGML 2.0 would have to be adapted for CityGML 3.0. However, all modifications to the new CityGML 3.0 model are carried out in a way to ensure backwards com- patibility with CityGML 1.0 and 2.0, i.e. it is possible to transform all CityGML 1.0 and 2.0 datasets into the new model by applying syntactical transformations only. Back- wards compatibility is a major requirement for CityGML 3.0 to preserve the investments by anybody providing CityGML tools, datasets, and extensions. 2 The New CityGML 3.0 Core Module Fig. 2 Occupied and unoccupied spaces 2.1 T he CityGML 3.0 Space Concept and Varzi (2000) on the difference between bona fide and In CityGML 3.0, a clear semantic distinction of spatial features is introduced by mapping all city objects onto fiat boundaries to bound objects. Bona fide boundaries are physical boundaries; they correspond to the physical the semantic concepts of spaces and space boundaries. A Space is an entity of volumetric extent in the real world. boundaries of physical spaces in CityGML 3.0. In contrast, fiat boundaries are man-made boundaries; they are equiva- Buildings, water bodies, trees, rooms, and traffic spaces, for instance, have a volumetric extent. Hence, they are lent to the virtual boundaries of logical spaces. Physical spaces, in turn, are further classified into occu- modelled as spaces or, more precisely, as specific sub- classes of the abstract class Space. A Space Boundary pied spaces and unoccupied spaces. Occupied spaces rep- resent physical volumetric objects that occupy space in is an entity with areal extent in the real world. Space Boundaries delimit and connect Spaces. Examples are the the urban environment. Examples for occupied spaces are buildings, bridges, trees, city furniture, and water bodies. wall surfaces and roof surfaces that bound a building; the water surface as boundary between the water body and air; Occupying space means that some space is blocked by these volumetric objects; for instance, the space blocked by the road surface as boundary between the ground and the traffic space; or the digital terrain model representing the the building in Fig.  2 cannot be used any more for driv- ing through this space or placing a tree on that space. In space boundary between the over- and underground space. To obtain a more precise definition of spaces, they contrast, unoccupied spaces represent physical volumetric entities that do not occupy space in the urban environment, are further subdivided into physical spaces and logical spaces. Physical spaces are spaces that are fully or par- i.e. no space is blocked by these volumetric objects. Exam- ples for unoccupied spaces are building rooms and traffic tially bounded by physical objects. Buildings and rooms, for instance, are physical spaces as they are bounded by spaces. There is a risk of misunderstanding the term Occu- piedSpace. However, we decided to use the term anyway, as walls and slabs. Traffic spaces of roads are physical spaces as they are bounded by road surfaces against the ground. it is established in the field of robotics for over three decades (Elfes 1989). The navigation of mobile robots makes use of a Logical spaces, in contrast, are spaces that are not neces- sarily bounded by physical objects, but are defined accord- so-called occupancy map that marks areas that are occupied by matter and, thus, are not navigable for robots. ing to thematic considerations. Depending on the applica- tion, logical spaces can also be bounded by non-physical, Semantic objects in CityGML are often composed of parts, i.e. they form multi-level aggregation hierarchies. This i.e. virtual boundaries and they can represent aggrega- tions of physical spaces. A building unit, for instance, is also holds for semantic objects representing occupied and unoccupied spaces. In general, two types of compositions a logical space as it aggregates specific rooms to flats, the rooms being the physical spaces that are bounded by can be distinguished: wall surfaces, whereas the aggregation as a whole is being delimited by a virtual boundary. Other examples are city (1) Spatial partitioning Semantic objects of either the space type OccupiedSpace or UnoccupiedSpace are districts which are bounded by virtual vertically extruded administrative boundaries; public spaces vs. security subdivided into different parts that are of the same space type as the parent object. Examples are Buildings zones in airports; or city zones with specific regulations stemming from urban planning. The definition of physi- that can be subdivided into BuildingParts, or Buildings that are partitioned into ConstructiveElements. Build- cal and logical spaces and of corresponding physical and virtual boundaries is in line with the discussion in Smith ings as well as BuildingParts and ConstructiveElements 1 3 46 PFG (2020) 88:43–61 represent OccupiedSpaces. Similarly, Roads can be subdivided into TrafficSpaces and AuxiliaryTraffic- Spaces, all objects being UnoccupiedSpaces. (2) Nesting of alternating space types Semantic objects of one space type contain objects that are of the opposite space type as the parent object. Examples are Buildings (OccupiedSpace) that contain BuildingRooms (Unoc- cupiedSpace), BuildingRooms (UnoccupiedSpace) that contain Furniture (OccupiedSpace), and Roads (UnoccupiedSpace) that contain CityFurniture (Occu- Fig. 3 Representation of a carport as OccupiedSpace in different piedSpace). The categorization of a semantic object LODs. The red boxes represent solids, the green area represents a sur- into occupied or unoccupied takes place at the level face. In addition, the normal vectors of the roof solid (in red) and the of the object in relation to the parent object. A build- roof surface (in green) are shown ing is part of a city model; thus, first of all it occupies urban space within a city. As long as the interior of of UnoccupiedSpaces (e.g. Rooms, Roads), the observer is the building is not modelled in detail, the space cov- ered by the building needs to be considered as occu- typically inside the UnoccupiedSpace. The classification into OccupiedSpace and Unoccupied- pied and only viewable from the outside. To make the building accessible inside, voids need to be added to Space might not always be apparent at first sight. Carports, for instance, represent an OccupiedSpace, although they the building in the form of building rooms. The rooms add free space to the building interior, i.e. the Occu- are not closed and most of the space is free of matter, see Fig. 3. Since a carport is a roofed, immovable structure with piedSpace contains now UnoccupiedSpace. The free space inside the building can, in turn, contain objects the purpose of providing shelter to objects (i.e. cars), car- ports are frequently represented as buildings in cadastres. that occupy space again, such as furniture or installa- tions. In contrast, roads also occupy urban space in the Thus, also in CityGML, a carport should be modelled as an instance of the class Building. Since Building is transitively city; however, this space is initially unoccupied as it is accessible by cars, pedestrian, or cyclists. Adding a subclass of OccupiedSpace, a carport is an Occupied- Space as well. However, only in LOD1, the entire volumet- traffic signs or other city furniture objects to the free space results in specific sections of the road becoming ric region covered by the carport would be considered as physically occupied. In LOD1, the occupied space is defined occupied by these objects. Thus, one can also say that occupied spaces are mostly filled with matter; whereas, by the entire carport solid (unless a room would be defined in LOD1 that would model the unoccupied part below the unoccupied spaces are mostly free of matter and, thus, realise free spaces. roof); whereas in LOD2 and LOD3, the solids represent more realistically the really physically occupied space of The classification of feature types into OccupiedSpace the carport. In addition, for all OccupiedSpaces, the normal vectors of the thematic surfaces like the RoofSurface need and UnoccupiedSpace also defines the semantics of the geometries attached to the respective features. For Occu- to point away from the solids, i.e. consistent with the solid geometry. piedSpaces, the attached geometries describe volumes that are (mostly) physically occupied. For UnoccupiedSpaces, In contrast, a room is a physically unoccupied space. In CityGML, a room is represented by the class BuildingRoom the attached geometries describe (or bound) volumes that are (mostly) physically unoccupied. This also has an impact that is a subclass of UnoccupiedSpace. In LOD1, the entire room solid would be considered as unoccupied space, which on the required orientation of surface normals for attached thematic surfaces. For OccupiedSpaces, the normal vectors can contain furniture and installations, though, as is shown in Fig. 4. In LOD2 and 3, the solid represents more realisti- of thematic surfaces must point in the same direction as the surfaces of the outer shell of the volume. For Unoccupied- cally the really physically unoccupied space of the room (possibly somewhat generalised as indicated in the figure). Spaces, the normal vectors of thematic surfaces must point in the opposite direction as the surfaces of the outer shell For all UnoccupiedSpaces, the normal vectors of the bound- ing thematic surfaces like the InteriorWallSurface need to of the volume. This means that from the perspective of an observer of a city scene, the surface normals must always point inside the object, i.e. opposite to the solid geometry. The concepts of Spaces and Space Boundaries are repre- be directed towards the observer. In the case of Occupied- Spaces (e.g. Buildings, Furniture), the observer must be sented in the UML model of the CityGML 3.0 Core module by introducing the two pivotal abstract classes Abstract- located outside the OccupiedSpace for the surface normals being directed towards the observer; whereas in the case Space and AbstractSpaceBoundary as shown in Fig.  5. 1 3 PFG (2020) 88:43–61 47 From the class AbstractSpace, the following subclasses are derived: the classes AbstractPhysicalSpace and Abstract- LogicalSpace to classify spaces into physical and logical spaces as well as the classes AbstractOccupiedSpace and AbstractUnoccupiedSpace to categorise physical spaces into physically occupied and unoccupied spaces. The concrete classes like Building, BuildingRoom, or TrafficSpace are then defined as subclasses of these abstract classes. From the class AbstractSpaceBoundary, the class AbstractThe- maticSurface is derived. It is the superclass for all concrete surface classes like WallSurface, ClosureSurface, WaterSur- face or LandUse. The relation between AbstractSpace and AbstractSpaceBoundary is represented in the UML model Fig. 4 Representation of a room as UnoccupiedSpace in different through an association between both classes. LODs. The red boxes represent solids, the green area represents a sur- The classification of real-world objects into spaces and face. In addition, the normal vectors of the room solid (in red) and the space boundaries is solely based on the semantics of these wall surface (in green) are shown objects and not on their used geometry type, as CityGML Fig. 5 Excerpt from the CityGML 3.0 Core UML model defining the space concept 1 3 48 PFG (2020) 88:43–61 3.0 allows various geometrical representations for objects. In CityGML 3.0 all geometric representations are defined A building, for instance, can be spatially represented by a in the Core module only. This makes (a) data models of 3D solid (e.g. in LOD1), but at the same time, the real-world the thematic modules simpler as they no longer need to geometry can also be abstracted by a single point (LOD0), be associated directly with the geometry classes, and (b) by a 3D point cloud, or by a 3D mesh (LOD3). implementation easier as all spatial concepts have only The space concept was strongly motivated from urban to be implemented once in the Core module and all the- planning, the work on IndoorGML and indoor navigation as matic modules like Building, Relief, WaterBody, etc. are well as the Land Administration Domain Model. By intro- inheriting them. ducing spaces in CityGML, it will become easier to link The space concept supports the expression of explicit CityGML with IndoorGML and to apply analytical frame- topological, geometrical, and thematic relations between works from the urban geography domain like Space Syntax spaces and spaces, spaces and space boundaries, and (Hillier and Hanson 1984) or from the analyses of urban space boundaries and space boundaries. Thus, imple- activities like living, working, or traffic (which are all taking menting the checking of geometric-topological consist- place in or affecting spaces). In addition, the space concept ency will become easier, because most checks can be was inspired by the work of Billen et al. (2012) on defin- expressed and performed on the CityGML Core module ing a generic ontology for the urban space. This ontology and then automatically apply to all thematic modules. partitions the universe into spaces that are classified into When a new thematic module [or an Application Domain physical spaces and fictional spaces. Physical spaces can Extension (ADE)] will be added and its spatial represen- have boundaries and can be divided into sub-spaces. Physi- tations will be expressed using space and space boundary cal sub-spaces, in turn, are classified into penetrable and classes, the validity checks automatically hold also for non-penetrable physical sub-spaces, depending on whether the new thematic module (or ADE). they can be penetrated by an agent such as a human, an Some new application areas could be opened up. For electromagnetic, or a specific behaviour. Real-world objects example, urban planning, urban analytics, autonomous can then be linked to the physical sub-spaces. Buildings, driving and driver assistance systems, and navigation for instance, are considered to have a non-permeable space, in general will benefit from the space concept. Also the whereas rooms are permeable spaces. The concepts defined modelling of the underground (hollow spaces, geologi- in the ontology can be found again in the space concept of cal rock layers and their separating surfaces) could be CityGML 3.0. Physical and fictional spaces are represented very elegantly done in the future using spaces and space in CityGML 3.0 by the classes AbstractPhysicalSpace and boundaries. AbstractLogicalSpace. The non-penetrable and penetrable For the analysis of navigable spaces (e.g. to generate physical sub-spaces are modelled in CityGML 3.0 by the IndoorGML data from CityGML) algorithms can be classes AbstractOccupiedSpace and AbstractUnoccupied- defined on the level of the Core module. These algo- Space; thus, buildings, which are considered by Billen et al. rithms will then work with all CityGML feature classes (2012) as non-penetrable, are defined as occupied spaces and also ADEs as they are derived from the Core. The and rooms, which are considered as penetrable, are defined same is true for other applications of 3D city models as unoccupied spaces. In contrast to the ontology, where listed in Biljecki et al. (2015) such as visibility analyses only physical spaces can have boundaries, all spaces can be including shadow casting or solar irradiation analyses. bounded by thematic surfaces in CityGML 3.0. The space Practitioners and developers do not see much of the concept corresponds also with the observations made in Yan space concept, because the space and space boundary et al. (2019) on the categorization of spaces into indoor and classes are just abstract classes. Only elements represent- outdoor spaces to improve indoor/outdoor navigation. The ing objects from concrete subclasses such as Building, classification in CityGML 3.0 does not go as far as differen- BuildingRoom, or TrafficSpace will appear in CityGML tiating semi-indoor and semi-outdoor spaces as well, how- files. ever, CityGML 3.0 can be used to derive this classification. The modelling in CityGML 3.0 does not focus on model- ling the navigable space, but on an exact representation of 2.2 The CityGML 3.0 LOD Concept spatial objects such as the carport in LOD2/3 as shown in Fig. 3. Nevertheless, CityGML 3.0 also allows for deriving CityGML 3.0 will include a revised Level of Detail (LOD) the navigable space of the carport. This distinguishes the concept which comprises a central definition of all geom - modelling with CityGML 3.0 from the concepts defined in etries in the Core module and the representation of the inte- Yan et al. (2019). rior of city objects at any level of detail. The new space concept offers several advantages: In CityGML 2.0, each module defines the required geometries itself, leading to redundancy, for instance, in 1 3 PFG (2020) 88:43–61 49 Fig. 6 Excerpt from the CityGML 3.0 Core UML model defining the LOD concept. The geometries in CityGML 3.0 are now associated with the classes in the Core model and no longer need to be specified in each thematic module separately the Building, Tunnel, and Bridge modules. To overcome in LOD2 or 3. Details on the changes to the CityGML LOD these redundancies, nearly all geometry representations are concept are provided in Löwner et al. (2016). moved from the thematic modules to the Core module and In addition, the new PointCloud module adds the possi- are associated with the semantic concepts of spaces and bility to use 3D point clouds to represent the geometries of space boundaries, see Fig. 6. The geometry classes from physical spaces and space boundaries. ISO 19107 are used for defining the various geometric rep- resentations. Since all feature types in the thematic modules are defined as subclasses of the space and space boundary 3 Refinement of Constructions classes, they automatically inherit the geometry classes and, and Buildings thus, no longer require direct associations with them. Spaces and all its subclasses like Building, Room, and CityGML 3.0 will contain a new Construction module that TrafficSpace can now be spatially represented as single defines concepts common to all kinds of man-made con - points in LOD0, multi-surfaces in LOD0/2/3, solids in structions like buildings, bridges, and tunnels. This means LOD1/2/3, and multi-curves in LOD2/3. Space bounda- that the module integrates all classes that are similar over ries and all its subclasses such as WallSurface, LandUse, different types of constructions and that are defined sepa- or Relief can now be represented as multi-surfaces in rately in the Building, Bridge, and Tunnel modules in City- LOD0/2/3 and as multi-curves in LOD2/3. GML 2.0. These are, in particular, the various thematic LOD4, which is used for representing the interior of surfaces like RoofSurface, GroundSurface, or WallSurface, objects in CityGML 2.0 (like indoor modelling for buildings and the openings Door and Window. Figure  7 shows the and tunnels), has been removed; only the LODs 0/1/2/3 will Construction module. The module defines a class Abstract- remain. Instead, the interior of objects can be expressed now Construction as subclass of AbstractOccupiedSpace which integrated with the LODs 0/1/2/3. This allows, for instance, is associated with the different thematic surfaces. Buildings, the representation of floor plans in LOD0 (Konde et  al. bridges, and tunnels, in turn, are defined as subclasses of 2018). It will even be possible to model the outside shell of the class AbstractConstruction, inheriting in this way auto- a building in LOD1, while representing the interior structure matically the associations with all thematic surfaces. This 1 3 50 PFG (2020) 88:43–61 Fig. 7 CityGML 3.0 Construction module leads to a substantial simplification of the UML models of components are bounded by the various thematic surfaces the Building, Bridge, and Tunnel modules. In addition, for RoofSurface, WallSurface, etc. as well. Thus, space and representing man-made structures that are neither buildings, space boundary establish the explicit connection between nor tunnels, nor bridges (e.g. large chimneys or city walls), (volumetric) constructive elements and their thematic the new class OtherConstruction has been introduced as sub- boundary surfaces. class of AbstractOccupiedSpace. The interoperability of CityGML with INSPIRE is To facilitate a more direct mapping of IFC onto City- improved by adopting attributes from the INSPIRE Building GML, a new feature type AbstractConstructiveElement is data theme (JRC 2013) which allow for specifying multiple introduced and corresponding subclasses BuildingConstruc- elevation levels and measured heights. In addition, various tiveElement, BridgeConstructiveElement, and TunnelCon- events and their dates can be specified, such as the date a build- structiveElement are defined in the modules Building (see ing permit was issued, the start of renovation, or the end of Fig. 8), Bridge, and Tunnel. These feature types allow for renovation (see corresponding attributes in the class Abstract- mapping constructive elements from BIM data sets given Construction in Fig. 7). in the IFC standard (e.g. the IFC classes IfcWall, IfcRoof, Doors and windows have a clearer semantics now. The IfcBeam, IfcSlab, etc.) onto CityGML. These volumetric classes Window and Door represent now filling elements; in 1 3 PFG (2020) 88:43–61 51 Fig. 8 CityGML 3.0 Building module addition, the classes WindowSurface and DoorSurface are object; however, a flood incident involves variations in the introduced to represent filling surfaces. location and shape of water. There might be other prop- The Building module introduces a new class AbstractBuild- erties which change w.r.t. thematic data of city objects, ingSubdivision, which is modelled as a subclass of Abstract- e.g. hourly variations in energy or gas consumption of a LogicalSpace, and the two specialisations BuildingUnit and building or changing the building usage from residential to Storey to allow for representing building units (like apart- commercial. Some properties involve changes in appear- ments) and storeys. ances over the period of time, such as building textures changing over years or traffic cameras recording videos of moving traffic over definite intervals. 3D city models com- 4 Dynamics of Changing Cities prise relevant real-world entities and also represent inter- relationships between objects. Such interrelationships may In general, a city object can have properties related to its also change over time. Hence, it is important to consider geometry, topology, semantics, and appearance and all of that the representation of time-varying data is required to these properties may change w.r.t. time. For example, a be associated with these different properties. construction event leads to the change in geometry of a Temporal variations involve time points mapped onto the building (i.e. addition of a new building floor or demoli- specific attributes (i.e. spatial, thematic, topology, or appear - tion of an existing door). The geometry of an object can ance). Such mappings are often realised by discrete record- be further classified according to its shape, location, and ings or by interpolation functions and involve quantitative extent, which can also be changed over time. A moving changes which can be defined as a function of time. For car object involves changing only the location of the car example, varying energy consumption values of a building 1 3 52 PFG (2020) 88:43–61 can be determined for specific points of time (1) in the past objects), and (3) real-time sensor observations. In this case, by querying a database for historic data, (2) in the present only some of the properties of otherwise static objects need by querying a real-time sensor or IoT device, and (3) in the to represent such time-varying values. future by a simulation software. However, there are other scenarios where features begin or cease to exist over differ -4.1 Versioning of Cities ent time intervals, for example, addition of a new building or demolition of an old building. Such scenarios involve Within the new Versioning module, CityGML 3.0 introduces qualitative changes and are fundamentally different from bitemporal timestamps for all objects in alignment with the the quantitative changes. Such changes can not be defined INSPIRE data specifications. Besides the attributes creation- as a function of time on a feature’s property as the state of Date and terminationDate from CityGML 2.0, which refer features changes. Hence, it is also essential to consider that to the time period in which a specific version of an object semantic 3D city models handle both quantitative and quali- is an integral part of the 3D city model, all objects now tative changes within cities/city objects. Since both quanti- can additionally have the attributes validFrom and validTo, tative and qualitative changes involve variations w.r.t. time, which represent the lifespan a specific version of an object it is also important to determine if they can be handled by has in the real world. Furthermore, each geographic feature the same mechanisms. A detailed discussion on the require- is being provided with two identifiers: the identifier property ments of applications regarding the support of dynamic data which is stable along the lifetime of the real-world object, is given in Chaturvedi and Kolbe (2019). and the gml:id attribute which is to mark the respective ver- In the current version of CityGML (version 2.0), such sion of the object. In this way, not only the current version of time variations are not supported. Hence, two new concepts a 3D city model, but also its entire history can be represented (Versioning module and Dynamizer module) are proposed in CityGML and exchanged even within a single file. The for CityGML 3.0 to manage time-dependent properties. module defines two new feature types: Version, which can be The Versioning module manages qualitative changes that used to explicitly define named states of the 3D city model are slower in nature, e.g. (1) the history or evolution of cit- and denote all the specific versions of objects belonging to ies such as construction or demolition of buildings, and (2) such states, and VersionTransition, which allows to explicitly managing multiple versions of the city models. The Dynam- link different versions of the 3D city model by describing the izer module manages quantitative changes representing high reason of change and the modifications applied. Details on frequent or dynamic variations of object properties, e.g. vari- the versioning concept are given in Chaturvedi et al. (2017). ations of (1) thematic attributes such as changes of physical The versioning concept has already been used and further quantities (energy demands, temperature, solar irradiation extended by a proposed proof-of-concept called UrbanCo- levels), (2) spatial properties such as change of a feature’s 2Fab (Samuel et al. 2016) to represent multiple viewpoints geometry, with respect to shape and location (moving of urban evolution. Fig. 9 An instance example of versions representing modifica- tions of a building 1 3 PFG (2020) 88:43–61 53 The following example illustrates one such possibility of also allows the different versions to be used in an interoper - modification scenarios. As shown in Fig.  9, a building with able exchange format and the exchange of all versions of the major ID B1020 has a function property Office and one a repository within a single dataset. Such a dataset can be of its building parts with major ID BP12 has a roofType used by different software systems to visualise and work property Flat. Over a period of time, the building function with all the versions. The approach not only addresses the property is changed to Living which has been captured in implementation of versionable CityGML models but also version 2. Furthermore, at a point in time, the roofType prop- considers new aspects to previous work such as managing erty of the same building has been changed to Saddle. Using multiple histories or multiple interpretations of the past of a the Versioning module, version management can easily be city. Also, collaborative work is supported since the Version- supported in a single CityGML data set as shown in Fig. 10. ing module provides all functionalities to represent a tree of The building object in version 1 can be denoted as B1020_t1 workspaces as version control systems like git or svn. The at a specific point in time t1. XPath can be used with XLink proposed UML model handles versions and version transi- to retrieve all the instances of the same building object. The tions as feature types, which allows the version management instance data can also include version elements for manag- to be completely handled using the OGC Web Feature Ser- ing different versions of an object. However, due to limited vice (Vretanos 2010). No extension of other OGC standards space in this paper, the example illustrates a simple version is required. management where it is sufficient to just use the bi-temporal time attributes and the major/minor IDs. The advantage of this approach is that it not only facili- tates the data model for supporting different versions, but Fig. 10 Representation of dif- ferent versions of city objects within one CityGML dataset encoded in GML 1 3 54 PFG (2020) 88:43–61 2. Dynamizer delivers a method to enhance static city mod- 4.2 Representation of Time‑Dependent Properties els by dynamic property values. It references a specific property (e.g. spatial, thematic or appearance properties) The new Dynamizer module has been developed to improve the usability of CityGML for different kinds of simulations of a specific object within a 3D city model providing dynamic values overriding the static value of the refer- as well as to facilitate the integration of sensors with 3D city models. Both, simulations and sensors provide dynamic enced object attribute. 3. Dynamizer objects establish explicit links between sen- variations of some measured or simulated properties like, for example, the electricity consumption of a building or the sor/observation data and the respective properties of city model objects that are measured by them. By mak- traffic density within a road. The variations of the value are typically represented using time series data. The data source ing such explicit links with city object properties, the semantics of sensor data become implicitly defined by of the time series data is either sensor observations (e.g. from a smart meter), pre-recorded load profiles (e.g. from the city model. an energy company), or the results of some simulation run. As shown in Fig.  11, Dynamizers serve three main In this way, dynamizers can be used to inject dynamic variations of city object properties into an otherwise static purposes: representation. The advantage in using such approach is that it allows only selected properties of city models to be 1. Dynamizer is a data structure to represent dynamic val- ues in different and generic ways. Such dynamic values made dynamic. If an application does not support dynamic data, it simply does not allow/include these special types may be given by (1) tabulation of time/value pairs using its AtomicTimeseries class, (2) patterns of time/value of features. Dynamizers have already been implemented as an pairs based on statistical rules using its CompositeTime- series class, and (3) retrieving observations directly Application Domain Extension (ADE) for CityGML 2.0 and were employed in the OGC Future City Pilot Phase 1. from external sensor/IoT services using its SensorCon- nection class. The values can be obtained from sensors, More details about the UML diagram and instance docu- ments are given in Chaturvedi and Kolbe (2017). simulation specific databases, and also external files such as CSV or Excel sheets. Fig. 11 Conceptual representa- tion of Dynamizers allowing (1) enhancing the properties of city objects by overriding their static values, and (2) the representa- tion of time-variant values from sensors, simulation specific databases, and external files. Image taken from Chaturvedi and Kolbe (2016) 1 3 PFG (2020) 88:43–61 55 TransportationSpace. In addition, they can be subdivided 5 Further New Concepts into sections, which can be regular road, track or railway legs, intersection areas, or roundabouts (class Section and In addition to the new and revised modules and concepts Intersection). Intersection areas as well as roundabouts can presented above, two further modules provide interesting belong to multiple road or track objects avoiding the redun- new additions to CityGML 3.0: the Transportation module dant representation of shared spaces. As in CityGML 2.0, and the PointCloud module. transportation objects can be subdivided into TrafficArea (e.g. driving lanes, pedestrian zones, and cycle lanes) and 5.1 Transportation Module AuxiliaryTrafficArea (e.g. kerbstones, middle lanes, and green areas). To adapt the semantics of the Transportation The Transportation module defines classes for the repre- module to the CityGML 3.0 space concept, the classes Traf- sentation of central elements of the traffic infrastructure. To ficSpace and AuxiliaryTrafficSpace were introduced in addi- improve the usability of CityGML transportation objects tion to TrafficArea and AuxiliaryTrafficArea, the two areas with traffic and driving simulations, driving assistance sys- representing now the bottom boundaries of the two spaces. tems, autonomous driving, as well as with road and railway Each traffic space can have an optional ClearanceSpace. facility management systems, the data model has been sub- This is exemplified in Fig.  13. A road consisting of a driv- stantially revised. ing lane and two sidewalks is represented. The traffic spaces Figure  12 illustrates the new Transportation module. (in blue) define the free spaces above the driving lane and Transportation objects like roads, tracks, or railways are the sidewalks; whereas, the traffic areas (in green) represent defined now as concrete subclasses of the abstract class Fig. 12 CityGML 3.0 Transportation module 1 3 56 PFG (2020) 88:43–61 Fig. 14 CityGML 3.0 PointCloud module 6 New Applications for CityGML 3.0 6.1 Sensors and IoT in Cities Fig. 13 Representation of a road in CityGML 3.0 1 2 A large number of cities such as Singapore, Munich, Hel- 3 4 sinki, and Melbourne are developing Digital Twins to the ground surfaces of the traffic spaces. In Germany, for improve the operational efficiency of cities. A Digital Twin example, roads typically have a free space height of 4.5 m (Batty 2018; Datta 2017) is a digital counterpart of a physi- and sidewalks of 2.5 m. In addition, clearance spaces (in cal asset, which collects information via sensors and IoT red) are represented. devices, and applies advanced analytics and artificial intel- Transportation objects can now have an areal as well as a ligence to gain real-time insights about the physical asset’s center line representation for each LOD. In the highest LOD performance, operation or profitability. These sensors can (LOD3), each lane is represented by an individual traffic be stationary such as Smart Meters and weather stations. space object. Each traffic space can be linked to predeces- Some of the sensors can also be non-stationary such as air- sor and successor traffic spaces. This information is typi- quality sensors mounted on a car measuring air pollution cally used (and required) in navigation systems and traffic over different parts of a city at different time intervals or simulations (cf. Ruhdorfer et al. 2018; Labetski et al. 2018). pedestrian flow analysis involving pedestrians moving into According to Labetski et al. (2018) also Waterway was intro- or out of a stadium (e.g. before or after a scheduled football duced as new subclass of TransportationSpace. In addition, match). Bridging the virtual and physical worlds together in the new class Marking allows for adding road markings to this way can also help Smart City applications to improve the road surface and the classes Hole and HoleSurface can decision-making and reduce risks by predicting issues before be used to represent, for instance, roadway damages or man- occurrence. holes including their surfaces. For further information and Several Smart City initiatives also highlight the impor- examples on the new Transportation module please refer to tance of integrating real-time sensors and IoT devices with Beil and Kolbe (2017). city objects. The Smart District Data Infrastructure (SDDI) proposed by Moshrefzadeh et al. (2017) allows integrat- 5.2 PointCloud Module ing diverse components such as stakeholders, sensors, IoT devices and simulation tools with a virtual district model In addition to the geometries defined in the Core module, representing the physical reality of the district. To access the geometry of physical spaces and of thematic surfaces can distributed resources, the framework uses a well-defined set now also be provided by 3D point clouds using MultiPoint of OGC-based service interfaces such as Web Feature Ser- geometry. This allows, for example, to spatially represent the vice (Vretanos 2010), Sensor Observation Service (Bröring building hull, a room within a building or a single wall sur- et al. 2012) and SensorThings API (Liang et al. 2015) as face just by a point cloud. All thematic feature types includ- well as a Catalogue Service. The framework also facilitates ing transportation objects, vegetation, city furniture, etc. can privacy, security and controlled access to all stakeholders be spatially represented by point clouds, too. In this way, the ClearanceSpace of a road or railway could, for instance, https ://www.nrf.gov.sg/progr ammes /virtu al-singa pore. https ://muenc hen.digit al/blog/digit aler-zwill ing-in-muenc hen-ein- be modelled directly from the result of a mobile laser scan- leuch tturm proje kt-auf-dem-weg-zur-digit alen-metro pole/. ning campaign. Point clouds can either be represented inline https ://aec-busin ess.com/helsi nki-is-build ing-a-digit al-twin-of-the- within a CityGML file or just reference an external file of city/. some common types such as LAS or LAZ. Figure 14 shows https ://www.itnew s.com.au/news/vic-govt-to-build -state s-first -digit the new PointCloud module. al-twin-52818 7. 1 3 PFG (2020) 88:43–61 57 and the respective components by establishing proper large CityGML datasets on top of spatial relational database authorization and authentication mechanisms (Chaturvedi management systems (SRDBMS) such as Oracle Spatial and et al. 2019a). PostgreSQL. It includes a Java front-end application named Since all of the above-mentioned city initiatives consider 3DCityDB Importer/Exporter for importing and exporting semantic 3D city models as an integral component of their CityGML datasets with arbitrary file sizes. It also allows infrastructures, it is highly important that the 3D city objects exporting CityGML objects in the form of 3D visualiza- support seamless integration with sensors and IoT devices. tion formats (such as KML, COLLADA, and glTF) enabling CityGML Dynamizers allow defining explicit links to these them to be viewed and interactively explored in web appli- real-time sensor observations directly within city objects. cations such as the 3DCityDB Web Map Client or Google In this way, the attribute of the respective city object can Earth. The implementation developed by Chaturvedi et al. also be associated with time-dynamic sensor observations. (2019b) allows storing Dynamizer timeseries data (such as For example, if a building has an indoor sensor installed for solar potential simulation results of a building’s roof sur- measuring real-time temperature or humidity and the indoor face) along with other static properties of the same building sensor’s readings are accessible via standardised web ser- in the 3DCityDB. It also enables CityGML Viewers such as vices such as OGC Sensor Web Enablement (Bröring et al. the 3DCityDB Web Map Client to access static data using 2011), FIWARE (FIWARE 2018), or any other proprietary the OGC Web Feature Service (Vretanos 2010) interface API, Dynamizers can be defined for the specific building or and dynamic data using the OGC SWE interfaces such as room having explicit links to those sensor-based services, the OGC Sensor Observation Service (Bröring et al. 2012) and the respective temperature/humidity attribute of the and the OGC SensorThings API (Liang et al. 2015) in an building can be overridden by the real-time sensor observa- integrated fashion with the help of the newly developed tions (see Fig. 15). InterSensor Service (Chaturvedi and Kolbe 2019). 6.2 Improved Simulation Support 6.3 Usage of the Space Concept CityGML Dynamizers also enable 3D city models for an The new space concept introduced in CityGML 3.0 can be improved simulation support. The Dynamizer ADE for useful in various applications such as enhancing the conver- CityGML 2.0 (Chaturvedi and Kolbe 2017) has already sion of IFC into CityGML. In particular the new volumetric been tested successfully for a solar potential simulation to feature types BuildingConstructiveElement, BridgeCon- assess and estimate solar energy production for the roofs and structiveElement, and TunnelConstructiveElement that are façades of 3D building objects. The simulation tool operates defined as subclasses of AbstractOccupiedSpace facilitate on 3D models structured according to the CityGML standard the mapping of constructive elements from IFC data sets and generates the monthly and yearly estimates of direct, dif- to CityGML. Walls, for instance, are represented in IFC as fuse, and global irradiation values for the building surfaces. volumetric objects; whereas in CityGML 2.0, only the exte- The dynamic simulation results can be represented using the rior and interior surfaces of walls are represented as separate international OGC TimeseriesML standard (Tomkins and features. This means that these surfaces need to be extracted Lowe 2016) within Dynamizer AtomicTimeseries class. The when mapping IFC to CityGML 2.0. With the newly intro- advantage of such representation of simulation results is that duced constructive element classes this extraction could be it allows modelling precise description of timeseries and avoided, because a direct mapping from IFC onto CityGML enables cross-domain exchanging of simulation results along can now be achieved simply by mapping the volumetric IFC with city objects (Fig. 16). It is also helpful to create a snap- objects to volumetric CityGML objects. Figure 17 shows shot of the state(s) of a city model including time-varying a building of the Technical University of Munich that was data for documentation and archiving. Similarly, Dynamiz- converted from IFC to CityGML 3.0. Visible are only the ers are also helpful in representing moving objects in traffic BuildingConstructiveElement objects that have been created simulations (Ruhdorfer 2017; Santhanavanich et al. 2018). from the IFC classes IfcWall, IfcRoof, IfcBeam, and IfcSlab. Furthermore, Chaturvedi et  al. (2019b) proposed an The conversion was executed using the FME-based ifc-to- implementation that allows managing and visualising static citygml3 conversion tool available from TUM-GIS (2019a). and dynamic properties of semantic 3D city models in an Similarly, the semantics of the IFC class IFCSpace is integrated fashion. The 3D City Database (also known as a physically unoccupied space to represent rooms. The 3DCityDB ) (Yao et al. 2018) is an Open Source software class BuildingRoom represents the equivalent concept in suite, which allows storing, representing, and managing City GML as it is a subclass of AbstractUnoccupiedSpace. 5 6 http://www.3dcit ydb.org. http://www.inter senso rserv ice.org/. 1 3 58 PFG (2020) 88:43–61 Fig. 15 Defining direct links to sensors within Dynamizer feature type. The file shows an excerpt of a CityGML dataset encoded in GML Fig. 17 BuildingConstructiveElement objects created from the IFC classes IfcWall, IfcRoof, IfcBeam, and IfcSlab Fig. 16 The standardised timeseries representation of monthly irradi- House have been converted into BuildingRoom objects in ation values of a building. This demo is accessible from http://manch CityGML 3.0. ester .virtu alcit ymap.de/ 6.4 Conversion of CityGML 2.0 into CityGML 3.0 Thus, IFCSpace objects can be mapped onto Building- Section 1 mentions that it is possible to convert every City- Room objects without change of semantics. This is shown GML 1.0 and 2.0 dataset into CityGML 3.0 by applying in Fig. 18, where IFCSpace objects of the well-known FZK 1 3 PFG (2020) 88:43–61 59 module, the new modules Construction, Versioning, and Dynamizer, as well as the revised Building and Transporta- tion modules. In addition, CityGML 3.0 is modelled ISO- compliant and, thus, allows for automatically deriving the GML application schemas from the UML model by applying a model-driven approach. Several implementations already exist or are currently being created for CityGML 3.0. All software systems that Fig. 18 BuildingRoom objects created from the IFC class IfcSpace can deal with generic GML3 can also read CityGML 3.0 data sets, amongst others FME, deegree, GDAL, GMLAS, and SupportGIS. The citygml2-to-citygml3 conversion tool can create CityGML 3.0 data sets from CityGML 2.0 data sets. The CityGML-3-to-Java-objects library citygml4j is currently being implemented by Claus Nagel for CityGML 3.0. An adaption of the 3DCityDB to support CityGML 3.0 will be carried out in the future. Successful application of CityGML 3.0 was also demonstrated at the OGC CityGML Hackathon in June 2019 in London as well as at the OGC CityGML Challenge in October 2019 in Manchester. Like with CityGML 2.0, the modular specic fi ation allows that applications do not have to implement all CityGML modules. For example, not only the modules Dynamizer, Versioning, or PointCloud, but also some thematic modules can be left out when not required. The entire CityGML 3.0 development is subject to final votings of the CityGML SWG as well as of the OGC OAB Fig. 19 The city model of Berlin Moabit represented in CityGML 3.0 (Open Architecture Board) and the Technical Committee. The UML models provided in this paper may still undergo slight changes until the finalisation of the specification. syntactical transformations only. This transformation can, However, we do not expect major changes anymore. for instance, be carried out using an XSLT-based conver- sion tool, such as the citygml2-to-citygml3 conversion tool Acknowledgements Open Access funding provided by Projekt DEAL. provided from TUM-GIS (2019b). This tool gives data We would like to thank the other members of the OGC CityGML SWG Modelling Subgroup Claus Nagel, Steve Smyth, Gilles Gesquière, providers and software implementers the possibility to (a) Emmanuel Devys, Heidi Valparys, Friso Penninga, Volker Coors, Sisi see how their existing datasets would look like in City- Zlatanova, Helga Tauscher and Carsten Roensdorf for their valuable GML 3.0, and (b) adapt their software implementations contributions and discussions in the development of CityGML 3.0. and work with CityGML 3.0 data, and (c) reassure them We also thank the modelling working group of SIG 3D of GDI-DE, in particular Gerhard Gröger, Joachim Benner, Karl-Heinz Häfele, Marc- on the backwards compatibility of the conceptual model of Oliver Löwner, Jürgen Ebbinghaus, and Heinrich Geerling as well as CityGML 3.0 with CityGML 2.0 by demonstrating lossless the further contributors to the CityGML 3.0 work packages includ- data conversion. The tool currently supports the conversion ing Filip Biljecki and Linda van den Brink. Special thanks go to Son of Buildings, CityFurniture, and Appearances and is gradu- Nguyen for his work on the citygml2-to-citygml3 conversion tool and Daniel Härpfer for his work on the ifc-to-citygml3 converter. ally being extended to support the other modules as well. Figure 19 visualises the city model of Berlin Moabit that Open Access This article is licensed under a Creative Commons Attri- was converted from CityGML 2.0 into CityGML 3.0 using bution 4.0 International License, which permits use, sharing, adapta- the citygml2-to-citygml3 conversion tool. tion, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are 7 Conclusions and Outlook included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in This paper introduces the new and revised concepts that the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will are to become part of the next major CityGML version 3.0. need to obtain permission directly from the copyright holder. To view a Of particular importance are the new space concept and copy of this licence, visit http://creativecommons.org/licenses/by/4.0/. the revised LOD concept that both are defined in the Core 1 3 60 PFG (2020) 88:43–61 ISO 16739 (2013) ISO 16739:2013 industry foundation classes (IFC) References for data sharing in the construction and facility management industries AdV (2009) Documentation on the modelling of geoinformation of ISO 19152 (2012) ISO/TS 19152:2012 geographic information—land official surveying and mapping (GeoInfoDoc), version 6.0.1 administration domain model Batty M (2018) Digital twins. Environ Plan B Urban Anal City Sci ISO 19505-2 (2012) ISO/IEC 19505-2:2012 information technology— 45(5):817–820 object management group unified modeling language (OMG Beil C, Kolbe TH (2017) CityGML and the streets of New York—a UML)—part 2: superstructure proposal for detailed street space modelling. ISPRS Ann Photo- JRC (2013) D2.8.III.2 Data specification on buildings—technical gram Remote Sens Spat Inf Sci IV-4/W5:9–16 guidelines Biljecki F, Stoter J, Ledoux H, Zlatanova S, Çöltekin A (2015) Appli- JRC (2014) INSPIRE D2.5: generic conceptual model, version 3.4 cations of 3d city models: state of the art review. ISPRS Int J Konde A, Tauscher H, Biljecki F, Crawford J (2018) Floor plans in Geo-Inf 4(4):2842–2889 CityGML. ISPRS Ann Photogramm Remote Sens Spat Inf Sci Billen R, Zaki CE, Servières M, Moreau G, Hallot P (2012) Developing IV-4/W6:25–32 an ontology of space: Application to 3D city modeling. In: Leduc Kutzner T, Kolbe TH (2018) CityGML 3.0: Sneak preview. In: Ker- T, Moreau G, Billen R (eds) Usage, usability, and utility of 3D sten TP, Gülch E, Schiewe J, Kolbe TH, Stilla U (eds) PFGK18- city models—European COST Action TU0801. EDP Sciences, Photogrammetrie-Fernerkundung-Geoinformatik-Kartographie, Nantes, vol 02007. https ://hal.archi ves-ouver tes.fr/hal-01521 445 37. Jahrestagung in München 2018, Deutsche Gesellschaft für Bröring A, Echterhoff J, Jirka S, Simonis I, Everding T, Stasch C, Photogrammetrie, Fernerkundung und Geoinformation e.V., Pub- Liang S, Lemmens R (2011) New generation sensor web enable- likationen der Deutschen Gesellschaft für Photogrammetrie, Fern- ment. Sensors 11(3):2652–2699 erkundung und Geoinformation (DGPF) e.V., vol 27, pp 835–839 Bröring A, Stasch C, Echterhoff J (2012) Sensor Observation Service Labetski A, van Gerwen S, Tamminga G, Ledoux H, Stoter J (2018) Interface Standard, OGC Doc. No. 12-006. http://www.openg A proposal for an improved transportation model in CityGML. eospa tial.org/stand ards/sos. Accessed 04 May 2019 ISPRS—Int Arch Photogramm Remote Sens Spat Inf Sci XLII-4/ Chaturvedi K, Kolbe TH (2016) Integrating dynamic data and sen- W10:89–96 sors with semantic 3D city models in the context of smart cities. Lee et al (2016) OGC IndoorGML, version 1.0.2 In: Proceedings of the 11th international 3D geoinfo conference, Liang S, Huang CY, Khalafbeigi T (2015) SensorThings API Part 1: Athens, ISPRS Annals of the Photogrammetry, Remote Sens- Sensing, OGC Doc. No. 15-078r6. https ://www.openg eospa tial. ing and Spatial Information Sciences, vol IV-2/W1. https ://doi. org/stand ards/senso rthin gs. Accessed 04 May 2019 org/10.5194/isprs -annal s-IV-2-W1-31-2016 Löwner MO, Gröger G, Benner J, Biljecki F, Nagel C (2016) Proposal Chaturvedi K, Kolbe TH (2017) Future City Pilot 1 Engineering for a new LOD and multi-representation concept for CityGML. Report, OGC Doc. No. 19-098. http://docs.openg eospa tial.org/ ISPRS Ann Photogramm Remote Sens Spat Inf Sci IV-2/W1:3–12 per/16-098.html. Accessed 22 Dec 2018 Moshrefzadeh M, Chaturvedi K, Hijazi I, Donaubauer A, Kolbe TH Chaturvedi K, Kolbe TH (2019) Towards establishing cross-platform (2017) Integrating and managing the information for smart sus- interoperability for sensors in smart cities. Sensors 19(3) tainable districts—the smart district data infrastructure (SDDI). Chaturvedi K, Smyth CS, Gesquière G, Kutzner T, Kolbe TH (2017) In: Kolbe TH, Bill R, Donaubauer A (eds) Geoinformations- Managing versions and history within semantic 3D city models for systeme 2017-Beiträge zur 4. Münchner GI-Runde, Wichmann the next generation of CityGML. In: Advances in 3D geoinforma- Verlag tion. Springer, pp 191–206 OGC (2019a) CityGML 3.0 conceptional model. https ://githu b.com/ Chaturvedi K, Matheus A, Nguyen SH, Kolbe TH (2019a) Securing openg eospa tial/CityG ML-3.0CM. Accessed 14 Sep 2019 spatial data infrastructures for distributed smart city applications OGC (2019b) CityGML 3.0 encodings. https://git hub.com/openg eospa and services. Future Gen Comput Syst 101:723–736 tial/CityG ML-3.0Enco dings /. Accessed 14 Sep 2019 Chaturvedi K, Yao Z, Kolbe TH (2019b) Integrated management and Ruhdorfer R (2017) Kopplung von Verkehrssimulation und seman- visualization of static and dynamic properties of semantic 3D tischen 3D-Stadtmodellen in CityGML. Master’s thesis, Technis- city models. In: Proceedings of the 4th international conference che Universität München, Chair of Geoinformatics on smart data and smart cities, ISPRS, Kuala Lumpur, ISPRS Ruhdorfer R, Willenborg B, Sindram M (2018) Coupling of traffic Archives of the Photogrammetry, Remote Sensing and Spatial simulations and semantic 3d city models. gisScience 3:101–109 Information Sciences Samuel J, Périnaud C, Gay G, Servigne S, Gesquière G (2016) Repre- Datta SPA (2017) Emergence of digital twins—is this the march of sentation and visualization of urban fabric through historical doc- reason? J Innov Manag 5(3):14–33 uments. In: Catalano CE, Luca LD (eds) Eurographics workshop Elfes A (1989) Using occupancy grids for mobile robot perception and on graphics and cultural heritage. The Eurographics Association. navigation. Computer 22(6):46–57 https ://doi.org/10.2312/gch.20161 399 European Parliament and Council (2007) Directive 2007/2/EC of the Santhanavanich T, Schneider S, Rodrigues P, Coors V (2018) Integra- European Parliament and of the council of 14 March 2007 estab- tion and visualization of heterogeneous sensor data and geospatial lishing an infrastructure for spatial information in the European information. ISPRS Ann Photogramm Remote Sens Spat Inf Sci Community (inspire). Off J Eur Union 50(L 108):1–14 IV-4/W7:115–122 FIWARE (2018) Open source platform for the smart digital future. Smith B, Varzi AC (2000) Fiat and bona fide boundaries. Philos Phe- https ://www.fiwar e.org/. Accessed 16 May 2018 nomenol Res 60(2):401–420. https ://doi.org/10.2307/26534 92 Gröger et al (2012) OGC City Geography Markup Language (Cit- Sparx Systems (2015) Enterprise architect. http://www .spar x sy s te yGML) Encoding Standard, Version 2.0.0 ms.com/produ cts/ea/index .html. Accessed 04 Oct 2015 Hillier B, Hanson J (1984) The social logic of space. Cambridge Uni- Tomkins J, Lowe D (2016) Timeseries profile of observations and versity Press, Cambridge. https ://doi.org/10.1017/CBO97 80511 measurements, OGC Document No. 15-043r3. http://www.openg 59723 7 eospa tial.org/stand ards/tsml. Accessed 09 Sep 2018 Interactive Instruments (2019) Shapechange. https://shape c hange.ne t/. TUM-GIS (2019a) citygml2-to-citygml3. https ://githu b.com/tum-gis/ Accessed 05 Sep 2019 cityg ml2-to-cityg ml3. Accessed 05 Sep 2019 1 3 PFG (2020) 88:43–61 61 TUM-GIS (2019b) ifc-to-citygml3. https:/ /github. com/tum-gis/ifc-to- Yao Z, Nagel C, Kunde F, Hudra G, Willkomm P, Donaubauer A, cityg ml3. Accessed 05 Sep 2019 Adolphi T, Kolbe TH (2018) 3DCityDB—a 3D geodatabase solu- Vretanos PA (2010) Opengis web feature service 2.0 interface stand- tion for the management, analysis, and visualization of semantic ard OGC document no. 09-025r1. http://www.opengeospa tial.or g/ 3D city models based on CityGML. Open Geospat Data Softw stand ards/wfs. Accessed 02 Nov 2018 Stand 3(5):1–26 W3C (2014) Rdf 1.1 specifications. https ://www .w3.org/s t and ar ds/ techs /rdf#w3c_all. Accessed 04 Oct 2015 Yan J, Diakité AA, Zlatanova S (2019) A generic space definition framework to support seamless indoor/outdoor navigation sys- tems. Trans GIS 23(6):1273–1295 1 3 http://www.deepdyve.com/assets/images/DeepDyve-Logo-lg.png PFG – Journal of Photogrammetry, Remote Sensing and Geoinformation Science Springer Journals

Loading next page...
 
/lp/springer-journals/citygml-3-0-new-functions-open-up-new-applications-Zr7AIKwafQ
Publisher
Springer Journals
Copyright
Copyright © The Author(s) 2020
ISSN
2512-2789
eISSN
2512-2819
DOI
10.1007/s41064-020-00095-z
Publisher site
See Article on Publisher Site

Abstract

The development of the next major version 3.0 of the international OGC standard CityGML is nearing its end. CityGML 3.0 will come up with a variety of new features and revisions of existing modules that will increase the usability of CityGML for more user groups and areas of application. This includes a new space concept, a revised level-of-detail (LOD) concept, the representation of time-dependent properties, the possibility to manage multiple versions of cities, the representation of city objects by point clouds, an improved modelling of constructions, the representation of building units and storeys, an improved representation of traffic infrastructure as well as a clear separation of the conceptual model and the data encod- ings that allow for providing further encoding specifications besides GML. This paper gives an overview of these new and revised concepts, and illustrates their application through selected use cases. Keywords CityGML 3.0 · 3D city models · Space concept Zusammenfassung CityGML 3.0: Neue Funktionen eröffnen neue Anwendungen. Die Entwicklung der nächsten Hauptversion 3.0 des internationalen OGC-Standards CityGML nähert sich dem Ende. CityGML 3.0 wird mit einer Vielzahl an neuen Funktionen und der Überarbeitung bestehender Module aufwarten, die die Benutzerfreundlichkeit von CityGML für weitere Benutzer gruppen und Anwendungsbereiche verbessern. Dazu gehören ein neues Space-Konzept, ein überarbeitetes Level-of-Detail (LOD)-Konzept, die Darstellung von zeitabhängigen Eigenschaften, die Möglichkeit, mehrere Versionen von Stadtmodellen gleichzeitig zu verwalten, die Darstellung von Stadtobjekten durch Punktwolken, eine verbesserte Modellierung von sonstigen Bauwerken, die Darstellung von Gebäudeeinheiten und Etagen, eine verbesserte Darstellung der Verkehrsinfrastruktur sowie eine klare Trennung des konzeptuellen Modells von der Datenhaltung, die es erlaubt, neben GML weitere Datenformate bereitzustellen. Dieser Artikel gibt einen Überblick über die neuen und überarbeiteten Konzepte und veranschaulicht ihre Anwendung anhand ausgewählter Beispiele. 1 Overview and Development of CityGML city furniture, water bodies, and vegetation. One well-known 3.0 standard for modelling, storing, and exchanging semantic 3D city models is the international standard CityGML issued Semantic 3D city models are nowadays commonly used for by the Open Geospatial Consortium (OGC) (Gröger et al. representing the real-world entities of cities and landscapes, 2012). The current version 2.0 of the standard was adopted such as buildings, bridges, tunnels, transportation objects, by OGC in March 2012. To increase the usability of City- GML for more user groups and areas of application, the OGC CityGML SWG and the Special Interest Group 3D * Tatjana Kutzner (SIG 3D) of the initiative Geodata Infrastructure Germany kutzner@tum.de (GDI-DE) started in 2013 to work on the next major version Kanishk Chaturvedi CityGML 3.0. kanishk.chaturvedi@tum.de Since the release of CityGML 2.0, several change Thomas H. Kolbe requests have been submitted to OGC. Further require- thomas.kolbe@tum.de ments and ideas were gathered and discussed at an interna- tional workshop jointly hosted by OGC and SIG 3D in June Chair of Geoinformatics, Technical University of Munich, 80333 Munich, Germany Vol.:(0123456789) 1 3 44 PFG (2020) 88:43–61 2013. Both, the outcomes of this discussion and the change requests, were organised into 14 Work Packages (WPs) that defined the overall work scope for CityGML 3.0. Persons interested in participating could do so as either work pack- age lead, editor, co-editor, contributor, or reviewer. Some WPs consistently progressed and produced useful results, whereas other WPs were not active at all. By the end of 2017, the results of the active WPs were integrated into a consolidated version of the CityGML 3.0 Conceptual Model (Kutzner and Kolbe 2018). Afterwards, a process of refining and resolving open issues took place until the end of 2019. Thus, it is a good point in time now to take a closer look at the new concepts and improvements CityGML 3.0 will offer. The current version of the conceptual UML model as well as the GML encoding (XML schemas) can be freely accessed in the github repositories OGC (2019a) and OGC (2019b), respectively. The CityGML model has been fully revised to reflect the increasing need for better interoperability with other relevant standards in the field like Industry Foundation Fig. 1 CityGML 3.0 module overview. The vertical boxes show the different thematic modules. Horizontal modules specify concepts that Classes (IFC) (ISO 16739 2013), IndoorGML (Lee et al. are applicable to all thematic modules 2016), Land Administration Domain Model (LADM) (ISO 19152 2012), INSPIRE (European Parliament and Council 2007), as well as with linked data and Semantic Web Tech- nologies like the Resource Description Framework (RDF) the modelling language UML (ISO 19505-2 2012), and (2) (W3C 2014). External object references have been rephrased the automatic derivation of transfer formats from these UML and are now better aligned to an RDF representation. Like models by applying predefined transformation rules. This before, each city object can have an arbitrary number of approach has been applied, e.g. in the development of the references to other objects in other datasets or databases, European INSPIRE Data Specifications (JRC 2014) and the but these can now be additionally qualified by a relation type German AFIS–ALKIS–ATKIS (AAA) Reference Model (that can point to a definition from an external ontology, e.g. (AdV 2009). The following tools are used to implement the the sameAs relation from OWL) given by an additional URI model-driven approach: Enterprise Architect (Sparx Sys- and allow for mapping to RDF triples. tems 2015) for defining the CityGML 3.0 UML model and The CityGML 3.0 standard will consist of two parts: ShapeChange (Interactive Instruments 2019) for deriving the the CityGML 3.0 Conceptual Model specification, which GML application schemas. Also, the feature catalogue with is planned to be released early 2020, and the CityGML 3.0 a detailed overview and explanation of all classes, attributes, GML Encoding specification, which is to be published a and relationships is derived automatically. couple of months after. Further encoding specifications UML data models developed for the GI domain are usu- (e.g. relational database schema, JSON-based representa- ally based on relevant standards from the ISO 191xx series tion) may follow in the future. The CityGML 3.0 Conceptual of geographic information standards. The data model of Model defines 17 modules as shown in Fig.  1. All mod- CityGML 3.0 is now based on these standards as well. This ules from CityGML 2.0 are part of CityGML 3.0. In addi- means that the geometry types from ISO 19107 as well as tion, the new modules Dynamizer, Versioning, PointCloud, the data types from ISO 19103 are used and that the rules for and Construction were introduced, and the modules Core, defining application schemas in UML from ISO 19109 are Generics, Building, and Transportation have been revised. applied. In addition, the transformation rules for converting The other modules have been updated to work with the new UML models to GML application schemas from ISO 19136 Core module. are applied in the GML encoding. CityGML 3.0 applies a model-driven approach in the cre- The application of the ISO-compliant transformation ation of the data model and exchange formats. Over the last rules inevitably leads to some changes in the XML encod- decade, this approach has become the standard procedure for ing compared to CityGML 2.0 and 1.0. Even if CityGML defining geospatial application schemas. The model-driven 3.0 would not change anything on the conceptual model with approach involves two steps: (1) the definition of data mod - regard to CityGML 2.0, the encoding would be slightly dif- els at the conceptual level, which is commonly done using ferent and datasets would have to be converted and software 1 3 PFG (2020) 88:43–61 45 for CityGML 2.0 would have to be adapted for CityGML 3.0. However, all modifications to the new CityGML 3.0 model are carried out in a way to ensure backwards com- patibility with CityGML 1.0 and 2.0, i.e. it is possible to transform all CityGML 1.0 and 2.0 datasets into the new model by applying syntactical transformations only. Back- wards compatibility is a major requirement for CityGML 3.0 to preserve the investments by anybody providing CityGML tools, datasets, and extensions. 2 The New CityGML 3.0 Core Module Fig. 2 Occupied and unoccupied spaces 2.1 T he CityGML 3.0 Space Concept and Varzi (2000) on the difference between bona fide and In CityGML 3.0, a clear semantic distinction of spatial features is introduced by mapping all city objects onto fiat boundaries to bound objects. Bona fide boundaries are physical boundaries; they correspond to the physical the semantic concepts of spaces and space boundaries. A Space is an entity of volumetric extent in the real world. boundaries of physical spaces in CityGML 3.0. In contrast, fiat boundaries are man-made boundaries; they are equiva- Buildings, water bodies, trees, rooms, and traffic spaces, for instance, have a volumetric extent. Hence, they are lent to the virtual boundaries of logical spaces. Physical spaces, in turn, are further classified into occu- modelled as spaces or, more precisely, as specific sub- classes of the abstract class Space. A Space Boundary pied spaces and unoccupied spaces. Occupied spaces rep- resent physical volumetric objects that occupy space in is an entity with areal extent in the real world. Space Boundaries delimit and connect Spaces. Examples are the the urban environment. Examples for occupied spaces are buildings, bridges, trees, city furniture, and water bodies. wall surfaces and roof surfaces that bound a building; the water surface as boundary between the water body and air; Occupying space means that some space is blocked by these volumetric objects; for instance, the space blocked by the road surface as boundary between the ground and the traffic space; or the digital terrain model representing the the building in Fig.  2 cannot be used any more for driv- ing through this space or placing a tree on that space. In space boundary between the over- and underground space. To obtain a more precise definition of spaces, they contrast, unoccupied spaces represent physical volumetric entities that do not occupy space in the urban environment, are further subdivided into physical spaces and logical spaces. Physical spaces are spaces that are fully or par- i.e. no space is blocked by these volumetric objects. Exam- ples for unoccupied spaces are building rooms and traffic tially bounded by physical objects. Buildings and rooms, for instance, are physical spaces as they are bounded by spaces. There is a risk of misunderstanding the term Occu- piedSpace. However, we decided to use the term anyway, as walls and slabs. Traffic spaces of roads are physical spaces as they are bounded by road surfaces against the ground. it is established in the field of robotics for over three decades (Elfes 1989). The navigation of mobile robots makes use of a Logical spaces, in contrast, are spaces that are not neces- sarily bounded by physical objects, but are defined accord- so-called occupancy map that marks areas that are occupied by matter and, thus, are not navigable for robots. ing to thematic considerations. Depending on the applica- tion, logical spaces can also be bounded by non-physical, Semantic objects in CityGML are often composed of parts, i.e. they form multi-level aggregation hierarchies. This i.e. virtual boundaries and they can represent aggrega- tions of physical spaces. A building unit, for instance, is also holds for semantic objects representing occupied and unoccupied spaces. In general, two types of compositions a logical space as it aggregates specific rooms to flats, the rooms being the physical spaces that are bounded by can be distinguished: wall surfaces, whereas the aggregation as a whole is being delimited by a virtual boundary. Other examples are city (1) Spatial partitioning Semantic objects of either the space type OccupiedSpace or UnoccupiedSpace are districts which are bounded by virtual vertically extruded administrative boundaries; public spaces vs. security subdivided into different parts that are of the same space type as the parent object. Examples are Buildings zones in airports; or city zones with specific regulations stemming from urban planning. The definition of physi- that can be subdivided into BuildingParts, or Buildings that are partitioned into ConstructiveElements. Build- cal and logical spaces and of corresponding physical and virtual boundaries is in line with the discussion in Smith ings as well as BuildingParts and ConstructiveElements 1 3 46 PFG (2020) 88:43–61 represent OccupiedSpaces. Similarly, Roads can be subdivided into TrafficSpaces and AuxiliaryTraffic- Spaces, all objects being UnoccupiedSpaces. (2) Nesting of alternating space types Semantic objects of one space type contain objects that are of the opposite space type as the parent object. Examples are Buildings (OccupiedSpace) that contain BuildingRooms (Unoc- cupiedSpace), BuildingRooms (UnoccupiedSpace) that contain Furniture (OccupiedSpace), and Roads (UnoccupiedSpace) that contain CityFurniture (Occu- Fig. 3 Representation of a carport as OccupiedSpace in different piedSpace). The categorization of a semantic object LODs. The red boxes represent solids, the green area represents a sur- into occupied or unoccupied takes place at the level face. In addition, the normal vectors of the roof solid (in red) and the of the object in relation to the parent object. A build- roof surface (in green) are shown ing is part of a city model; thus, first of all it occupies urban space within a city. As long as the interior of of UnoccupiedSpaces (e.g. Rooms, Roads), the observer is the building is not modelled in detail, the space cov- ered by the building needs to be considered as occu- typically inside the UnoccupiedSpace. The classification into OccupiedSpace and Unoccupied- pied and only viewable from the outside. To make the building accessible inside, voids need to be added to Space might not always be apparent at first sight. Carports, for instance, represent an OccupiedSpace, although they the building in the form of building rooms. The rooms add free space to the building interior, i.e. the Occu- are not closed and most of the space is free of matter, see Fig. 3. Since a carport is a roofed, immovable structure with piedSpace contains now UnoccupiedSpace. The free space inside the building can, in turn, contain objects the purpose of providing shelter to objects (i.e. cars), car- ports are frequently represented as buildings in cadastres. that occupy space again, such as furniture or installa- tions. In contrast, roads also occupy urban space in the Thus, also in CityGML, a carport should be modelled as an instance of the class Building. Since Building is transitively city; however, this space is initially unoccupied as it is accessible by cars, pedestrian, or cyclists. Adding a subclass of OccupiedSpace, a carport is an Occupied- Space as well. However, only in LOD1, the entire volumet- traffic signs or other city furniture objects to the free space results in specific sections of the road becoming ric region covered by the carport would be considered as physically occupied. In LOD1, the occupied space is defined occupied by these objects. Thus, one can also say that occupied spaces are mostly filled with matter; whereas, by the entire carport solid (unless a room would be defined in LOD1 that would model the unoccupied part below the unoccupied spaces are mostly free of matter and, thus, realise free spaces. roof); whereas in LOD2 and LOD3, the solids represent more realistically the really physically occupied space of The classification of feature types into OccupiedSpace the carport. In addition, for all OccupiedSpaces, the normal vectors of the thematic surfaces like the RoofSurface need and UnoccupiedSpace also defines the semantics of the geometries attached to the respective features. For Occu- to point away from the solids, i.e. consistent with the solid geometry. piedSpaces, the attached geometries describe volumes that are (mostly) physically occupied. For UnoccupiedSpaces, In contrast, a room is a physically unoccupied space. In CityGML, a room is represented by the class BuildingRoom the attached geometries describe (or bound) volumes that are (mostly) physically unoccupied. This also has an impact that is a subclass of UnoccupiedSpace. In LOD1, the entire room solid would be considered as unoccupied space, which on the required orientation of surface normals for attached thematic surfaces. For OccupiedSpaces, the normal vectors can contain furniture and installations, though, as is shown in Fig. 4. In LOD2 and 3, the solid represents more realisti- of thematic surfaces must point in the same direction as the surfaces of the outer shell of the volume. For Unoccupied- cally the really physically unoccupied space of the room (possibly somewhat generalised as indicated in the figure). Spaces, the normal vectors of thematic surfaces must point in the opposite direction as the surfaces of the outer shell For all UnoccupiedSpaces, the normal vectors of the bound- ing thematic surfaces like the InteriorWallSurface need to of the volume. This means that from the perspective of an observer of a city scene, the surface normals must always point inside the object, i.e. opposite to the solid geometry. The concepts of Spaces and Space Boundaries are repre- be directed towards the observer. In the case of Occupied- Spaces (e.g. Buildings, Furniture), the observer must be sented in the UML model of the CityGML 3.0 Core module by introducing the two pivotal abstract classes Abstract- located outside the OccupiedSpace for the surface normals being directed towards the observer; whereas in the case Space and AbstractSpaceBoundary as shown in Fig.  5. 1 3 PFG (2020) 88:43–61 47 From the class AbstractSpace, the following subclasses are derived: the classes AbstractPhysicalSpace and Abstract- LogicalSpace to classify spaces into physical and logical spaces as well as the classes AbstractOccupiedSpace and AbstractUnoccupiedSpace to categorise physical spaces into physically occupied and unoccupied spaces. The concrete classes like Building, BuildingRoom, or TrafficSpace are then defined as subclasses of these abstract classes. From the class AbstractSpaceBoundary, the class AbstractThe- maticSurface is derived. It is the superclass for all concrete surface classes like WallSurface, ClosureSurface, WaterSur- face or LandUse. The relation between AbstractSpace and AbstractSpaceBoundary is represented in the UML model Fig. 4 Representation of a room as UnoccupiedSpace in different through an association between both classes. LODs. The red boxes represent solids, the green area represents a sur- The classification of real-world objects into spaces and face. In addition, the normal vectors of the room solid (in red) and the space boundaries is solely based on the semantics of these wall surface (in green) are shown objects and not on their used geometry type, as CityGML Fig. 5 Excerpt from the CityGML 3.0 Core UML model defining the space concept 1 3 48 PFG (2020) 88:43–61 3.0 allows various geometrical representations for objects. In CityGML 3.0 all geometric representations are defined A building, for instance, can be spatially represented by a in the Core module only. This makes (a) data models of 3D solid (e.g. in LOD1), but at the same time, the real-world the thematic modules simpler as they no longer need to geometry can also be abstracted by a single point (LOD0), be associated directly with the geometry classes, and (b) by a 3D point cloud, or by a 3D mesh (LOD3). implementation easier as all spatial concepts have only The space concept was strongly motivated from urban to be implemented once in the Core module and all the- planning, the work on IndoorGML and indoor navigation as matic modules like Building, Relief, WaterBody, etc. are well as the Land Administration Domain Model. By intro- inheriting them. ducing spaces in CityGML, it will become easier to link The space concept supports the expression of explicit CityGML with IndoorGML and to apply analytical frame- topological, geometrical, and thematic relations between works from the urban geography domain like Space Syntax spaces and spaces, spaces and space boundaries, and (Hillier and Hanson 1984) or from the analyses of urban space boundaries and space boundaries. Thus, imple- activities like living, working, or traffic (which are all taking menting the checking of geometric-topological consist- place in or affecting spaces). In addition, the space concept ency will become easier, because most checks can be was inspired by the work of Billen et al. (2012) on defin- expressed and performed on the CityGML Core module ing a generic ontology for the urban space. This ontology and then automatically apply to all thematic modules. partitions the universe into spaces that are classified into When a new thematic module [or an Application Domain physical spaces and fictional spaces. Physical spaces can Extension (ADE)] will be added and its spatial represen- have boundaries and can be divided into sub-spaces. Physi- tations will be expressed using space and space boundary cal sub-spaces, in turn, are classified into penetrable and classes, the validity checks automatically hold also for non-penetrable physical sub-spaces, depending on whether the new thematic module (or ADE). they can be penetrated by an agent such as a human, an Some new application areas could be opened up. For electromagnetic, or a specific behaviour. Real-world objects example, urban planning, urban analytics, autonomous can then be linked to the physical sub-spaces. Buildings, driving and driver assistance systems, and navigation for instance, are considered to have a non-permeable space, in general will benefit from the space concept. Also the whereas rooms are permeable spaces. The concepts defined modelling of the underground (hollow spaces, geologi- in the ontology can be found again in the space concept of cal rock layers and their separating surfaces) could be CityGML 3.0. Physical and fictional spaces are represented very elegantly done in the future using spaces and space in CityGML 3.0 by the classes AbstractPhysicalSpace and boundaries. AbstractLogicalSpace. The non-penetrable and penetrable For the analysis of navigable spaces (e.g. to generate physical sub-spaces are modelled in CityGML 3.0 by the IndoorGML data from CityGML) algorithms can be classes AbstractOccupiedSpace and AbstractUnoccupied- defined on the level of the Core module. These algo- Space; thus, buildings, which are considered by Billen et al. rithms will then work with all CityGML feature classes (2012) as non-penetrable, are defined as occupied spaces and also ADEs as they are derived from the Core. The and rooms, which are considered as penetrable, are defined same is true for other applications of 3D city models as unoccupied spaces. In contrast to the ontology, where listed in Biljecki et al. (2015) such as visibility analyses only physical spaces can have boundaries, all spaces can be including shadow casting or solar irradiation analyses. bounded by thematic surfaces in CityGML 3.0. The space Practitioners and developers do not see much of the concept corresponds also with the observations made in Yan space concept, because the space and space boundary et al. (2019) on the categorization of spaces into indoor and classes are just abstract classes. Only elements represent- outdoor spaces to improve indoor/outdoor navigation. The ing objects from concrete subclasses such as Building, classification in CityGML 3.0 does not go as far as differen- BuildingRoom, or TrafficSpace will appear in CityGML tiating semi-indoor and semi-outdoor spaces as well, how- files. ever, CityGML 3.0 can be used to derive this classification. The modelling in CityGML 3.0 does not focus on model- ling the navigable space, but on an exact representation of 2.2 The CityGML 3.0 LOD Concept spatial objects such as the carport in LOD2/3 as shown in Fig. 3. Nevertheless, CityGML 3.0 also allows for deriving CityGML 3.0 will include a revised Level of Detail (LOD) the navigable space of the carport. This distinguishes the concept which comprises a central definition of all geom - modelling with CityGML 3.0 from the concepts defined in etries in the Core module and the representation of the inte- Yan et al. (2019). rior of city objects at any level of detail. The new space concept offers several advantages: In CityGML 2.0, each module defines the required geometries itself, leading to redundancy, for instance, in 1 3 PFG (2020) 88:43–61 49 Fig. 6 Excerpt from the CityGML 3.0 Core UML model defining the LOD concept. The geometries in CityGML 3.0 are now associated with the classes in the Core model and no longer need to be specified in each thematic module separately the Building, Tunnel, and Bridge modules. To overcome in LOD2 or 3. Details on the changes to the CityGML LOD these redundancies, nearly all geometry representations are concept are provided in Löwner et al. (2016). moved from the thematic modules to the Core module and In addition, the new PointCloud module adds the possi- are associated with the semantic concepts of spaces and bility to use 3D point clouds to represent the geometries of space boundaries, see Fig. 6. The geometry classes from physical spaces and space boundaries. ISO 19107 are used for defining the various geometric rep- resentations. Since all feature types in the thematic modules are defined as subclasses of the space and space boundary 3 Refinement of Constructions classes, they automatically inherit the geometry classes and, and Buildings thus, no longer require direct associations with them. Spaces and all its subclasses like Building, Room, and CityGML 3.0 will contain a new Construction module that TrafficSpace can now be spatially represented as single defines concepts common to all kinds of man-made con - points in LOD0, multi-surfaces in LOD0/2/3, solids in structions like buildings, bridges, and tunnels. This means LOD1/2/3, and multi-curves in LOD2/3. Space bounda- that the module integrates all classes that are similar over ries and all its subclasses such as WallSurface, LandUse, different types of constructions and that are defined sepa- or Relief can now be represented as multi-surfaces in rately in the Building, Bridge, and Tunnel modules in City- LOD0/2/3 and as multi-curves in LOD2/3. GML 2.0. These are, in particular, the various thematic LOD4, which is used for representing the interior of surfaces like RoofSurface, GroundSurface, or WallSurface, objects in CityGML 2.0 (like indoor modelling for buildings and the openings Door and Window. Figure  7 shows the and tunnels), has been removed; only the LODs 0/1/2/3 will Construction module. The module defines a class Abstract- remain. Instead, the interior of objects can be expressed now Construction as subclass of AbstractOccupiedSpace which integrated with the LODs 0/1/2/3. This allows, for instance, is associated with the different thematic surfaces. Buildings, the representation of floor plans in LOD0 (Konde et  al. bridges, and tunnels, in turn, are defined as subclasses of 2018). It will even be possible to model the outside shell of the class AbstractConstruction, inheriting in this way auto- a building in LOD1, while representing the interior structure matically the associations with all thematic surfaces. This 1 3 50 PFG (2020) 88:43–61 Fig. 7 CityGML 3.0 Construction module leads to a substantial simplification of the UML models of components are bounded by the various thematic surfaces the Building, Bridge, and Tunnel modules. In addition, for RoofSurface, WallSurface, etc. as well. Thus, space and representing man-made structures that are neither buildings, space boundary establish the explicit connection between nor tunnels, nor bridges (e.g. large chimneys or city walls), (volumetric) constructive elements and their thematic the new class OtherConstruction has been introduced as sub- boundary surfaces. class of AbstractOccupiedSpace. The interoperability of CityGML with INSPIRE is To facilitate a more direct mapping of IFC onto City- improved by adopting attributes from the INSPIRE Building GML, a new feature type AbstractConstructiveElement is data theme (JRC 2013) which allow for specifying multiple introduced and corresponding subclasses BuildingConstruc- elevation levels and measured heights. In addition, various tiveElement, BridgeConstructiveElement, and TunnelCon- events and their dates can be specified, such as the date a build- structiveElement are defined in the modules Building (see ing permit was issued, the start of renovation, or the end of Fig. 8), Bridge, and Tunnel. These feature types allow for renovation (see corresponding attributes in the class Abstract- mapping constructive elements from BIM data sets given Construction in Fig. 7). in the IFC standard (e.g. the IFC classes IfcWall, IfcRoof, Doors and windows have a clearer semantics now. The IfcBeam, IfcSlab, etc.) onto CityGML. These volumetric classes Window and Door represent now filling elements; in 1 3 PFG (2020) 88:43–61 51 Fig. 8 CityGML 3.0 Building module addition, the classes WindowSurface and DoorSurface are object; however, a flood incident involves variations in the introduced to represent filling surfaces. location and shape of water. There might be other prop- The Building module introduces a new class AbstractBuild- erties which change w.r.t. thematic data of city objects, ingSubdivision, which is modelled as a subclass of Abstract- e.g. hourly variations in energy or gas consumption of a LogicalSpace, and the two specialisations BuildingUnit and building or changing the building usage from residential to Storey to allow for representing building units (like apart- commercial. Some properties involve changes in appear- ments) and storeys. ances over the period of time, such as building textures changing over years or traffic cameras recording videos of moving traffic over definite intervals. 3D city models com- 4 Dynamics of Changing Cities prise relevant real-world entities and also represent inter- relationships between objects. Such interrelationships may In general, a city object can have properties related to its also change over time. Hence, it is important to consider geometry, topology, semantics, and appearance and all of that the representation of time-varying data is required to these properties may change w.r.t. time. For example, a be associated with these different properties. construction event leads to the change in geometry of a Temporal variations involve time points mapped onto the building (i.e. addition of a new building floor or demoli- specific attributes (i.e. spatial, thematic, topology, or appear - tion of an existing door). The geometry of an object can ance). Such mappings are often realised by discrete record- be further classified according to its shape, location, and ings or by interpolation functions and involve quantitative extent, which can also be changed over time. A moving changes which can be defined as a function of time. For car object involves changing only the location of the car example, varying energy consumption values of a building 1 3 52 PFG (2020) 88:43–61 can be determined for specific points of time (1) in the past objects), and (3) real-time sensor observations. In this case, by querying a database for historic data, (2) in the present only some of the properties of otherwise static objects need by querying a real-time sensor or IoT device, and (3) in the to represent such time-varying values. future by a simulation software. However, there are other scenarios where features begin or cease to exist over differ -4.1 Versioning of Cities ent time intervals, for example, addition of a new building or demolition of an old building. Such scenarios involve Within the new Versioning module, CityGML 3.0 introduces qualitative changes and are fundamentally different from bitemporal timestamps for all objects in alignment with the the quantitative changes. Such changes can not be defined INSPIRE data specifications. Besides the attributes creation- as a function of time on a feature’s property as the state of Date and terminationDate from CityGML 2.0, which refer features changes. Hence, it is also essential to consider that to the time period in which a specific version of an object semantic 3D city models handle both quantitative and quali- is an integral part of the 3D city model, all objects now tative changes within cities/city objects. Since both quanti- can additionally have the attributes validFrom and validTo, tative and qualitative changes involve variations w.r.t. time, which represent the lifespan a specific version of an object it is also important to determine if they can be handled by has in the real world. Furthermore, each geographic feature the same mechanisms. A detailed discussion on the require- is being provided with two identifiers: the identifier property ments of applications regarding the support of dynamic data which is stable along the lifetime of the real-world object, is given in Chaturvedi and Kolbe (2019). and the gml:id attribute which is to mark the respective ver- In the current version of CityGML (version 2.0), such sion of the object. In this way, not only the current version of time variations are not supported. Hence, two new concepts a 3D city model, but also its entire history can be represented (Versioning module and Dynamizer module) are proposed in CityGML and exchanged even within a single file. The for CityGML 3.0 to manage time-dependent properties. module defines two new feature types: Version, which can be The Versioning module manages qualitative changes that used to explicitly define named states of the 3D city model are slower in nature, e.g. (1) the history or evolution of cit- and denote all the specific versions of objects belonging to ies such as construction or demolition of buildings, and (2) such states, and VersionTransition, which allows to explicitly managing multiple versions of the city models. The Dynam- link different versions of the 3D city model by describing the izer module manages quantitative changes representing high reason of change and the modifications applied. Details on frequent or dynamic variations of object properties, e.g. vari- the versioning concept are given in Chaturvedi et al. (2017). ations of (1) thematic attributes such as changes of physical The versioning concept has already been used and further quantities (energy demands, temperature, solar irradiation extended by a proposed proof-of-concept called UrbanCo- levels), (2) spatial properties such as change of a feature’s 2Fab (Samuel et al. 2016) to represent multiple viewpoints geometry, with respect to shape and location (moving of urban evolution. Fig. 9 An instance example of versions representing modifica- tions of a building 1 3 PFG (2020) 88:43–61 53 The following example illustrates one such possibility of also allows the different versions to be used in an interoper - modification scenarios. As shown in Fig.  9, a building with able exchange format and the exchange of all versions of the major ID B1020 has a function property Office and one a repository within a single dataset. Such a dataset can be of its building parts with major ID BP12 has a roofType used by different software systems to visualise and work property Flat. Over a period of time, the building function with all the versions. The approach not only addresses the property is changed to Living which has been captured in implementation of versionable CityGML models but also version 2. Furthermore, at a point in time, the roofType prop- considers new aspects to previous work such as managing erty of the same building has been changed to Saddle. Using multiple histories or multiple interpretations of the past of a the Versioning module, version management can easily be city. Also, collaborative work is supported since the Version- supported in a single CityGML data set as shown in Fig. 10. ing module provides all functionalities to represent a tree of The building object in version 1 can be denoted as B1020_t1 workspaces as version control systems like git or svn. The at a specific point in time t1. XPath can be used with XLink proposed UML model handles versions and version transi- to retrieve all the instances of the same building object. The tions as feature types, which allows the version management instance data can also include version elements for manag- to be completely handled using the OGC Web Feature Ser- ing different versions of an object. However, due to limited vice (Vretanos 2010). No extension of other OGC standards space in this paper, the example illustrates a simple version is required. management where it is sufficient to just use the bi-temporal time attributes and the major/minor IDs. The advantage of this approach is that it not only facili- tates the data model for supporting different versions, but Fig. 10 Representation of dif- ferent versions of city objects within one CityGML dataset encoded in GML 1 3 54 PFG (2020) 88:43–61 2. Dynamizer delivers a method to enhance static city mod- 4.2 Representation of Time‑Dependent Properties els by dynamic property values. It references a specific property (e.g. spatial, thematic or appearance properties) The new Dynamizer module has been developed to improve the usability of CityGML for different kinds of simulations of a specific object within a 3D city model providing dynamic values overriding the static value of the refer- as well as to facilitate the integration of sensors with 3D city models. Both, simulations and sensors provide dynamic enced object attribute. 3. Dynamizer objects establish explicit links between sen- variations of some measured or simulated properties like, for example, the electricity consumption of a building or the sor/observation data and the respective properties of city model objects that are measured by them. By mak- traffic density within a road. The variations of the value are typically represented using time series data. The data source ing such explicit links with city object properties, the semantics of sensor data become implicitly defined by of the time series data is either sensor observations (e.g. from a smart meter), pre-recorded load profiles (e.g. from the city model. an energy company), or the results of some simulation run. As shown in Fig.  11, Dynamizers serve three main In this way, dynamizers can be used to inject dynamic variations of city object properties into an otherwise static purposes: representation. The advantage in using such approach is that it allows only selected properties of city models to be 1. Dynamizer is a data structure to represent dynamic val- ues in different and generic ways. Such dynamic values made dynamic. If an application does not support dynamic data, it simply does not allow/include these special types may be given by (1) tabulation of time/value pairs using its AtomicTimeseries class, (2) patterns of time/value of features. Dynamizers have already been implemented as an pairs based on statistical rules using its CompositeTime- series class, and (3) retrieving observations directly Application Domain Extension (ADE) for CityGML 2.0 and were employed in the OGC Future City Pilot Phase 1. from external sensor/IoT services using its SensorCon- nection class. The values can be obtained from sensors, More details about the UML diagram and instance docu- ments are given in Chaturvedi and Kolbe (2017). simulation specific databases, and also external files such as CSV or Excel sheets. Fig. 11 Conceptual representa- tion of Dynamizers allowing (1) enhancing the properties of city objects by overriding their static values, and (2) the representa- tion of time-variant values from sensors, simulation specific databases, and external files. Image taken from Chaturvedi and Kolbe (2016) 1 3 PFG (2020) 88:43–61 55 TransportationSpace. In addition, they can be subdivided 5 Further New Concepts into sections, which can be regular road, track or railway legs, intersection areas, or roundabouts (class Section and In addition to the new and revised modules and concepts Intersection). Intersection areas as well as roundabouts can presented above, two further modules provide interesting belong to multiple road or track objects avoiding the redun- new additions to CityGML 3.0: the Transportation module dant representation of shared spaces. As in CityGML 2.0, and the PointCloud module. transportation objects can be subdivided into TrafficArea (e.g. driving lanes, pedestrian zones, and cycle lanes) and 5.1 Transportation Module AuxiliaryTrafficArea (e.g. kerbstones, middle lanes, and green areas). To adapt the semantics of the Transportation The Transportation module defines classes for the repre- module to the CityGML 3.0 space concept, the classes Traf- sentation of central elements of the traffic infrastructure. To ficSpace and AuxiliaryTrafficSpace were introduced in addi- improve the usability of CityGML transportation objects tion to TrafficArea and AuxiliaryTrafficArea, the two areas with traffic and driving simulations, driving assistance sys- representing now the bottom boundaries of the two spaces. tems, autonomous driving, as well as with road and railway Each traffic space can have an optional ClearanceSpace. facility management systems, the data model has been sub- This is exemplified in Fig.  13. A road consisting of a driv- stantially revised. ing lane and two sidewalks is represented. The traffic spaces Figure  12 illustrates the new Transportation module. (in blue) define the free spaces above the driving lane and Transportation objects like roads, tracks, or railways are the sidewalks; whereas, the traffic areas (in green) represent defined now as concrete subclasses of the abstract class Fig. 12 CityGML 3.0 Transportation module 1 3 56 PFG (2020) 88:43–61 Fig. 14 CityGML 3.0 PointCloud module 6 New Applications for CityGML 3.0 6.1 Sensors and IoT in Cities Fig. 13 Representation of a road in CityGML 3.0 1 2 A large number of cities such as Singapore, Munich, Hel- 3 4 sinki, and Melbourne are developing Digital Twins to the ground surfaces of the traffic spaces. In Germany, for improve the operational efficiency of cities. A Digital Twin example, roads typically have a free space height of 4.5 m (Batty 2018; Datta 2017) is a digital counterpart of a physi- and sidewalks of 2.5 m. In addition, clearance spaces (in cal asset, which collects information via sensors and IoT red) are represented. devices, and applies advanced analytics and artificial intel- Transportation objects can now have an areal as well as a ligence to gain real-time insights about the physical asset’s center line representation for each LOD. In the highest LOD performance, operation or profitability. These sensors can (LOD3), each lane is represented by an individual traffic be stationary such as Smart Meters and weather stations. space object. Each traffic space can be linked to predeces- Some of the sensors can also be non-stationary such as air- sor and successor traffic spaces. This information is typi- quality sensors mounted on a car measuring air pollution cally used (and required) in navigation systems and traffic over different parts of a city at different time intervals or simulations (cf. Ruhdorfer et al. 2018; Labetski et al. 2018). pedestrian flow analysis involving pedestrians moving into According to Labetski et al. (2018) also Waterway was intro- or out of a stadium (e.g. before or after a scheduled football duced as new subclass of TransportationSpace. In addition, match). Bridging the virtual and physical worlds together in the new class Marking allows for adding road markings to this way can also help Smart City applications to improve the road surface and the classes Hole and HoleSurface can decision-making and reduce risks by predicting issues before be used to represent, for instance, roadway damages or man- occurrence. holes including their surfaces. For further information and Several Smart City initiatives also highlight the impor- examples on the new Transportation module please refer to tance of integrating real-time sensors and IoT devices with Beil and Kolbe (2017). city objects. The Smart District Data Infrastructure (SDDI) proposed by Moshrefzadeh et al. (2017) allows integrat- 5.2 PointCloud Module ing diverse components such as stakeholders, sensors, IoT devices and simulation tools with a virtual district model In addition to the geometries defined in the Core module, representing the physical reality of the district. To access the geometry of physical spaces and of thematic surfaces can distributed resources, the framework uses a well-defined set now also be provided by 3D point clouds using MultiPoint of OGC-based service interfaces such as Web Feature Ser- geometry. This allows, for example, to spatially represent the vice (Vretanos 2010), Sensor Observation Service (Bröring building hull, a room within a building or a single wall sur- et al. 2012) and SensorThings API (Liang et al. 2015) as face just by a point cloud. All thematic feature types includ- well as a Catalogue Service. The framework also facilitates ing transportation objects, vegetation, city furniture, etc. can privacy, security and controlled access to all stakeholders be spatially represented by point clouds, too. In this way, the ClearanceSpace of a road or railway could, for instance, https ://www.nrf.gov.sg/progr ammes /virtu al-singa pore. https ://muenc hen.digit al/blog/digit aler-zwill ing-in-muenc hen-ein- be modelled directly from the result of a mobile laser scan- leuch tturm proje kt-auf-dem-weg-zur-digit alen-metro pole/. ning campaign. Point clouds can either be represented inline https ://aec-busin ess.com/helsi nki-is-build ing-a-digit al-twin-of-the- within a CityGML file or just reference an external file of city/. some common types such as LAS or LAZ. Figure 14 shows https ://www.itnew s.com.au/news/vic-govt-to-build -state s-first -digit the new PointCloud module. al-twin-52818 7. 1 3 PFG (2020) 88:43–61 57 and the respective components by establishing proper large CityGML datasets on top of spatial relational database authorization and authentication mechanisms (Chaturvedi management systems (SRDBMS) such as Oracle Spatial and et al. 2019a). PostgreSQL. It includes a Java front-end application named Since all of the above-mentioned city initiatives consider 3DCityDB Importer/Exporter for importing and exporting semantic 3D city models as an integral component of their CityGML datasets with arbitrary file sizes. It also allows infrastructures, it is highly important that the 3D city objects exporting CityGML objects in the form of 3D visualiza- support seamless integration with sensors and IoT devices. tion formats (such as KML, COLLADA, and glTF) enabling CityGML Dynamizers allow defining explicit links to these them to be viewed and interactively explored in web appli- real-time sensor observations directly within city objects. cations such as the 3DCityDB Web Map Client or Google In this way, the attribute of the respective city object can Earth. The implementation developed by Chaturvedi et al. also be associated with time-dynamic sensor observations. (2019b) allows storing Dynamizer timeseries data (such as For example, if a building has an indoor sensor installed for solar potential simulation results of a building’s roof sur- measuring real-time temperature or humidity and the indoor face) along with other static properties of the same building sensor’s readings are accessible via standardised web ser- in the 3DCityDB. It also enables CityGML Viewers such as vices such as OGC Sensor Web Enablement (Bröring et al. the 3DCityDB Web Map Client to access static data using 2011), FIWARE (FIWARE 2018), or any other proprietary the OGC Web Feature Service (Vretanos 2010) interface API, Dynamizers can be defined for the specific building or and dynamic data using the OGC SWE interfaces such as room having explicit links to those sensor-based services, the OGC Sensor Observation Service (Bröring et al. 2012) and the respective temperature/humidity attribute of the and the OGC SensorThings API (Liang et al. 2015) in an building can be overridden by the real-time sensor observa- integrated fashion with the help of the newly developed tions (see Fig. 15). InterSensor Service (Chaturvedi and Kolbe 2019). 6.2 Improved Simulation Support 6.3 Usage of the Space Concept CityGML Dynamizers also enable 3D city models for an The new space concept introduced in CityGML 3.0 can be improved simulation support. The Dynamizer ADE for useful in various applications such as enhancing the conver- CityGML 2.0 (Chaturvedi and Kolbe 2017) has already sion of IFC into CityGML. In particular the new volumetric been tested successfully for a solar potential simulation to feature types BuildingConstructiveElement, BridgeCon- assess and estimate solar energy production for the roofs and structiveElement, and TunnelConstructiveElement that are façades of 3D building objects. The simulation tool operates defined as subclasses of AbstractOccupiedSpace facilitate on 3D models structured according to the CityGML standard the mapping of constructive elements from IFC data sets and generates the monthly and yearly estimates of direct, dif- to CityGML. Walls, for instance, are represented in IFC as fuse, and global irradiation values for the building surfaces. volumetric objects; whereas in CityGML 2.0, only the exte- The dynamic simulation results can be represented using the rior and interior surfaces of walls are represented as separate international OGC TimeseriesML standard (Tomkins and features. This means that these surfaces need to be extracted Lowe 2016) within Dynamizer AtomicTimeseries class. The when mapping IFC to CityGML 2.0. With the newly intro- advantage of such representation of simulation results is that duced constructive element classes this extraction could be it allows modelling precise description of timeseries and avoided, because a direct mapping from IFC onto CityGML enables cross-domain exchanging of simulation results along can now be achieved simply by mapping the volumetric IFC with city objects (Fig. 16). It is also helpful to create a snap- objects to volumetric CityGML objects. Figure 17 shows shot of the state(s) of a city model including time-varying a building of the Technical University of Munich that was data for documentation and archiving. Similarly, Dynamiz- converted from IFC to CityGML 3.0. Visible are only the ers are also helpful in representing moving objects in traffic BuildingConstructiveElement objects that have been created simulations (Ruhdorfer 2017; Santhanavanich et al. 2018). from the IFC classes IfcWall, IfcRoof, IfcBeam, and IfcSlab. Furthermore, Chaturvedi et  al. (2019b) proposed an The conversion was executed using the FME-based ifc-to- implementation that allows managing and visualising static citygml3 conversion tool available from TUM-GIS (2019a). and dynamic properties of semantic 3D city models in an Similarly, the semantics of the IFC class IFCSpace is integrated fashion. The 3D City Database (also known as a physically unoccupied space to represent rooms. The 3DCityDB ) (Yao et al. 2018) is an Open Source software class BuildingRoom represents the equivalent concept in suite, which allows storing, representing, and managing City GML as it is a subclass of AbstractUnoccupiedSpace. 5 6 http://www.3dcit ydb.org. http://www.inter senso rserv ice.org/. 1 3 58 PFG (2020) 88:43–61 Fig. 15 Defining direct links to sensors within Dynamizer feature type. The file shows an excerpt of a CityGML dataset encoded in GML Fig. 17 BuildingConstructiveElement objects created from the IFC classes IfcWall, IfcRoof, IfcBeam, and IfcSlab Fig. 16 The standardised timeseries representation of monthly irradi- House have been converted into BuildingRoom objects in ation values of a building. This demo is accessible from http://manch CityGML 3.0. ester .virtu alcit ymap.de/ 6.4 Conversion of CityGML 2.0 into CityGML 3.0 Thus, IFCSpace objects can be mapped onto Building- Section 1 mentions that it is possible to convert every City- Room objects without change of semantics. This is shown GML 1.0 and 2.0 dataset into CityGML 3.0 by applying in Fig. 18, where IFCSpace objects of the well-known FZK 1 3 PFG (2020) 88:43–61 59 module, the new modules Construction, Versioning, and Dynamizer, as well as the revised Building and Transporta- tion modules. In addition, CityGML 3.0 is modelled ISO- compliant and, thus, allows for automatically deriving the GML application schemas from the UML model by applying a model-driven approach. Several implementations already exist or are currently being created for CityGML 3.0. All software systems that Fig. 18 BuildingRoom objects created from the IFC class IfcSpace can deal with generic GML3 can also read CityGML 3.0 data sets, amongst others FME, deegree, GDAL, GMLAS, and SupportGIS. The citygml2-to-citygml3 conversion tool can create CityGML 3.0 data sets from CityGML 2.0 data sets. The CityGML-3-to-Java-objects library citygml4j is currently being implemented by Claus Nagel for CityGML 3.0. An adaption of the 3DCityDB to support CityGML 3.0 will be carried out in the future. Successful application of CityGML 3.0 was also demonstrated at the OGC CityGML Hackathon in June 2019 in London as well as at the OGC CityGML Challenge in October 2019 in Manchester. Like with CityGML 2.0, the modular specic fi ation allows that applications do not have to implement all CityGML modules. For example, not only the modules Dynamizer, Versioning, or PointCloud, but also some thematic modules can be left out when not required. The entire CityGML 3.0 development is subject to final votings of the CityGML SWG as well as of the OGC OAB Fig. 19 The city model of Berlin Moabit represented in CityGML 3.0 (Open Architecture Board) and the Technical Committee. The UML models provided in this paper may still undergo slight changes until the finalisation of the specification. syntactical transformations only. This transformation can, However, we do not expect major changes anymore. for instance, be carried out using an XSLT-based conver- sion tool, such as the citygml2-to-citygml3 conversion tool Acknowledgements Open Access funding provided by Projekt DEAL. provided from TUM-GIS (2019b). This tool gives data We would like to thank the other members of the OGC CityGML SWG Modelling Subgroup Claus Nagel, Steve Smyth, Gilles Gesquière, providers and software implementers the possibility to (a) Emmanuel Devys, Heidi Valparys, Friso Penninga, Volker Coors, Sisi see how their existing datasets would look like in City- Zlatanova, Helga Tauscher and Carsten Roensdorf for their valuable GML 3.0, and (b) adapt their software implementations contributions and discussions in the development of CityGML 3.0. and work with CityGML 3.0 data, and (c) reassure them We also thank the modelling working group of SIG 3D of GDI-DE, in particular Gerhard Gröger, Joachim Benner, Karl-Heinz Häfele, Marc- on the backwards compatibility of the conceptual model of Oliver Löwner, Jürgen Ebbinghaus, and Heinrich Geerling as well as CityGML 3.0 with CityGML 2.0 by demonstrating lossless the further contributors to the CityGML 3.0 work packages includ- data conversion. The tool currently supports the conversion ing Filip Biljecki and Linda van den Brink. Special thanks go to Son of Buildings, CityFurniture, and Appearances and is gradu- Nguyen for his work on the citygml2-to-citygml3 conversion tool and Daniel Härpfer for his work on the ifc-to-citygml3 converter. ally being extended to support the other modules as well. Figure 19 visualises the city model of Berlin Moabit that Open Access This article is licensed under a Creative Commons Attri- was converted from CityGML 2.0 into CityGML 3.0 using bution 4.0 International License, which permits use, sharing, adapta- the citygml2-to-citygml3 conversion tool. tion, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are 7 Conclusions and Outlook included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in This paper introduces the new and revised concepts that the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will are to become part of the next major CityGML version 3.0. need to obtain permission directly from the copyright holder. To view a Of particular importance are the new space concept and copy of this licence, visit http://creativecommons.org/licenses/by/4.0/. the revised LOD concept that both are defined in the Core 1 3 60 PFG (2020) 88:43–61 ISO 16739 (2013) ISO 16739:2013 industry foundation classes (IFC) References for data sharing in the construction and facility management industries AdV (2009) Documentation on the modelling of geoinformation of ISO 19152 (2012) ISO/TS 19152:2012 geographic information—land official surveying and mapping (GeoInfoDoc), version 6.0.1 administration domain model Batty M (2018) Digital twins. Environ Plan B Urban Anal City Sci ISO 19505-2 (2012) ISO/IEC 19505-2:2012 information technology— 45(5):817–820 object management group unified modeling language (OMG Beil C, Kolbe TH (2017) CityGML and the streets of New York—a UML)—part 2: superstructure proposal for detailed street space modelling. ISPRS Ann Photo- JRC (2013) D2.8.III.2 Data specification on buildings—technical gram Remote Sens Spat Inf Sci IV-4/W5:9–16 guidelines Biljecki F, Stoter J, Ledoux H, Zlatanova S, Çöltekin A (2015) Appli- JRC (2014) INSPIRE D2.5: generic conceptual model, version 3.4 cations of 3d city models: state of the art review. ISPRS Int J Konde A, Tauscher H, Biljecki F, Crawford J (2018) Floor plans in Geo-Inf 4(4):2842–2889 CityGML. ISPRS Ann Photogramm Remote Sens Spat Inf Sci Billen R, Zaki CE, Servières M, Moreau G, Hallot P (2012) Developing IV-4/W6:25–32 an ontology of space: Application to 3D city modeling. In: Leduc Kutzner T, Kolbe TH (2018) CityGML 3.0: Sneak preview. In: Ker- T, Moreau G, Billen R (eds) Usage, usability, and utility of 3D sten TP, Gülch E, Schiewe J, Kolbe TH, Stilla U (eds) PFGK18- city models—European COST Action TU0801. EDP Sciences, Photogrammetrie-Fernerkundung-Geoinformatik-Kartographie, Nantes, vol 02007. https ://hal.archi ves-ouver tes.fr/hal-01521 445 37. Jahrestagung in München 2018, Deutsche Gesellschaft für Bröring A, Echterhoff J, Jirka S, Simonis I, Everding T, Stasch C, Photogrammetrie, Fernerkundung und Geoinformation e.V., Pub- Liang S, Lemmens R (2011) New generation sensor web enable- likationen der Deutschen Gesellschaft für Photogrammetrie, Fern- ment. Sensors 11(3):2652–2699 erkundung und Geoinformation (DGPF) e.V., vol 27, pp 835–839 Bröring A, Stasch C, Echterhoff J (2012) Sensor Observation Service Labetski A, van Gerwen S, Tamminga G, Ledoux H, Stoter J (2018) Interface Standard, OGC Doc. No. 12-006. http://www.openg A proposal for an improved transportation model in CityGML. eospa tial.org/stand ards/sos. Accessed 04 May 2019 ISPRS—Int Arch Photogramm Remote Sens Spat Inf Sci XLII-4/ Chaturvedi K, Kolbe TH (2016) Integrating dynamic data and sen- W10:89–96 sors with semantic 3D city models in the context of smart cities. Lee et al (2016) OGC IndoorGML, version 1.0.2 In: Proceedings of the 11th international 3D geoinfo conference, Liang S, Huang CY, Khalafbeigi T (2015) SensorThings API Part 1: Athens, ISPRS Annals of the Photogrammetry, Remote Sens- Sensing, OGC Doc. No. 15-078r6. https ://www.openg eospa tial. ing and Spatial Information Sciences, vol IV-2/W1. https ://doi. org/stand ards/senso rthin gs. Accessed 04 May 2019 org/10.5194/isprs -annal s-IV-2-W1-31-2016 Löwner MO, Gröger G, Benner J, Biljecki F, Nagel C (2016) Proposal Chaturvedi K, Kolbe TH (2017) Future City Pilot 1 Engineering for a new LOD and multi-representation concept for CityGML. Report, OGC Doc. No. 19-098. http://docs.openg eospa tial.org/ ISPRS Ann Photogramm Remote Sens Spat Inf Sci IV-2/W1:3–12 per/16-098.html. Accessed 22 Dec 2018 Moshrefzadeh M, Chaturvedi K, Hijazi I, Donaubauer A, Kolbe TH Chaturvedi K, Kolbe TH (2019) Towards establishing cross-platform (2017) Integrating and managing the information for smart sus- interoperability for sensors in smart cities. Sensors 19(3) tainable districts—the smart district data infrastructure (SDDI). Chaturvedi K, Smyth CS, Gesquière G, Kutzner T, Kolbe TH (2017) In: Kolbe TH, Bill R, Donaubauer A (eds) Geoinformations- Managing versions and history within semantic 3D city models for systeme 2017-Beiträge zur 4. Münchner GI-Runde, Wichmann the next generation of CityGML. In: Advances in 3D geoinforma- Verlag tion. Springer, pp 191–206 OGC (2019a) CityGML 3.0 conceptional model. https ://githu b.com/ Chaturvedi K, Matheus A, Nguyen SH, Kolbe TH (2019a) Securing openg eospa tial/CityG ML-3.0CM. Accessed 14 Sep 2019 spatial data infrastructures for distributed smart city applications OGC (2019b) CityGML 3.0 encodings. https://git hub.com/openg eospa and services. Future Gen Comput Syst 101:723–736 tial/CityG ML-3.0Enco dings /. Accessed 14 Sep 2019 Chaturvedi K, Yao Z, Kolbe TH (2019b) Integrated management and Ruhdorfer R (2017) Kopplung von Verkehrssimulation und seman- visualization of static and dynamic properties of semantic 3D tischen 3D-Stadtmodellen in CityGML. Master’s thesis, Technis- city models. In: Proceedings of the 4th international conference che Universität München, Chair of Geoinformatics on smart data and smart cities, ISPRS, Kuala Lumpur, ISPRS Ruhdorfer R, Willenborg B, Sindram M (2018) Coupling of traffic Archives of the Photogrammetry, Remote Sensing and Spatial simulations and semantic 3d city models. gisScience 3:101–109 Information Sciences Samuel J, Périnaud C, Gay G, Servigne S, Gesquière G (2016) Repre- Datta SPA (2017) Emergence of digital twins—is this the march of sentation and visualization of urban fabric through historical doc- reason? J Innov Manag 5(3):14–33 uments. In: Catalano CE, Luca LD (eds) Eurographics workshop Elfes A (1989) Using occupancy grids for mobile robot perception and on graphics and cultural heritage. The Eurographics Association. navigation. Computer 22(6):46–57 https ://doi.org/10.2312/gch.20161 399 European Parliament and Council (2007) Directive 2007/2/EC of the Santhanavanich T, Schneider S, Rodrigues P, Coors V (2018) Integra- European Parliament and of the council of 14 March 2007 estab- tion and visualization of heterogeneous sensor data and geospatial lishing an infrastructure for spatial information in the European information. ISPRS Ann Photogramm Remote Sens Spat Inf Sci Community (inspire). Off J Eur Union 50(L 108):1–14 IV-4/W7:115–122 FIWARE (2018) Open source platform for the smart digital future. Smith B, Varzi AC (2000) Fiat and bona fide boundaries. Philos Phe- https ://www.fiwar e.org/. Accessed 16 May 2018 nomenol Res 60(2):401–420. https ://doi.org/10.2307/26534 92 Gröger et al (2012) OGC City Geography Markup Language (Cit- Sparx Systems (2015) Enterprise architect. http://www .spar x sy s te yGML) Encoding Standard, Version 2.0.0 ms.com/produ cts/ea/index .html. Accessed 04 Oct 2015 Hillier B, Hanson J (1984) The social logic of space. Cambridge Uni- Tomkins J, Lowe D (2016) Timeseries profile of observations and versity Press, Cambridge. https ://doi.org/10.1017/CBO97 80511 measurements, OGC Document No. 15-043r3. http://www.openg 59723 7 eospa tial.org/stand ards/tsml. Accessed 09 Sep 2018 Interactive Instruments (2019) Shapechange. https://shape c hange.ne t/. TUM-GIS (2019a) citygml2-to-citygml3. https ://githu b.com/tum-gis/ Accessed 05 Sep 2019 cityg ml2-to-cityg ml3. Accessed 05 Sep 2019 1 3 PFG (2020) 88:43–61 61 TUM-GIS (2019b) ifc-to-citygml3. https:/ /github. com/tum-gis/ifc-to- Yao Z, Nagel C, Kunde F, Hudra G, Willkomm P, Donaubauer A, cityg ml3. Accessed 05 Sep 2019 Adolphi T, Kolbe TH (2018) 3DCityDB—a 3D geodatabase solu- Vretanos PA (2010) Opengis web feature service 2.0 interface stand- tion for the management, analysis, and visualization of semantic ard OGC document no. 09-025r1. http://www.opengeospa tial.or g/ 3D city models based on CityGML. Open Geospat Data Softw stand ards/wfs. Accessed 02 Nov 2018 Stand 3(5):1–26 W3C (2014) Rdf 1.1 specifications. https ://www .w3.org/s t and ar ds/ techs /rdf#w3c_all. Accessed 04 Oct 2015 Yan J, Diakité AA, Zlatanova S (2019) A generic space definition framework to support seamless indoor/outdoor navigation sys- tems. Trans GIS 23(6):1273–1295 1 3

Journal

PFG – Journal of Photogrammetry, Remote Sensing and Geoinformation ScienceSpringer Journals

Published: Feb 26, 2020

There are no references for this article.