# Incorporating Topological Representation in 3D City Models

^{*}

## Abstract

**:**

## 1. Introduction

## 2. Related Work and Background Information

#### 2.1. The CityGML Data Model

#### 2.2. The CityJSON Data Format

`parents`and

`children`attributes can be used to associate references between city objects as follows:

#### 2.3. Topology in 3D City Models

#### 2.4. Linear Cell Complexes and Combinatorial Maps

## 3. Topological Representation of 3D City Models

#### 3.1. Data Model

`Dart`class (Figure 4). The class contains the necessary information as attributes: (a) the

`vertexPoint`attribute points to the

`Vertex`object that stores the coordinates of the zero-cell; (b) the

`parentCityObject`attribute points to the

`CityObject`associated with the dart’s two-cell; (c) the

`semanticSurface`attribute links the dart’s two-cell with the respective SemanticSurface (in case the original polygon has semantic information attached); and (d) the

`beta`attribute is a three-element array of

`Dart`objects, representing ${\beta}_{1}$, ${\beta}_{2}$ and ${\beta}_{3}$.

`Dart`class and its attributes can represent a complete linear cell complex, they only preserve one-way links from the C-Map to the city model. Nevertheless, it is equally important to be able to identify the three-cells that compose a city object without having to iterate through the whole linear cell complex. This is achieved by introducing the

`lccVolumes`attributes in the

`CityObject`class, which contains links to the three-cells related to the city object. As it is not possible to directly link to the three-cells, this list contains one of the volume’s darts.

#### 3.2. CityJSON Extension

`“vertices”`list as described in the CityJSON specification. This fits perfectly with the requirement of associating points to the zero-cells of the C-Map in order to achieve the linear geometric embedding. Therefore, it is sufficient for the completeness of the final dataset to store the dart information (their betas and parent object associations) and link them to the existing list of

`“vertices”`, instead of introducing a new list.

`“betas”`,

`“parentCityObject”`,

`“semanticSurface”`and

`“vertex”`), such a structure would produce a verbose JSON encoding. That is due to the fact that, for every dart in the dataset, the same attribute names would have to be repeated as keywords. Given the large amount of darts required in order to represent complicated cell complexes such 3D city models, this would result in a burst of the resulting file’s size. Instead, we decided to store the four attributes as lists with the same length, equal to the number of darts. This way we avoid the repetition of keywords as they only appear once in the file, thus minimising its size.

#### 3.2.1. Darts Representation

`“+darts”`root property in the main

`“CityJSON”`object. It contains four lists containing the values of the respective attributes of the LCCs darts:

`“betas”`,

`“parentCityObjects”`,

`“semanticSurfaces”`and

`“vertices”`. The

`“+darts”`object has also the

`“count”`property which states the number of darts in the LCC. These lists are indexed, so the nth element of every list corresponds to the respective attribute of the nth dart of the LCC (the lists are one-based numbered, therefore the first element of the list is denoted by the number “1”).

`“betas”`property contains the ${\beta}_{i}$’s of the darts. Every element of the list is an array of three integers which refer to the ${\beta}_{1}$, ${\beta}_{2}$ and ${\beta}_{3}$ of the current dart, respectively. In the case this dart is i-free, ${\beta}_{i}$ is set to −1. Otherwise, the ${b}_{i}$ refers to the respective dart’s index in the list.

`“parentCityObjects”`and

`“vertices”`properties are single lists. The first is composed of the IDs associated with the two-cells of each dart; and the second is composed of the index of the vertex, from the CityJSON’s

`“vertices”`list, associated with each dart’s zero-cell.

`“semanticSurfaces”`property associates the two-cell of a dart with a semantic surface of the city model. Every item of this list is an array of two integers, which refer to the indices of the geometry and the semantic surface, respectively, under the parent city object. If the two-cell of a dart does not have a semantic surface associated, then the value of the second value is set to −1.

`“darts”`object that would represent an LCC with one triangle:

#### 3.2.2. CityObject to LCC Association

`“+lccVolumes”`property in the

`“CityObject”`. The

`“+lccVolumes”`property is a list of darts that belong to the respective three-cells. It has to be noted that not all darts related to a city object are stored in this list; instead, one dart per three-cell is used as an index. Therefore, the number of elements in the list should be equal to the number of volumes associated with the city object.

## 4. Topological Reconstruction of 3D City Models

#### 4.1. Algorithm

`ReadCityObject`for every city object.

`ReadCityObject`(Algorithm 2) iterates through the geometries of the city object. For every geometry, function

`ReadGeometry`is called and, then, the created darts’ two-attributes are associated to the object’s id and geometry’s id.

