A Citygml Extension for Handling Very Large Tins

Abstract

ABSTRACT:In addition to buildings, the terrain forms an important part of a 3D city model. Although in GIS terrains are usually represented with 2D grids, TINs are also increasingly being used in practice. One example is 3DTOP10NL, the 3D city model covering the whole of the Netherlands, which stores the relief with a constrained TIN containing more than 1 billion triangles. Due to the massive size of such datasets, the main problem that arises is: how to efficiently store and maintain them? While CityGML supports the storage of TINs, we argue in this paper that the current solution is not adequate. For instance, the 1 billion+ triangles of 3DTOP10NL require 686 GB of storage space with CityGML. Furthermore, the current solution does not store the topological relationships of the triangles, and also there are no clear mechanisms to handle several LODs. We propose in this paper a CityGML extension for the compact representation of terrains. We describe our abstract and implementation specifications (modelled in UML), and our prototype implementation to convert TINs to our CityGML structure. It increases the topological relationships that are explicitly represented, and allows us to compress up to a factor of ∼25 in our experiments with massive real-world terrains (more than 1 billion triangles).

Compactly representing massive terrain models as TINs in CityGML

“…Simple Feature representation for a triangle in ISO 19136:2007 implementation standard GML (Kumar et al, ). The first vertex ( x1, y1, z1 ) of every triangle is repeated as the last vertex ( x1, y1, z1 ) to close the linear ring…”

“…We plan to use 3DCityDB (https://www.3dcitydb.org/) (PostgreSQL) for the database implementation of the ADE. Our previous tests have shown that it takes a significantly larger amount of time to populate and index the TIN datasets with the Simple Feature structure than the index‐based data structures in the database (Kumar et al, ). In the case of the ADE, we expect that the loading time from the CityGML ADE file to the database will most likely improve.…”

“…The spatial index will be smaller as it does not require creating a complex spatial index like giST (in case of Simple Feature). The indexing can be accomplished at the vertex level with a simple B‐tree (Ledoux, ; Kumar et al, ).…”

“…The vertices are stored in a separate list with IDs and are not repeated for every triangle like in Simple Feature. For instance, in Figure 5, a triangle T has three vertices with IDs {v 1 , v 2 , v 3 } each with a tuple of location coordinates (x, y, z (Kumar et al, 2016a). The first vertex (x1, y1, z1) of every triangle is repeated as the last vertex (x1, y1, z1) to close the linear ring Another variation of the Indexed Triangle structure is Triangle+, which stores triangles along with their adjacency information.…”

“…Therefore, the main focus of this article is to develop an improved representation for storing massive terrains as TINs in the context of 3D city models. This article is an actual implementation of and extension to the ideas that we proposed in the initial phase of the research (Kumar, Ledoux, & Stoter, ). In this article, we review different data structures for compactly representing TINs, and explore how they can be implemented in GML/CityGML to efficiently store massive TINs.…”