A major difference between regular 2D geo information systems and Virtual Reality applications is the way how data is created and displayed. 2D map features are always described in geographic coordinates or in a map projection. The data creation process usually involves global positioning systems, surveillance techniques, and rectified aerial imagery from which users can trace map features on the desktop.
On the other side, the data creation process for 3D buildings often involves expert systems for automatically processing point clouds created by laser scanning or photogrammetric techniques. In this approach the spatial reference can be reconstructed using control points and by aligning the point cloud prior to the automatic model creation process. Software for creating 3D animations, CAD, scientific visualization, and game engines however, uses a hierarchical structure for assembling parts and grouping geometries to higher level elements. 3D modeling and CAD software for creating detailed object models do not use geodetic or cartographic reference systems but a local Cartesian coordinate system. A scene graph data structure is common in Virtual Reality and 3D modeling applications. The advantage of scene graphs is that models and parts can be defined in local coordinate space and moved to the final position by applying rotation and translation matrices. Parts can be grouped to higher entities, which can be transformed as a whole.
Parts can also be reused easily without actually making a copy. This concept is referred to as geometry instancing and is generally used in 3D graphics for speeding up the rendering process. As an example, a program for Building Information Modeling (BIM) may be connected to a parts library containing typical building and interior elements which can then be placed multiple times and modified easily. Extending the concept of geographical modeling in a single reference system to BIM would make is very difficult to edit such detailed 3D models. Another advantage is the possibility to describe and display dynamic content. Temporal changes and animations are achieved by modifying the transformation matrices of objects. Typically, key frames are defined along a timeline, and the actual position and orientation of an object at a specific time is interpolated between key frames. This way, prototypical dynamic objects such as wind generators with rotating blades could be provided by a Web 3D Service and embedded in a virtual landscape model.
The implications of using scene graph data structures in 3D GIS are explained in detail in chapter 7. It not only allows embedding detailed and dynamic 3D assets but also using complex terrain data derived from terrestrial laser scans as shown in Auer et al. (2011). Terrain is usually streamed as raster data sets with elevation values. By replacing these raster data sets with scene graph objects including free form meshes, not only the triangulation can be optimized for the actual surface structure but also overhanging parts at very steep mountain walls or caves can be modeled. This was demonstrated by processing a terrestrial laser scan of a culture heritage site with engravings, sculptures, and small niches in a natural stone face. Several LODs were produced from the scan by mesh simplification. Due to the size of the scan a simple discrete LOD schema was not sufficient. Therefore, all levels were passed through a cutting process for generating rectangular tiles of various sizes which could then be imported into a Web 3D Service and streamed as tiled data set for a walkthrough VR application (see Figure 14).
Another example of integrating highly detailed models is a terrestrial laser scan of a statue (Marienstatue in Heidelberg, see Figure 14), from which a 3D model has been created and integrated into the 3D SDI for Heidelberg. Multiple scans from different angles were made and combined to a single triangle mesh using specific alignment software for point clouds. Materials and textures of the statue and the socket were created from photographs in order to create a natural look. The spatial alignment and correct geo-referenciation was ensured by recording GPS positions of the LIDAR scanner and by using photographs. Since the resulting mesh was extremely dense, it was passed through a mesh reduction software so that the model could be handled by the server and 3D clients. The statue was made available as extra object layer through a Web 3D Service along with other similar objects such as fountains.
The scene graph concept for 3D GIS replaces specialized data structures for specific feature types with generic data structures. For example, raster images encoding elevation as grayscale image are replaced by triangle meshes; specialized point data structures for describing labels and POIs are replaced by prototypes with 3D text and billboards. These can be encoded in roalty free formats and other 3D graphics formats that are commonly used for exchanging and viewing 3D assets.
Figure 14: Data from terrestrial laser scanning embedded as scene graph objects and streamed through a Web 3D Service. Left: cultural heritage site in Sichuan, China. Right: Marienstatue in Heidelberg.
As an example, the suitability of X3D has been assessed, which is an ISO standard (ISO/IEC 19775-19777) for encoding complex geospatial data (see chapter 7). X3D is often used in scientific work and supports all necessary features for efficient and dynamic web visualizations. 3D geometries are described as a list of unique coordinates in local Cartesian space and a list of index values forming the triangles. Additional lists can be included for describing vertex colors and wrapping a texture image on the geometry. Using indexed geometry data structures is a major distinction to CityGML, which is derived from GML and thus uses polygon rings in order to describe planar faces. Polygon rings directly containing lists of coordinates produce a lot of redundancy, which is unwanted if the system architecture must be optimized towards data throughput and rendering performance. Non-indexed geometries make optimizations such as creating triangle strips difficult. Moreover, polygons (possibly containing holes) require a triangulation algorithm in order to create triangle lists that can be sent to the graphics pipeline (e.g. OpenGL).
In X3D, transformation matrices for placing objects are described as separate vectors for the translation, rotation, and scale components in order to make editing easier. Prototypical objects can be embedded as external references using URLs and instantiated by providing a location and orientation of each individual object. Depending on the implementation of the X3D parser, OpenGL Vertex Buffer Objects (VBOs) and Index Buffer Objects (IBOs) or similar techniques in DirectX can be used for making rendering prototypical objects more efficient. Since X3D includes an optional geospatial component for specifying exact locations relative to a spatial reference frame, e.g. the WGS 84 ellipsoid, geo transformation nodes and other geo specific features, it is well suitable for being used in a geospatial visualization framework.
However, also drawbacks were found. In GIS, text labels must be readable at all scales and should not overlap each other. Optimal label placement has been a research topic on its own. Although the behavior of label displacements on the screen for avoiding overlaps cannot be generally encoded in a 3D exchange format, maintaining a legible text size is also difficult to achieve. In X3D, text is always rendered as 3D object and the size is defined in metric units. In order to dynamically change the text depending on the distance to the viewpoint, so that screen size can be kept static, multiple LOD nodes were included. However, switching between discrete LODs creates visual discontinuities and does not provide a smooth visualization. Using 2D overlays or coupling the text size with the distance is currently not possible.
Other widely-used formats such as COLLADA and 3DS have similar capabilities, but focus more on the representation of solid 3D objects, without support of interactive features such as dynamic billboards. In order to provide the geospatial reference frame, COLLADA models must be embedded in a separate KML file containing the WGS84 coordinate of the model’s origin.
Figure 15: Transformation of a scene graph containing a hierarchy of transformation nodes from a web Mercator projection to local Cartesian coordinates and integration in a global model (right).
Using scene graph data structures in GIS implies additional computations for operations that are otherwise quite simple when using typical GIS standards such as the Simple Feature Specification or CityGML. For instance, the creation of a spatial index on a 3D data set may require deriving a 2D footprint for each object or even part, which is not explicitly stored in generic scene graph models. Another aspect is the requirement of a geo-service to support multiple coordinate reference systems in order to be used by various applications and contexts. This requires a transformation of complex scene graphs between coordinate reference systems. In this thesis, data sets from the same service have been used for being displayed in the local map projection Gauss- Krüger Zone 3 (EPSG:31467), in a Spherical Mercator projection (EPSG:3857) and on a Virtual Globe, i.e. in a global Cartesian system. Especially in the OpenStreetMap project, data is always edited in the Spherical Mercator reference frame and stored in WGS84. Displaying such data on a Virtual Globe requires a re-projection and scene graph transformations. The procedures and formulas for performing transformations of hierarchical scene graphs are described in chapter 7. This transformation involves travelling along the scene graph structure from the base to the leaf nodes and multiplying and projecting each transformation matrix.