`ReadGeometry`function (Algorithm 3) parses the geometry by getting all polygons that bound the object. For every polygon, the algorithm iterates through the edges and creates a dart that represents this edge, by calling

`GetEdge`. The newly created dart that represents the edge is, then, associated with the semantic surface of the polygon by assigning the respective two-attribute value. Finally, the algorithm accesses the items of index ${I}_{3}$ in order to find adjacent three-free two-cells, in which case the two two-cells must be three-sewed. This ensures that volumes sharing a common surface are going to have their adjacency relationship represented in the resulting LCC.

`GetEdge`(Algorithm 4) creates a dart that represents an edge, given the two end points of the edge. It gets one dart per point by calling the

`GetVertex`function and then conducts a one-sew operation between them. Finally, it iterates through index ${I}_{2}$ in order to find adjacent two-free one-cells so that they can be two-sewed.

`GetVertex`(Algorithm 5) is responsible for creating darts that represent a vertex in the LCC. The function iterates through the LCC in order to find existing one-free darts with the same coordinates as the point provided; if such a dart is found, it is returned. If no dart is found, the algorithm creates a new dart, associates the coordinates to its zero-attribute, and returns it.

Algorithm 1: Main body of reconstruction. |

Algorithm 2:ReadCityObject |

Algorithm 3:ReadGeometry. |

Algorithm 4:GetEdge. |

Algorithm 5:GetVertex |

- The runtime of GetVertex depends on the number of darts in the LCC (${d}_{lcc}$), i.e. its time complexity is of order $O\left({d}_{lcc}\right)$.
`GetEdge`calls`GetVertex`twice, which means that the complexity of the first part of the algorithm is ${d}_{lcc}$ as well. In a reasonable implementation, the sewing operation should be constant time, while the insertion and deletion should be logarithmic, and thus would not change the overall complexity. Because of this, the time complexity is again of order $O\left({d}_{lcc}\right)$.`ReadGeometry`iterates through all vertices of the given geometry (${v}_{g}$) and calls`GetEdge`, therefore the first iteration’s time complexity is of order $O\left({v}_{g}\right)\xb7O\left({d}_{lcc}\right)=O\left({v}_{g}\phantom{\rule{3.33333pt}{0ex}}{d}_{lcc}\right)$. As the second iteration depends on ${d}_{lcc}$, which does not change the order of complexity, the final time complexity of`ReadGeometry`is that of the first iteration: $O\left({v}_{g}\phantom{\rule{3.33333pt}{0ex}}{d}_{lcc}\right)$. This assumes the same logarithmic access to the index and constant time iteration from one dart to another (for sewing and setting attributes).`ReadCityObject`iterates through all geometries of a city object and calls`ReadGeometry`for every one, which means that the previous calls to`GetEdge`are applied to every vertex of the city object (as opposed to those of a single two-cell). Therefore, the algorithm depends on the size of all vertices of all geometries (${v}_{cityobject}$) and in accordance with`ReadGeometry`complexity it is of order $O\left({v}_{cityobject}\phantom{\rule{3.33333pt}{0ex}}{d}_{lcc}\right)$).- Finally, the main iteration repeats
`ReadCityObject`for every city object. Following the same logic as before,`GetEdge`ends up being called for every vertex of the city model (${v}_{citymodel}$). Therefore, the time complexity of the algorithm is of order $O({v}_{citymodel}\phantom{\rule{3.33333pt}{0ex}}{d}_{lcc}$).

#### 4.2. Implementation

`.3map`) or as a new CityJSON.

## 5. Validation of Methodology

#### 5.1. Datasets

- Den Haag dataset of buildings and terrain (https://data.overheid.nl/dataset/48265-3d-lod2-stadsmodel-2010-den-haag-citygml),
- Rotterdam’s Delfshaven dataset of buildings (http://rotterdamopendata.nl/dataset/rotterdam-3d-bestanden), and
- A dataset representing a landscape around a railway, originally introduced to demonstrate a plethora of CityGML 2.0 city object types.

#### 5.1.1. Den Haag

`TINRelief`and the rest are

`Building`objects. It contains 1991 LOD2 geometries of

`MultiSurface`and

`CompositeSurface`type, with semantic surfaces

`RoofSurface`,

`WallSurface`and

`GroundSurface`present.

#### 5.1.2. Delfshaven

`MultiSurface`geometries with three semantic surfaces present:

`RoofSurface`,

`WallSurface`and

`GroundSurface`.

#### 5.1.3. Railway Demo

`MultiSurface`and

`CompositeSurface`geometries with semantic surfaces.

#### 5.2. LCC Viewer

#### 5.3. Reconstruction and Evaluation of Datasets

## 6. Conclusions and Discussion

## Author Contributions

## Funding

## Acknowledgments

## Conflicts of Interest

## Abbreviations

C-Map | combinatorial map |

LCC | linear cell complex |

GML | geography markup language |

ISO | International Organization for Standardization |

BIM | building information modelling |

GIS | geographic information system |

JSON | JavaScript Object Notation |

## References

- Choi, J.; Lee, J. 3D Geo-Network for Agent-based Building Evacuation Simulation. In 3D Geo-Information Sciences; Lee, J., Zlatanova, S., Eds.; Springer: Berlin/Heidelberg, Germany, 2009; pp. 283–299. [Google Scholar] [CrossRef]
- Strand, R.; Baumgartner, K. Modeling radiant heating and cooling systems: Integration with a whole-building simulation program. Energy Build.
**2005**, 37, 389–397. [Google Scholar] [CrossRef] - Zhivov, A.M.; Case, M.P.; Jank, R.; Eicker, U.; Booth, S. Planning Tools to Simulate and Optimize Neighborhood Energy Systems. In Green Defense Technology; Springer: Dordrecht, The Netherlands, 2017. [Google Scholar] [CrossRef]
- Open Geospatial Consortium. City Geography Markup Language (CityGML) Encoding Standard; Version: 2.0.0; Open Geospatial Consortium: Wayland, MA, USA, 2012. [Google Scholar]
- Guo, Y.; Pan, M.; Wang, Z.; Qu, H.; Lan, X. A spatial overlay analysis method for three-dimensional vector polyhedrons. In Proceedings of the 2010 18th International Conference on Geoinformatics, Beijing, China, 18–20 June 2010; IEEE: Piscataway, NJ, USA, 2010. [Google Scholar] [CrossRef]
- Maria, M.; Horna, S.; Aveneau, L. Topological Space Partition for Fast Ray Tracing in Architectural Models. In Proceedings of the GRAPP 2014—9th International Joint Conference on Computer Graphics Theory and Applications, Lisbon, Portugal, 5–8 January 2014; pp. 225–235. [Google Scholar]
- Arroyo Ohori, K.; Ledoux, H.; Stoter, J. An evaluation and classification of nD topological data structures for the representation of objects in a higher-dimensional GIS. Int. J. Geogr. Inf. Sci.
**2015**, 29, 825–849. [Google Scholar] [CrossRef] - Arroyo Ohori, K.; Ledoux, H.; Stoter, J. A dimension-independent extrusion algorithm using generalised maps. Int. J. Geogr. Inf. Sci.
**2015**, 29, 1166–1186. [Google Scholar] [CrossRef] - Damiand, G.; Teillaud, M. A Generic Implementation of dD Combinatorial Maps in CGAL. Procedia Eng.
**2014**, 82, 46–58. [Google Scholar] [CrossRef] [Green Version] - Diakité, A.A.; Damiand, G.; Van Maercke, D. Topological Reconstruction of Complex 3D Buildings and Automatic Extraction of Levels of Detail. In Eurographics Workshop on Urban Data Modelling and Visualisation; Gonzalo Besuievsky, V.T., Ed.; Eurographics Association: Strasbourg, France, 2014; pp. 25–30. [Google Scholar] [CrossRef]
- Diakité, A.A.; Damiand, G.; Gesquière, G. Automatic Semantic Labelling of 3D Buildings Based on Geometric and Topological Information. In 3DGeoInfo Conference Proceedings Series, Proceedings of the 9th International 3DGeoInfo Conference (3DGeoInfo), Dubai, UAE, 11–13 November 2014; Karlsruhe Institute of Technology: Dubaï, UAE, 2014. [Google Scholar]
- Vitalis, S.; Ohori, K.A.; Stoter, J. Topological Reconstruction of 3D City Models with preservation of semantics. In Geospatial Technologies for All: Short Papers, Posters and Poster Abstracts of the 21th AGILE Conference on Geographic Information Science; Mansourian, A., Pilesjö, P., Harrie, L., von Lammeren, R., Eds.; Lund University: Lund, Sweden, 2018; Available online: https://agile-online.org/index.php/conference/proceedings/proceedings-2018 (accessed on 31 July 2019).
- Geographic Information—Spatial Schema; Standard, International Organization for Standardization: Geneva, Switzerland, 2005.
- Biljecki, F.; Ledoux, H.; Stoter, J. Improving the Consistency of Multi-LOD CityGML Datasets by Removing Redundancy. In 3D Geoinformation Science: The Selected Papers of the 3D GeoInfo 2014. Lecture Notes in Geoinformation and Cartography; Springer International Publishing: Cham, Switzerland, 2015; pp. 1–17. [Google Scholar] [CrossRef]
- Li, L.; Luo, F.; Zhu, H.; Ying, S.; Zhao, Z. A two-level topological model for 3D features in CityGML. Comput. Environ. Urban Syst.
**2016**, 59, 11–24. [Google Scholar] [CrossRef] - Hatcher, A. Algebraic Topology; Tsinghua University Press: Beijing, China, 2005. [Google Scholar]
- Čomić, L.; Floriani, L.D. Modeling and Manipulating Cell Complexes in Two, Three and Higher Dimensions. In Digital Geometry Algorithms; Springer: Dordrecht, The Netherlands, 2012; pp. 109–144. [Google Scholar] [CrossRef]
- Damiand, G.; Lienhardt, P. Combinatorial Maps: Efficient Data Structures for Computer Graphics and Image Processing, 1st ed.; A. K. Peters, Ltd.: Natick, MA, USA, 2014. [Google Scholar]
- Lienhardt, P. N-dimensional generalized combinatorial maps and cellular quasi-manifolds. Int. J. Comput. Geom. Appl.
**1994**, 4, 275–324. [Google Scholar] [CrossRef] - Vitalis, S.; Ohori, K.A.; Stoter, J. A Framework for the Representation of Two Versions of a 3D City Model in 4D Space. ISPRS Ann. Photogramm. Remote Sens. Spat. Inf. Sci.
**2018**, IV-4/W6, 81. [Google Scholar] [CrossRef]

**Figure 2.**Example of a two-dimensional C-Map describing two polygons [20]. The graph is composed of seven zero-cells (vertices), eight one-cells (edges) and two two-cells (facets). These cells are described by darts (denoted as arrows) and their ${\beta}_{i}$s (denoted as dashed arrows). Every edge of a facet is described by a dart and ${\beta}_{i}$’s are used to describe the links between them: ${\beta}_{1}$ is the dart of the “next” edge of the same facet and ${\beta}_{2}$ is the dart of the “next” facet of the same edge. ${\beta}_{0}$ is a special link to the dart of the “previous” edge of the same face. In this example, only one dart’s ${\beta}_{i}$s are shown.

**Figure 4.**The UML diagram that describes the proposed Linear Cell Complex integration with the CityGML data model.

**Figure 5.**The Delfshaven dataset visualised in the LCC viewer according to three different colour formatting options. (

**a**) Every facets (two-cells) is coloured according to the city object in the CityJSON structure. This figure proves that buildings that are merged in the same volume (three-cell) maintain their association with the original city objects. (

**b**) All facets (two-cells) that are incident to the same volume (three-cell) have the same colour. This figure highlights the topological characteristics of the dataset and shows that multiple semantically individual buildings have been merged, topologically, under the same volume. (

**c**) Every facet (two-cell) is being coloured according to the semantic surface related to it: red highlights roof surfaces and white highlight walls. This figure proves that the the resulting dataset maintains the association between facets (two-cells) and semantic surfaces in the CityJSON structure.

**Figure 6.**Topologically invalid surfaces and “noisy” single-edged volumes were identified in the Delfshaven LCC when the buildings of the area where hidden.

Dataset | File Size (MB) | Number of | |||||||
---|---|---|---|---|---|---|---|---|---|

Original | Final | City Objects | Geometries | Darts | Zero-Cells | 1-Cells | 2-Cells | 3-Cells | |

Den Haag | 3.00 | 8.56 | 2498 | 1991 | 84,795 | 24,835 | 42,658 | 21,804 | 1991 |

Delfshaven | 2.60 | 7.08 | 853 | 853 | 68,500 | 26,782 | 42,644 | 15,484 | 1192 |

Railway demo | 4.31 | 18.92 | 121 | 105 | 243,491 | 76,821 | 135,514 | 65,196 | 5789 |

© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Vitalis, S.; Arroyo Ohori, K.; Stoter, J.
Incorporating Topological Representation in 3D City Models. *ISPRS Int. J. Geo-Inf.* **2019**, *8*, 347.
https://doi.org/10.3390/ijgi8080347

**AMA Style**

Vitalis S, Arroyo Ohori K, Stoter J.
Incorporating Topological Representation in 3D City Models. *ISPRS International Journal of Geo-Information*. 2019; 8(8):347.
https://doi.org/10.3390/ijgi8080347

**Chicago/Turabian Style**

Vitalis, Stelios, Ken Arroyo Ohori, and Jantien Stoter.
2019. "Incorporating Topological Representation in 3D City Models" *ISPRS International Journal of Geo-Information* 8, no. 8: 347.
https://doi.org/10.3390/ijgi8080347