3D Geo-DBMS

Benefits of Using DBMS for GIS and AEC Applications
Clearly, there are a lot of reasons to use spatial DBMSs in both GIS and CAD/AEC systems: multi-user control on shared data and crash recovery, automatic locks of single objects while using database transactions, advanced database protocol mechanisms to prevent the loss of data, data security, data integrity and operations that comfortably retrieve, insert and update data.It is likely that the significance of spatial DBMS in both GIS and AEC worlds will continue to increase.

Most GIS and CAD system users would be concerned if there was no multi-user access possible on data during design processes.It is no question that the results of their work being constructed on shared data should be automatically stored within the database periodically.Furthermore, unpredictable events such as a power breakdown, wrong operating by the user, or hardware error, etc.should not cause the loss of data.Fortunately, multi-user control and crash recovery are two of the standard functions in today's DBMSs. The user does not have to care about obtaining exclusive data access. The DBMS automatically locks single objects or tables using database transactions so that several users can access the same objects, reading or even updating them at the same time.Furthermore, advanced database protocol mechanisms prevent the loss of data by writing the data on disk beforehand.

Other very useful DBMS functions concern data security and the checking of data integrity.Thus the correctness and the consistency of thematic and spatial data can be automatically checked during the input of the data and during the execution of database queries.Typical examples are the checking of the data types for input data and the checking of their domains. Finally, DBMSs offer operations for the comfortable retrieval, insertion and update of non-spatial data.Therefore standard relational or object-relational DBMSs are well suited to store and retrieve the values of non-spatial attributes of geo-objects.

What is the current status of Geo-DBMSs and what still has to be done for enabling the support both GIS and CAD/AEC applications?

Geo-DBMS Development
Although designed for non-spatial data, DBMS has been linked with spatial data.Initially GIS vendors used DBMS mainly to store thematic, i.e.non-spatial data.Few GIS vendors (e.g.ESRI) went the way to store both non-spatial and spatial data into DBMS.Such solutions can be referred to as 'top-down' approaches, because from an architectural point of view, the DBMS functionality has been constructed 'under' the GIS application and the GIS application accesses 'top-down' to the geodata stored in the DBMS.

The second way and more interesting development within DBMS was the support of spatial data types.This solution is called a 'bottom-up approach,' because it extends 'low level' DBMS data types and indexes to use them in the upper level of GIS applications.Data analysis on the spatial and non-spatial parts of objects can be executed.Since the nineties more and more commercial DBMSs provide such spatial extensions to offer support of spatial objects.

Geo-DBMSs provide spatial data types and spatial functions (and operations) on them that define the spatial functionality of a Geo-DBMS.A Geo-DBMS knows primitive and composed geometric data types in the same way as its primitive standard data types such as character, string, integer, real etc. A Geo-DBMS is a 3D Geo-DBMS if it:

Supports 3D data types, i.e.point, line, surface and volume in 3D Euclidean space based on 3D (topological or geometrical) models.
Offers 3D spatial functionality, i.e.spatial operations and functions embedded in its query language that can operate with the 3D data types.

Geometry and topology are often used in Geo-DBMS terminology (in contrast to OpenGIS specifications) as synonyms to denote the two ways of describing spatial data types.Geometry data types are described by the x,y,z coordinates of the points composing a data type.Topology data types have references to the unique identifiers of low-dimensional objects.

Although there is a belief that a topological model might be sufficient (geometry can be derived from topology), in the same way one could argue that the same is true for a geometry model, because topology can be derived from geometry.In this respect, one can choose between three different options.

Storing the topological model in the 3D Geo-DBMS (and deriving geometry from it)
Storing the geometric model in the 3D Geo-DBMS (and deriving topology from it)
Storing both models in the 3D Geo-DBMS

In the first approach the topological relationships between object parts, such as 'all surfaces belonging to the boundary of a 3D volume object' are stored in a topology model.The location of objects, i.e. the x,y,z coordinates of its defining points, are not part of the topology model.This approach can quickly identify topological properties, e.g. 'find neighboring walls,' but it is inefficient in queries needing coordinates, e.g. 'visualize the object'.

The second approach prevents the disadvantage of the first approach.However, topological queries have higher computational complexity.

The third approach seems to be the best solution: it allows flexible topological and geometric database queries executed efficiently by accessing the topology and geometry model in the Geo-DBMS.With these two models all relevant types of spatial database queries can be executed:

topological database queries (neighborhoods etc.),
metric database queries (distances),
geometric database queries (e.g.spatial search inside a 3D box).

3D Geometry in DBMS
Mainstream DBMSs Oracle, IBM DB2, Informix, PostGIS and MySQL support geometric data types and offer a large spectrum of functions, but all spatial data types are basically 2D.However, the major problem is that their implementations differ from each other.The standard SQL statement: "select attribute_a from table_b where a < 100" is the same in every DBMS.However, if geometries are concerned, different types of queries have to be executed in the different DBMSs. For example, Oracle Spatial does not have explicitly implemented data types such as point, line and polygon.There is only one complex data type, sdo_geometry, composed of several parameters indicating type geometry, dimension, and an array with the x,y,z coordinates.

Although the geometry types are 2D, 3D objects still can be stored in main stream Geo-DBMS in two ways: using the existing data types or creating user-defined spatial types.Using the first approach, the 3D objects are represented as a set polygons (with 3D coordinates) composing the object.The representations vary depending on the DBMS, i.e.a 3D object can be stored as one (using data type multipolygon) or many (using polygon) records in one table.This approach has the advantage of being 'understandable' for all the front-ends (GIS/CAD/AEC), since it is supported by the DBMS (Figure 1).

