Comparative Analysis of Data Structures for Storing Massive Tins in a DBMS

Abstract

ABSTRACT:Point cloud data are an important source for 3D geoinformation. Modern day 3D data acquisition and processing techniques such as airborne laser scanning and multi-beam echosounding generate billions of 3D points for simply an area of few square kilometers. With the size of the point clouds exceeding the billion mark for even a small area, there is a need for their efficient storage and management. These point clouds are sometimes associated with attributes and constraints as well. Storing billions of 3D points is currently possible which is confirmed by the initial implementations in Oracle Spatial SDO PC and the PostgreSQL Point Cloud extension. But to be able to analyse and extract useful information from point clouds, we need more than just points i.e. we require the surface defined by these points in space. There are different ways to represent surfaces in GIS including grids, TINs, boundary representations, etc. In this study, we investigate the database solutions for the storage and management of massive TINs. The classical (face and edge based) and compact (star based) data structures are discussed at length with reference to their structure, advantages and limitations in handling massive triangulations and are compared with the current solution of PostGIS Simple Feature. The main test dataset is the TIN generated from third national elevation model of the Netherlands (AHN3) with a point density of over 10 points/m 2 . PostgreSQL/PostGIS DBMS is used for storing the generated TIN. The data structures are tested with the generated TIN models to account for their geometry, topology, storage, indexing, and loading time in a database. Our study is useful in identifying what are the limitations of the existing data structures for storing massive TINs and what is required to optimise these structures for managing massive triangulations in a database.

Compactly representing massive terrain models as TINs in CityGML

“…Given that the vertices follow a Poisson distribution, the average degree of a vertex in a 2D Delaunay triangulation is exactly 6 (Okabe, Boots, Sugihara, & Chiu, 2009). This suggests that on average each vertex is stored 6 + (6/3) = 8 times in the Simple Feature structure (Kumar et al, 2016b). The size of the dataset increases considerably with this repeated storage of vertex information for every triangle.…”

“…This stores every triangle of the TIN as references to the IDs of the three vertices forming the triangle (Kumar et al, 2016b). The vertices are stored in a separate list with IDs and are not repeated for every triangle like in Simple Feature.…”

“…The vertex coordinates (x, y, z) are stored in a separate list with their IDs. To generate a TriStrip, we start with the three vertices of a triangle, then add a new vertex, and drop the oldest vertex to form the next triangle in sequence (Speckmann & F I G U R E 5 Indexed Triangle (Kumar et al, 2016b). Every triangle T is represented by the IDs of the three vertices (v 1 , v 2 , v 3 ) forming the triangle F I G U R E 6 Triangle+ (Kumar et al, 2016b).…”

“…To generate a TriStrip, we start with the three vertices of a triangle, then add a new vertex, and drop the oldest vertex to form the next triangle in sequence (Speckmann & F I G U R E 5 Indexed Triangle (Kumar et al, 2016b). Every triangle T is represented by the IDs of the three vertices (v 1 , v 2 , v 3 ) forming the triangle F I G U R E 6 Triangle+ (Kumar et al, 2016b). Every triangle T is represented by the IDs of the three vertices (v 1 , v 2 , v 3 ) forming the triangle and its three adjacent triangles {T1, T2, T3} Snoeyink, 2001).…”

“…With advancements in 3D data acquisition and processing technologies, it is now possible to generate billions of 3D points even for an area of a few square kilometers, and, therefore, the TIN generated from these points is also massive in size. Based on the literature review and experiments conducted, we found that there are several problems in storing these massive TINs with CityGML (Kumar et al, 2016b). First, CityGML datasets become very F I G U R E 7 TriStrip (Speckmann & Snoeyink, 2001).…”