General Concepts¶
Level of Detail (LoD)¶
All spatial models are abstractions of reality. Some are closer to the real thing, while others are less so. In 3D GIS, the Level of Detail (LoD) of a 3D model describes the amount of detail that is captured in the model, although a high LoD can still be an inaccurate approximation of reality. For instance, consider a very simple building with four corners and a gabled roof. A very rough approximation of this building would be a cube. While on the other end, we could have individual surfaces in the model that follow the shape of the building exactly, each of them labelled with additional information like surface type, material etc.
Higher LoDs (LoD2 and above) can label the surfaces of the model based on their function in the real object. These labels are called semantics, and accordingly we call the labelled surfaces semantic surfaces. For instance in case of building models, we can identify a ground surface, wall surface, roof surface etc.
In the 3DBAG, we use the so called improved LoD specification, as it is displayed in the figure below.
For the 3DBAG the relevant LoDs are 1.2, 1.3, and 2.2. Note that apart from the amount of geometric detail, the key difference between LoD1 and LoD2 is the presence of semantic surfaces, to allow, for example, roof surfaces to be coloured red and wall surfaces to be coloured grey. Furthermore, the distinction between LoD1.2 and LoD1.3 is that LoD1.3 distinguishes between significant height differences within one building, while in case of LoD1.2 the whole model has a uniform height.
3D geometric primitives¶
In 2D GIS, the geometry of objects can be represented by points, lines, polygons and their variations. There are standards that prescribe a set of rules for these primitives so that data can be exchanged in an interoperable manner (eg Simple Feature Access).
In 3D GIS, the geometric primitives and their rules need to be extended to the third dimension, so that their interactions can be described in a meaningful way. The figure below gives an overview of the commonly used primitives in 3D GIS.
For the 3DBAG the most relevant primitive is the Solid, as we treat the building models as Solids in our process. This distinction is important, because of the (stricter) rules that apply to Solids, compared to other 3D primitives.
3D primitives and data formats
Not every data format supports the 3D primitives mentioned above. In fact, this applies to all our export formats except CityJSON. Therefore, in such formats we use the geometry types that are the closest equivalent to Solids. The PostgreSQL backup is a bit of an outlier here, because technically PostGIS can store Solids, but only with the SFCGAL extension. In order to cause the least friction for restoring the PostgreSQL backup, we store the 3D geometries as MultiPolygonZ.
Valid 3D geometries¶
Having valid geometries is important for using the data in various applications. Standards help to define a common set of rules to which both data producers and consumers can adhere to, when working with data. val3dity is a software that validates 3D primitives according to the international standard ISO19107.
We integrated val3dity into our process, and so we validate each 3D model after it is reconstructed. However, the building models are validated independently as they go through the reconstruction process. Therefore, we cannot detect errors in the interaction of multiple models (error codes above 500).
b3_val3dity_lod12", "b3_val3dity_lod13", "b3_val3dity_lod22
The attributes starting with b3_val3dity_ store the error codes from val3dity (if any) for a model.