Figure 1: Visualization of 3D object (stored in Oracle Spatial) in MicroStation GeoGraphics

The major disadvantage is that the DBMS is not aware of the 3D object, e.g.it cannot be validated or the volume cannot be computed.Some researchers have already developed and implemented 3D geometry data types.Indeed, they are specific for a particular DBMS and are still not recognized by the spatial extent of the DBMS.However, such developments can be used by the Open Geospatial Consortium to adjust the specifications.

3D Topology in Geo-DBMS
At present, no DBMS supports 3D topology.The problems with topology are much more complex compared to the geometry.Usually many application-related issues used to be taken into consideration, e.g. the space partitioning (full, embedding), the object components (volumes, faces), the construction rules (planarity, intersection constraints, etc.).The 3D topological data structures reported currently in the literature can be subdivided in two large groups: structures maintaining objects and those maintaining relationships.While in the first group (object oriented), most of the relationships between the objects are to be derived, in the second group (topology oriented), the representation of the objects has to be derived.Many structures, which are a typical example of explicit storage of objects, also maintain explicit storage of relationships, i.e.singularities.

Clearly, advantages of a topological representation in one of the aspects occur as disadvantages in another aspect.For example, the arbitrary number of nodes per face can be seen as an advantage and disadvantage for different applications.It is very convenient for modelling complex 3D objects (e.g.buildings) since an inappropriate partitioning (into triangles) is not required, but the operators for consistency check become very complex.

Since no agreement on a 3D topological representation exists, alternative approaches are investigated.Instead of looking for an appropriate 3D topological representation, it is suggested extending the DBMS kernel with meta information describing different topological structures in the DBMS.Such topological meta information can then be used both within the DBMS and outside the DBMS. In general, meta information (or system catalogs) of a DBMS contains descriptions of the data stored in the database: tables, attributes and types, and also contains descriptions of the available types and operators.

3D Operations in DBMS
Although it is possible to maintain objects with 3D coordinates, the functions implemented still omit the z-value.Some exceptions are PostGIS and MapInfo Spatialware Datablade (based on Informix) that do support geometry calculation such as 3D length and 3D perimeter in 3D. Existing spatial functions are developed only on the basis of a geometry model (with exception Oracle Spatial 10g), but they still can perform topological operations such as overlap, touch, etc.

The problem with 3D operations is twofold: first, the existing operations have to extend to consider the z-coordinate, and second, new operations have to be developed on the basis of topological models.

Furthermore, since the two models (geometry and topology) are to be maintained in DBMS, operations for conversion between the two has to be ensured, i.e.operators for building topology and operators for realization of geometry.

Toward Bridging AEC and GIS
Cleary DBMS can be used as a bridge between AEC and GIS applications.Currently many AEC vendors such as Bentley and Autodesk, as well as many GIS vendors (ESRI, MapInfo, Intergraph) use the spatial models of Geo-DBMSs.Although many interoperability issues (maintenance of color, texture, attributes) still have to be developed, the experiments show promising results, i.e.models stored on Geo-DBMS can be visualized and edited from both GIS and AEC applications.

To be able to provide a stronger management of objects from AEC and GIS, Geo-DBMSs have to extend their spatial support to accommodate design objects (coming from AEC) and real-world objects (considering new data collection and modeling techniques).Some of the required developments are listed below.

Real 3D geometry types and corresponding 3D validity operations. Many objects coming from AEC applications are well defined closed spaces and their integrity has to be recognized by Geo-DBMSs.
Freeform curves and surfaces. AEC applications have a large number of freeform curves and surfaces, basically not used in GIS.To be able to combine 3D design models (modeled in CAD) with existing situations (modeled in GIS), specialized data types for freeform surfaces are needed.Among a large amount of mathematical representations of 3D space, NURBS could be one possible solution. NURBS are approved as industry standard for the representation and design of geometry.
Point cloud data types. With the progress of data collection techniques, existing data types and spatial indexing appeared to be insufficient.Nowadays laser-scanned technology easily generates millions of points for a single building. DBMSs fail to handle efficiently such amounts of data.
TIN data type. Most of the terrain representations presently maintained in GIS as well as many CAD designs (meshes) are TIN representations.TINs can be stored in DBMS using the polygon data type.This data type is generally assumed for multiple vertices and thus over-attributed.Thus a simpler adapted data type is required.
Maintenance of multiple representations to be used as LOD.The management of multiple representations is still far from formalized.Users take care of their own implementations, which however cannot benefit from the indexing mechanisms in the Geo-DBMS.
Management of texture and mechanism for texture mapping and texture draping.3D objects usually need more physical attributes compared to 2D objects. Very often 3D objects are textured with images from the real world.As AEC and GIS applications come together, the question of linking textures to geometries will appeal.Textures have to serve as attributes of 3D objects decoded in the data types.

Questions such as 3D functionality are next to be considered.It should not be forgotten that Geo-DBMS in the first place is a DBMS, i.e.the location for storage and management.The 3D functionality should not be completely taken away from GIS and CAD/AEC applications.3D Geo-DBMSs should provide the basic (simple) 3D functions, such as computing volumes and finding neighbors.Complex analysis have to be attributed to the applications.

Other installments published to date in this series: