Abstract
In this paper, a novel approach to specify application-specific requirements for 3D City Models is proposed. A modular set of geometric and semantic requirements that are based on the OGC CityGML Quality Interoperability Experiment (Coors and Wagner in Fernerkundung und Geoinformation eV 24:288–295, 2015) has been specified. Depending on the purpose of the model, not all requirements are mandatory. For example, if the model is used for visualization only, solid geometry is not required. However, if the same model should be used for analytic purpose such as heating demand simulation, solid geometry is mandatory. A formal definition of a validation plan is proposed in this paper to specify the application-specific set of requirements. This gives the city model manufacturers the possibility to provide proof that their model is usable in certain applications and can certify a certain level of quality. The concept is evaluated with the definition of a validation plan for heating demand simulation. It has been successfully implemented using the Software CityDoctor and SimStadt.
Zusammenfassung
Ein Konzept für das Qualitätsmanagement von 3D-Stadtmodellen zur Unterstützung von anwendungsspezifischen Anforderungen. In diesem Beitrag wird eine neue Methode zur Spezifikation anwendungsabhängiger Anforderungen an 3D-Stadtmodelle vorgestellt. Ein modularer Satz von geometrischen und semantischen Anforderungen, die auf dem “OGC CityGML Quality Interoperability Experiment” basieren (Coors und Wagner in Fernerkundung und Geoinformation eV 24:288–295, 2015) wurde definiert. Je nach Zweck des Modells sind nicht alle Anforderungen zwingend erforderlich. Wenn das Modell beispielsweise nur zur Visualisierung verwendet wird, spielt die Volumengeometrie keine Rolle. Wenn jedoch dasselbe Modell für analytische Zwecke wie der Simulation des Heizungsbedarfs verwendet werden soll, ist die genaue 3D-Geometrie erforderlich. Der Artikel schlägt einen Validierungsplan vor, der abhängig von der Anwendung jeweils einen Satz von Anforderungen festlegt. Dies gibt den Herstellern von Stadtmodellen die Möglichkeit, den Nachweis zu erbringen, dass ihr Modell für bestimmte Anwendungen geeignet ist und dabei ein bestimmtes Qualitätsniveau garantiert. Unser Konzept wurde am Beispiel einer Heizungsbedarfsanalyse überprüft und erfolgreich in der Software CityDoctor und SimStadt implementiert.
Similar content being viewed by others
Explore related subjects
Discover the latest articles, news and stories from top researchers in related subjects.Avoid common mistakes on your manuscript.
1 Introduction
The digital transformation process of cities has become visible through the concept of a “Smart City”. More and more information and communication technology are employed to solve urban development challenges such as natural resource management, air quality, mobility, sustainable food, water, and energy supply (Balakrishna 2012; Calvillo et al. 2016; Nam and Pardo 2011). Cities have a share of up to 80% of the world’s greenhouse gas emissions (Murray 2015). Besides industry and transportation, heating and cooling of buildings is one of the main sources of \(\mathrm{CO}_2\) emission. Reducing this heating and cooling demand will have a significant impact on climate protection worldwide.
To achieve this aim and to develop integrated energy concepts in urban districts, it is necessary to have an insight into the energetic performance of the areas of interest. Forecasting the future energy demand for heating and cooling for buildings at district level and beyond is essential for the development of climate protection strategies for municipalities world wide. This requires methods to simulate the impact of future developments such as refurbishment of buildings and reliable data of the existing building stock.
The availability of 3D building models has increased tremendously. Most of the models are available in CityGML (Kolbe 2009; Gröger and Plümer 2012). Some urban simulation tools such as SimStadt (Nouvel et al. 2015) and CitySim (Robinson et al. 2009) support CityGML as an input heating and cooling demand simulation. The simulation results strongly depend on the quality of the input data. As an example, small errors in the building geometry can have a big impact on the calculated volume of a building (Biljecki et al. 2018).
To illustrate this, a simple experiment has been set up. A building with a rectangular footprint (3 m \(\times\) 5 m) and a saddle roof with 3 m eaves height and 4.5 m ridge height is modelled in CityGML with LoD 2 solid geometry. Each polygon of the building geometry is defined by a sequence of points in counterclockwise order. A FME workbench is created to read the model and calculate the volume using the Transformer VolumeCalculator (Fig. 1). The resulting volume is \(56.25\,\mathrm {m}^3\), which is correct. An error is then introduced into the model. The orientation of one polygon is changed by defining it with a sequence of points in clockwise order. The geometry is still the same, no coordinates have been modified. But calculating the volume of this model leads to a volume of \(18.75\,\mathrm {m}^3\). As the heating and cooling demand of a building depends on the volume, this will lead to wrong simulation results.
In this paper, a general methodology to define application-specific requirements to a 3D City Model is proposed. This methodology is independent of a specific software solution, but of course, an implementation is needed to validate existing models. In this paper, the software CityDoctor is used for this purpose.
The paper is organized as follows: Sect. 2 will give a brief summary of the state of the art in quality management of 3D City Models. In Sect. 3, an overview of a monthly energy balance to calculate the heating and cooling demand of a building is given. A general methodology to validate 3D City Models is introduced in Sect. 4, with a focus on geometry validation in Sect. 5. This methodology is applied in Sect. 6 to validate if a 3D City Model is suitable for heating and cooling demand simulation. Section 7 shows an implementation of this validation process in a use case in the city district “Stadtgärtnerei” in Mainz, Germany. The paper concludes with discussion of the proposed methodology and the achieved results in Sect. 8.
2 State of the Art
In 2015, Biljecki et al. summarized applications that make use of 3D City Models from interactive visualization, urban planning, shadow and viewshed analysis to urban analytic and simulation (Biljecki et al. 2015). These applications have very different requirements to the input data. For interactive visualization, it is sufficient to represent a building geometry by a set of non-overlapping polygons, with no further constraints. In contrast, urban analytics and simulation usually includes the calculation of building volumes. In this case, a solid geometry of the building is mandatory. These different requirements have to be taken into account in quality management of 3D City Models. As CityGML is an XML format, any CityGML document can be validated against the XSD schema. However, this does not include any validation of the geometry or can take into account application-specific requirements.
Ledoux (2013) has proposed a methodology to validate solid geometry. Wagner et al. (2013a, b) take into account not only geometry, but also include some semantics such as BoundarySurface into the validation process. Both approaches have laid the foundations for the OGC CityGML Quality Interoperability Experiment (QIE) to define a unified method for the validation of 3D City Models (Coors and Wagner 2015). The result of this activity was the specification of a set of validation rules that can be used to validate CityGML models and conformance requirements as defined in the CityGML standard. However, application-specific requirements are not taken into account. In 2016, Biljecki at al. did a survey on the quality of existing CityGML models in Biljecki et al. (2016). However, the purpose of the model was not taken into account in this study. This is fundamental, as for example, a building geometry that consists of MultiSurface geometry using triangles only is valid according to the CityGML standard. The standard requires a MultiSurface OR a solid geometry in all levels of detail.
The Working Committee of the Surveying Authorities of the Laender of the Federal Republic of Germany (AdV) has defined a CityGML profile for a nation-wide CityGML building model in 2016 (Landesamt 2019). This profile defines some restrictions such as a building has to have a solid geometry, and requires some mandatory attributes such as building function. Based on the results of CityGML Quality Interoperability Experiment, the AdV has published a validation plan for their profile in 2017 to enable quality management on a nation-wide CityGML 3D building model in LoD 1 and LoD 2.
To summarize, lot of work has been done to validate solid geometry. However, a systematic approach to take into account application-specific requirements in the validation process is not in practise yet. On the other hand, many existing models are suited for visualization, but not necessarily for urban analytics and simulation applications, as this usually requires a valid solid geometry.
3 Monthly Energy Balance
3.1 Balance Equations
By applying the first law of thermodynamics to a given building (see Fig. 2), we have:
Assuming a constant temperature inside the building (thanks to an idealized heating system), we get:
3.2 Building Simulation in SimStadt
SimStadt is an urban energy simulation tool (Nouvel et al. 2015). Several workflows are available, including a Monthly Energy Balance simulation based on DIN V 18599 (Din 2007).
The geometry is imported and then analyzed to determine building type, volume, external area and shared walls area. Additional attributes are required for the simulation, e.g. building function and year of construction. A coordinate reference system also needs to be defined in order for weather and irradiance calculations to be possible.
3.3 Influence of Geometry on the Energy Balance
The building geometry has an influence on each of the terms included in the Eq. (1). As an example:
Polygon orientation must be correct to calculate solar gain.
Building volume is used to estimate the internal area, which impacts internal gains and specific heat demand.
The total area of exterior surfaces is used to estimate ventilation and conduction losses.
Trying to calculate the volume of buildings as described in the introduction with a faulty geometry can lead to wrong results. To avoid those errors, SimStadt flags building with negative volume or with volumes that are larger than their bounding box. They can be either ignored or replaced by their bounding boxes.
4 Methodology
To validate if a CityModel or more precisely a XSD-valid CityGML document fulfills the requirements of a specific application, the following approach is proposed in this paper. First of all, a formal system to specify such requirements has been developed. In addition, an algorithm is needed to check whether a CityGML document fulfills a requirement or not. A validation software implements these algorithms. To ensure interoperability, the specification of the validation plan as well as the requirements have to be agreed upon. Based on the CityGML QIE, a modular set of requirements is proposed.
For a specific application, a subset of these requirements is chosen to define a validation plan. This approach will be evaluated by a validation plan for heating demand simulation. The results of the model validation include a reference to the validation plan to report what has been validated, and the validation results of any CityObject. The entire process from the CityGML document to the simulation results is shown in Fig. 3. Please note that the improvement of the 3D City Model usually requires some semi-automatic iterations. The entire process has been evaluated with a use case in the City of Mainz. To calculate the heating energy demand, the software SimStadt has been used. Data were provided by the City of Mainz. The focus of this study is the validation process, not the simulation itself.
5 CityGML Validation
As CityGML is based on XML, each CityGML file is an XML document.
Definition 1
A CityGML document is schema conform, if it is validated against the CityGML XML Schema Definition and no errors are found.
However, an XSD valid CityGML file is not always suited for simulation purposes, as CityGML itself allows many different options to model a building (Coors and Wagner 2015). Several additional requirements have to be fulfilled for this purpose.
Definition 2
A requirement r is a verifiable criterion that says something about the content of a CityGML document or the data described therein.
As an example, a building has to have a valid solid geometry and the attributes yearOfConstruction and usage are mandatory in heating demand simulation. Even if these attributes and the building geometry are missing, the CityGML document is XSD valid, as all these elements are optional in the standard.
Definition 3
Let D be the set of valid CityGML documents and \(d \in D\). A check \(c_r: D \rightarrow \mathrm{Boolean}\) is a function to validate a given CityGML document against the requirement r:
If \(c_r\) returns false, a specific error code including additional parameters can be stored.
Definition 4
A validation plan is a set of requirements \(R = \{ r_0, r_1, ..., r_n \}\) together with a set of checks \(C = \{ c_{r_0}, c_{r_1}, ..., c_{r_n} \}\) that shall be used to validate these requirements.
It is possible that some requirements are necessary in every validation plan for every application. To be as general as possible, no set of requirement is defined which may be applied to all city models. If there is such a set, those requirements are simply included in every validation plan.
Definition 5
A validation software is an implementation of algorithms to perform the checks of the validation plan.
The requirements and the related checks have to be defined and agreed by data suppliers, data producers and data consumers to be able to develop data sets that can be used for multiple purposes. The aim of the OGC CityGML QIE (Coors and Wagner 2015) is to come up with such definitions. In the following section, a validation plan for a 3D building model to be used to calculate the heating demand of a set of buildings using a monthly energy balance in the simulation software SimStadt, will be proposed. The validation plan is based on the CityGML QIE and can be used for input data to a similar simulation software such as CitySim.
5.1 Validation Plan for Heating Demand Simulation Using CityGML Building Models
The requirements of a CityGML data building model for heating demand simulation using a monthly energy balance method can be summarized as follows, depending on the level of detail of the building model:
In case of LoD 1:
the CityGML document has to be XSD valid
element yearOfConstructionFootnote 1 is mandatory for each building
element functionFootnote 2 is mandatory for each building
each building and building part has to have a valid lod1Solid geometry
Remark 1
If a building part has no element yearOfConstruction or function, the value from the parent building shall be used in SimStadt.
In case of LoD 2:
the CityGML document has to be XSD valid
element yearOfConstruction is mandatory for each building
element function is mandatory for each building
each building and building part has to have a valid lod2Solid geometry
each valid building and building part has to have valid Roof-, Wall-, Ground-, OuterFloor-, OuterCeilingSurfaces with an unambiguous azimuth and tilt
Remark 2
According to the CityGML standard, boundary surfaces such as Wall-, Roof-, and GroundSurface shall not be used in LoD 1. In SimStadt, they are required, but can be automatically derived from a valid solid geometry.
Some of these requirements can be expressed in a formal language such as XQuery or Schematron (Wagner et al. 2014). In Coors and Wagner (2015), Schematron is proposed to validate CityGML conformance requirements. This approach is used to formalize the above-mentioned requirements as well. Each requirement will be identified by a given id and a related error code if the requirement is not fulfilled.
The requirement that the element yearOfConstruction is given per building in the CityGML document can be expressed in Schematron as follows:
Similar rules can be defined for other mandatory elements such as function and lod1Solid. For simplicity, the name of the mandatory element is a parameter of this requirement. It is named SE-bldg:BU-0001 following the naming conventions of Coors and Wagner (2015). The same requirement for building parts is called SE-bldg:BP-0001.
However, geometry validation cannot be expressed as a Schematron statement as several geometric constrains have to be fulfilled to proof that a collection of polygons is a valid solid. A solid is defined in ISO 19107 (ISO 2003) as:
“A Solid is the basis for 3-dimensional geometry. The extent of a solid is defined by the boundary surfaces. The boundaries of Solids shall be represented as SolidBoundary. [...] The OrientablesSurfaces that bound a solid shall be oriented outward.”
In CityGML, the SolidBoundary consists of polygons only. A polygon is defined by one exterior linear ring and 0 or more interior linear rings. Interior linear rings are used to model polygons with holes. Rules to validate solid in CityGML have been published in Coors et al. (2019) and Ledoux (2013).
5.2 Ring Checks
Definition 6
An ordered set or sequence is an ordered list of elements. Unlike a set, order matters, and the exact same elements can appear multiple times at different positions in the sequence. A finite sequence \(a\) with \(n+1\) elements is denoted as \(a = ( a_0, a_1, ..., a_n )\). The empty sequence \(a = ()\) has no elements.
Definition 7
A finite sequence of points
\(R = ( P_0, P_1, ..., P_n )\) is a valid linear ring if
- I
R has at least four points: \(n \ge 3\)
- II
All points of the sequence besides first and last point are different: \(P_i \ne P_k, i=0..n-1, k=0..n-1, i \ne k\)
- III
The first and last point \(P_0\) and the last point \(P_n\) are the same: \(P_0 = P_n\)
- IV
Two edges \((P_i, P_i+1) \, {\rm and} (P_k, P_k+1), i=0,...n-1, k=0,..n-1, i \ne k\) do only intersect in one start-/ endpoint. No other intersection is allowed.
If all points of the sequence are co-planar, the linear ring is planar.
Table 1 defines five requirements GE-gml:LR-0001 to GE-gml:LR-0005 that are necessary to validate a linear ring. If a requirement is not fulfilled, a specific error code is reported. Requirement GE-gml:LR-0001 corresponds to (I). GE-gml:LR-0002 only ensures that two consecutive points are different. If two non-consecutive points beside the first and the last point are the same, it violates requirement GE-gml:LR-0004 (self intersection). GE-gml:LR-0002 and GE-gml:LR-0004 together are the same as II and IV. GE-gml:LR-0005 is redundant, as it is always a violation of GE-gml:LR-0004 (self intersection), but may give some hints to improve the building geometry later.
Planarity of a linear ring is not required, but is defined on polygon level.
Usually, the coordinates of a point \(p \in R\) are given as floating point numbers. A parameter \(\tau > 0\) and a norm have to be introduced to define equality of two points. The default norm is the \(l^2\) norm.
Definition 8
Two points P and Q are the same if \(\Vert (P,Q)\Vert _2 < \tau\). \(\tau > 0\) is called the just notable difference (JND) of two points.
Remark 3
The JND of two points is not the same as the precision of the point location. For example, the precision of a measured point location can be 10 cm, but two different points might have a distance of 1 cm. These points are still two different points, even though there are some uncertainty in the location of the points.
The impact of such a definition is illustrated by the following example of a real-world CityGML building model. The building model with gml:id=DENW22AL10000c8S of the CityGML document LoD1_362_5700_1_NW.gmlFootnote 3 contains a very small polygon in the LoD 1 geometry. Two times two consecutive points of that polygon have just a 1mm difference in the x-coordinate, y- and z-values are exactly the same. If the model is validated against the linear ring requirements with a minimal point distance \(\tau = 0.0005\), the geometry is valid. With a minimal point distance of \(\tau = 0.0011\), the linear ring is not valid any more. Two GE_R_CONSECUTIVE_POINTS_SAME errors will be thrown during validation. And it will lead to GE_R_SELF_INTERSECTION and GE_R_COLLAPSED_TO_LINE errors as the polygon degenerates to a line in this case (Fig. 4).
As the ADV specifies the use of three digits after the decimal separator in its CityGML profile for LoD 1 and LoD 2 building geometry (Landesamt 2019), \(\tau = 0.0005\) is a good threshold value in this case and the model is valid. The parameter JND of two points is very essential for the validation process and should be added to the metadata of the CityGML document.
5.3 Polygon Checks
Definition 9
A set of planar linear rings
\(S = \{R_0, R_1, ..., R_n \}, S \ne \emptyset\) is a valid polygon if
- I
the exterior linear ring \(R_0\) and all interior linear rings \(R_1, ..., R_n\) are co-planar.
- II
The interior linear rings must be completely included in the area defined by the exterior linear ring. Interior linear rings must not overlap or be included in another interior linear ring.
- III
Interior linear rings and the exterior linear ring touch each other in a finite number of points.
- IV
The inner of the polygon, as defined as the inner of the exterior ring excluding the inner of the interior rings, is connected.
- V
The order of points of the exterior linear ring defines the orientation of the polygon. The interior linear rings have to have the opposite orientation.
The interior linear rings define holes in the polygon.
Table 2 gives an overview of the related requirements for polygons. Requirement GE-gml:PO-0002 ensures that (I) is fulfilled. Planarity of a polygon (within a given tolerance) can be defined using distance of all point to a regression plane or by the deviation of the normal vector. For the deviation algorithm, the polygon needs to be tesselated. Each of the resulting triangles has a normal vector n resulting in a set of normal vectors for the polygon \(N = \{n_0, n_1, ..., n_m\}, S \ne \emptyset\). The polygon is planar if the scalar product of two normal vectors is less than a given threshold \(\tau\)\(\forall N_i \in N, \forall N_k \in N : \langle N_i, N_k\rangle < \tau\).
GE-gml:PO-0001, GE-gml:PO-0004 and GE-gml:PO-0005 correspond to (II) and (III), GE-gml:PO-0003 to (IV) and GE-gml:PO-0006 to (V).
5.4 Solid Checks
Definition 10
The set \(W = \{ S_0, S_1, ..., S_n \}, n \ge 4\) of polygons is a solid geometry if:
- I
The intersection of two polygons \(S_a \in W\) defined as a set of planar linear rings \(S_a = \{ R_0^a, R_1^a, ..., R_n^a \}, S_a \ne \emptyset\) and \(S_b \in W\) defined as a set of planar linear rings \(S_b = \{ R_0^b, R_1^b, ..., R_m^b \}, S_b \ne \emptyset\) is either empty or contains only a set of points \(Q \ne \emptyset\) and a set of edges \(E \ne \emptyset\) that are part of both sets of linear rings:
$$\begin{aligned} s_a \cap s_b = {\left\{ \begin{array}{ll} \emptyset \\ Q \ne \emptyset , \forall q \in Q: q \in \bigcup _{i=0...n} R_i^a \wedge \\ q \in \bigcup _{j=0...m} R_j^b , \text { and } E \ne \emptyset , \\ \forall e=(q_i, q_j) \in E: q_i \in Q, q_j \in Q, \\ \exists i, j: e \text { is an edge in both } R_i^a \text { and } R_j^b \end{array}\right. } \end{aligned}$$ - II
\(e=(p_i, p_j)\) is an edge in \(R_1 \in S_j, j=0...n \implies ( e=(p_j, p_i)\) is an edge in \(R_2 \in S_k, k=0...n, k \ne j \wedge e=(p_i, p_j)\) is not an edge in any other polygon \(R \in S_k, k=0...n, k \ne j\).
- III
All polygons \(R \in S_j, j=0...n\) are oriented such that the normal vector of each polygon points to the outside of the solid.
- VI
The dual graph \(G_W = (V_W, E_W)\) of \(W\) is connected. \(G_W\) consists of a set of nodes \(V_W\) and a set of edges \(E_W\). Every node \(v \in V_W\) represents one polygon of \(S \in W\). An edge \(e=(q_i, q_j)\) shared by two polygons \(S_a \in W\) and \(S_b \in W\) is represented by an edge \(e_ab\) in \(E_W\).
- V
For every point P of a linear ring R of a polygon \(S \in W\) applies: The graph \(G_P = (V_P, E_P)\), that is built by polygons and edges that touch P is connected. Each node \(v \in V_P\) represents a polygon in which a linear ring contains P. Two nodes are connected by an edge \(e \in E_P\) if the two polygons represented by the nodes have a common edge that touches P.
The statement of (I) formulates the intersection of the two polygons Sa and Sb. The intersection results in an edge, which is an existing edge in both of the polygons. Polygons should always only “touch” along existing edges. The intersection must not be a new edge.
The statement of (VI) formulates the requirement that the graph is connected.
From (I) and (II) follows that the surface defined by \(W\) has no holes. Together with conditions (IV) and (V), it follows that the inner of the solid is connected.
If all these requirements of a solid’s geometry have been fulfilled, the solid is valid (Table 3).
Definition 11
The set \(M = \{ S_0, S_1, ..., S_n \}, M \ne \emptyset\) of polygons is a MultiSurface geometry.
5.5 Scalability
All geometric requirements have been implemented as checks in the CityDoctor software and tests have been conducted to ensure that massive amount of data can be processed in a reasonable time frame.
For this test, a PC with an i5-2400 @ 3.1 GHz was used.
The file was a DLM-Model of Niedernhall with a filesize of 3.3 GB. The batch process was completed in 4 m and 50 s while utilizing 1 core and less than 2 GB RAM, producing a pdf and an xml report output file.
5.6 Order of Requirements
Requirements depend on each other. In general, polygon requirements depend on the ring requirements and solid requirement depend on the polygon and ring requirements. Every polygon has to be a valid polygon before the solid requirements can be checked, otherwise it is possible to get false positive or false negative errors, which only lead to confusion.
For a detailed view of the dependencies, refer to the wiki of CityDoctor Validation Plan for SimStadt where all requirements and checks are listed and described. A dependency graph can be found in Coors and Betz (2019).
5.7 Storing the Validation Results as Metadata
The results of the performed checks and the validation plan itself need to be stored as metadata. Other applications can use the metadata to ensure the validity of their calculations. Once there are known errors, the result may also be wrong but if no error has been reported, one can assume the correctness of the calculation.
The metadata need to contain the validation plan to know which requirements were checked, the parameters used for the checks (e.g. point equality distance), the validation results, the date and the file or model that was validated. For this purpose, a reference between metadata and model is possible.
6 Validation Plan for Monthly Energy Balance
Not every requirement is useful for every use case. Each use case must specify a set of requirements and parameters to ensure that it works correctly.
To simplify the definition of a validation plan, an addition requirement GE-gml:SO-0009 (valid solid geometry) is introduced to group all the necessary requirements.
The validation plan for building models with LoD 2 geometry is more complex as each building and building part has to have valid Roof-, Wall-, and GroundSurfaces with an unambiguous azimuth and tilt. A boundary surface has a lod2MultiSurface geometry with no further constraints.
Similar to the solid geometry, a grouping requirement GE-gml:MS-0001 is introduced to validate multisurface geometry. A MultiSurface geometry \(M\) is valid if all polygons \(S \in M\) are valid. To ensure that BoundarySurfaces such as Roof-, Wall-, and GroundSurface have an unambiguous azimuth and tilt, all polygons \(S \in M\) of the lod2MultiSurface geometry \(M\) of the BoundarySurface shall be coplanar within a given tolerance.
For the monthly energy balance in SimStadt the requirements for LoD 1 are listed in Tables 4 and 5. For LoD 2, more requirements are needed because of the necessary boundary surfaces which need to be referenced by the solid. Table 6 has those additional requirements listed. Additionally for both LoD 1 and LoD 2, a coordinate system needs to be defined in the CityGML file. This is necessary to retrieve weather data for the city, which is needed for the simulation.
The validation plans for SimStadt have already been implemented in CityDoctor to verify CityGML files for the usage in SimStadt.
7 Example Stadtgärtnerei Mainz
As a use case, the heating demand of the city district Stadtgärtnerei in the City of Mainz, Germany is simulated using SimStadt based on a 3D Model of the existing building stock. As input data, a CityGML file containing the LoD 2 geometry of the buildings was provided by the City of Mainz. The first step before the simulation can be performed is to validate the model according to the specified validation plan. CityDoctor v3.2.0 was used. As a result, the application found several hundred GE_R_CONSECUTIVE_POINTS_SAME errors. An overview of the initial error distribution can be seen in Fig. 5. These kinds of errors are not necessarily detrimental to the simulation process, but they do inhibit some algorithms in the calculation. If two points have the same or nearly the same coordinates, they create an edge that has a zero-length or a nearly zero-length. Such an edge can result in some extreme values for some calculations. The checks are organized hierarchically. Thus, a following check depends on the result of the previous. However, in some cases it is necessary to perform a check without having completed the previous checks. In this case, the error code GE_R_CONSECUTIVE_POINTS_SAME “hides” any previous errors, which are to be detected at a later stage. Consequently, those checks are not executed and it is, therefore, unknown if they would have found further errors (Fig. 6).
Fixing the model was an iterative process starting with GE_R_CONSECUTIVE_POINTS_SAME errors. After removing those, further errors were found. Most of them were GE_S_NON_MANIFOLD_EDGE, GE_S_NOT_CLOSED and GE_S_MULTIPLE_CONNECTED_COMPONENTS errors. More rare were GE_S_POLYGON_WRONG_ORIENTATION errors were found more rarely.
The manifold edge errors were the result of polygons located inside the geometry. While the geometry looks correctly from the outside, these superfluous polygons have an impact in the calculations, specifically the volume calculation. The volume calculation takes every available polygon into account, which consequently results in wrong results.
Another error that has a major impact on the volume calculation is the wrong orientation of a polygon.
After the repair of the CityGML model, SimStadt was able to calculate the heat demand of the city quarter.
8 Conclusion
The workflow of validating the GML models before the simulation works very well as there is now a possibility to judge the validity of the simulation results. The validation plan will be used in the simulation software SimStadt in the workflow to automatically create an indicator on the uncertainty of the resulting values.
For better feasibility in validating the models, it is imperative that the creator of the CityGML files inserts the accuracy of the vertices into the file as a mandatory parameter. Otherwise, choosing a useful JND may result in “guesswork” or the chosen JND may not be useful. As an example, if a file has a vertex accuracy of three decimal places and two JNDs are chosen for two different validation plans, respectively, 0.0001 m and 0.00001 m. They would both have the same result as the input data do not have the necessary accuracy to support those JNDs.
The validation plans can also lead to a categorization of the 3D-Models. Not every CityGML file is applicable for any application. To check whether the file can be used or not, the validation plans and the validation software are applied. Manufacturers can on the basis of our approach specify that their model can be used for some applications while for others, they may provide a different model.
This may lead to the fact that each application produces its own model with each of those being a different one. However, this is not the intention of the concept.
Our investigation has rather revealed a hierarchy of categories where the lower categories are specializations of the higher ones. Consequently, a city model manufacturer has the choice of selecting a higher category with its usability for all applications or a lower category, which serves specific requirements.
8.1 Future Work
It is planned to extend CityDoctor to implement a repair feature where faulty buildings are allowed to be in a (semi-)automatic process. This is not a simple task, as there are many ways to fix seemingly simple errors with different results and repercussions.
A working group is implementing validation plans for further applications to ensure that the methodology provided in this paper is applicable to multiple applications.
Notes
yearOfConstruction is a child element of building, and not an attribute in CityGML.
Function is a child element of building, and not an attribute in CityGML.
Open data: https://www.opengeodata.nrw.de/produkte/geobasis/3d-gm/3d-gm_lod1/3d-gm_lod1_EPSG25832_CityGML, last access 20.9.2019.
References
Balakrishna C (2012) Enabling technologies for smart city services and applications. In: 2012 sixth international conference on next generation mobile applications, services and technologies, pp 223–227. https://doi.org/10.1109/NGMAST.2012.51
Biljecki F, Heuvelink GB, Ledoux H, Stoter J (2018) The effect of acquisition error and level of detail on the accuracy of spatial analyses. Cartogr Geogr Inf Sci 45(2):156–176
Biljecki F, Stoter J, Ledoux H, Zlatanova S, Çöltekin A (2015) Applications of 3D city models: state of the art review. ISPRS Int J Geo-Inf 4(4):2842–2889
Biljecki F, Ledoux H, Du X, Stoter J, Soon KH, Khoo V (2016) The most common geometric and semantic errors in CityGML datasets. ISPRS Ann Photogramm Remote Sens Spat Inf Sci 4:13–22
Calvillo C, Sánchez-Miralles A, Villar J (2016) Energy management and planning in smart cities. Renew Sustain Energy Rev 55:273–287. https://doi.org/10.1016/j.rser.2015.10.133
Coors V, Wagner D (2015) CityGML Quality Interoperability Experiment des ogc. DGPF Tagungsband. Publikationen der Deutschen Gesellschaft für Photogrammetrie. Fernerkundung und Geoinformation eV 24:288–295
Coors V, Betz M (2019) Requirements and checks for the validation of 3D city models encoded in CityGML. https://gitlab.com/volkercoors/CiD4Sim/wikis/validation/Requirements. Accessed 20 Sept 2019
Coors V, Gröger G, Häfele K-H, Casper E (2017) Modeling guide for 3D objects—part 1: basics (rules for validating GML geometries in CityGML) (version 0.7.1). http://en.wiki.quality.sig3d.org/index.php/Modeling. Accessed 28 May 2019
Din V (2007) 18599: Energetische Bewertung von Gebäuden - Berechnung des Nutz-, End- und Primärenergie- bedarfs für Heizung, Kühlung, Lüftung, Trinkwarmwasser und Beleuchtung. Deutschland: Februar
Gröger G, Plümer L (2012) CityGML-interoperable semantic 3D city models. ISPRS J Photogramm Remote Sens 71:12–33
ISO I (2003) 19107:2003 Geographic information-Spatial schema. International Organization for Standardization (TC/211): Geneva, Switzerland
Kolbe TH (2009) Representing and exchanging 3D city models with CityGML. In: 3D geo-information sciences. Springer, Berlin, Heidelberg, pp 15–31
Landesamt für Digitalisierung, Breitband und Vermessung Bayern: Die amtlichen 3d-Gebäudemodelle in der Ausprägung lod1 (lod1-de). http://www.adv-online.de/AdV-Produkte/Weitere-Produkte/3D-Gebaeudemodelle-LoD/. Accessed 12 Sept 2019
Ledoux H (2013) On the validation of solids represented with the international standards for geographic information. Comput Aided Civ Infrastruct Eng 28(9):693–706
Murray S (2015) How technology can reduce consumption in cities. https://www.weforum.org/agenda/2015/02/how-technology-can-reduce-consumption-in-cities/. Accessed 12 Sept 2019
Nam T, Pardo TA (2011)Conceptualizing smart city with dimensions of technology, people, and institutions. In: Proceedings of the 12th annual international digital government research conference: digital government innovation in challenging times, ACM, pp 282–291
Nouvel R, Brassel KH, Bruse M, Duminil E, Coors V, Eicker U, Robinson D (2015) Simstadt, a new workflow-driven urban energy simulation platform for CityGML city models. In: Proceedings of international conference CISBAT 2015 future buildings and districts sustainability from nano to urban scale, CONF, LESO-PB, EPFL, pp 889–894
Robinson D, Haldi F, Leroux P, Perez D, Rasheed A, Wilke U (2009) CitySIM: comprehensive micro-simulation of resource flows for sustainable urban planning. In: Proceedings of the eleventh international IBPSA conference, CONF, pp 1083–1090
Wagner D, Alam N, Coors V (2013a) Geometric validation of 3D city models based on standardized quality criteria. In: Urban and regional data management. CRC Press, pp 203–216
Wagner D, Wewetzer M, Bogdahn J, Alam N, Pries M, Coors V (2013b) Geometric-semantical consistency validation of CityGML models. In: Progress and new trends in 3D geoinformation sciences. Springer, Berlin, Heidelberg, pp 171–192
Wagner D, Coors V, Benner J (2014) Semantic Validation of GML-based geospatial data. In: Breunig M (ed) 9th 3D geoinfo conference 2014, Dubai, UAE, November 11–13, 2014, p 15
Acknowledgements
Open Access funding provided by Projekt DEAL. The authors would like to thank the participants of the research projects SimStadt and CityDoctor as well as the members of 3D City Model quality management working group of their for valuable input and discussion. The project SimStadt 2.0 is supported by the German Ministry of Economics (Contract 3ET1459A). The Project CityDoctor 2.0 is funded within the program Forschung an Fachhochschulen by the German Federal Ministry of Education and Research (Contract 13FH179PB6). The 3D City Model quality management working group is voluntary work under the umbrella of the Joint Commission on 3D City Models (https://3d-stadtmodelle.org/) of the German Society of Cartography and the German Society of Photogrammetry, Remote Sensing, and Geoinformation.
Author information
Authors and Affiliations
Corresponding author
Ethics declarations
Conflict of interest
The authors declare that they have no conflict of interest.
Rights and permissions
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, 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 included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
About this article
Cite this article
Coors, V., Betz, M. & Duminil, E. A Concept of Quality Management of 3D City Models Supporting Application-Specific Requirements . PFG 88, 3–14 (2020). https://doi.org/10.1007/s41064-020-00094-0
Received:
Accepted:
Published:
Issue Date:
DOI: https://doi.org/10.1007/s41064-020-00094-0