La teoría del aprendizaje de Lev Vygotsk

One of the most important software components that have been developed for this thesis is a 3D visualization client that is used for rendering 3D models and for interacting with the user. Due to the architecture of SDIs and involved workflows, a static viewer is not sufficient. The 3D client must include the logic of how to connect to various OGC compliant services, discover the

available resources and render subsets of available data efficiently and without unnecessary user interaction (e.g. specifying the bounding box to be displayed). The 3D client has been implemented in Java and is available as open source project XNavigator (http://sourceforge.net/projects/xnavigator). Figure 17 shows a screenshot of the graphical user interface.

The 3D visualization client has the following functions:

1) Support the OGC service interfaces that are relevant for the various use cases. All OGC service depicted in Figure 13 are supported. Each OGC standard provides an XML schema document describing the involved data structures and service operations. Using a process called Unmarshalling, these XML schema documents were transformed into a Java Object model, which can be used to parse service responses and prepare service requests without dealing with the serialized XML data stream.

2) Content, protocol, version, and language negotiation. The OWS Commons specification, from which W3DS, WMS, and other services are derived, supports a mechanism to request information on available data sets, supported versions, supported references systems, supported HTTP protocols, and available languages. The negotiation is especially important for connecting to various Web 3D Services automatically. A list of available layers along with their spatial extent, description, and available styles is retrieved from the server and shown in the Graphical User Interface. The W3DS interface provides additional information on available LODs and the intended scale range, so that the client can automatically adjust the visibility of layers and LODs accordingly. For instance, a layer containing highly detailed building models may provide a hint that this layer can be safely displayed at a scale larger than a specified threshold without overloading the client. The threshold value can be changed by the user manually or by the client’s configuration in order to display more data. Terrain layers have been mostly configured as tiled data sets and contain information on the spatial alignment of the tile set and the tile sizes of each individual LOD. This information is important for the 3D client in order to set up the internal quadtree scene graph data structure that is used for loading and unloading layer data.

3) Efficient rendering of 3D geo-data. Models are retrieved from the W3DS as VRML streams. Partly these models consist of many separate objects or parts. For example, a detailed building model is comprised of many elements representing façade details and other structures organized in a hierarchical scene graph structure. Often, the separation into objects each having its own geometry, material and texture, is unnecessary, as well as the depth of the scene graph. For optimizing the rendering process, geometries and textures can be merged together and transformation nodes can be combined by multiplying their transformation matrices. This method reduces the OpenGL rendering calls and necessary state changes. Since feature information is retrieved by additional W3DS requests, merging geometries can be done without altering the behavior of the system. The frame rate could be increased significantly by this optimization method. Other techniques typically found in rendering engines and that have also been used include creation of display lists for caching OpenGL calls, back side culling, and viewport culling.

4) Data loading and unloading. Data of each layer is only displayed within a specific range. Terrain layers are composed of many individual tiles with different sizes and different LODs. Object layers are divided into blocks that can be requested from the W3DS and integrated into the renderer’s scene graph according to the viewpoint position. In order to achieve this behavior, a quadtree index structure is created for each layer which is aligned to the layer’s

extent. Loading and unloading tiles representing the nodes of the quadtree is triggered by range entry and exit events, i.e. when the viewpoint comes closer or moved further away from the respective tile. Loading and unloading tiles depends on 3 values for determining the visual significance on the screen: a) distance to tile center, b) angle between the tile normal (up direction) and the vector from tile center to viewpoint, and c) angle between the viewing direction and the vector from tile center to viewpoint (Figure 16).

5) Defining custom styles. For creating meaningful cartographic visualizations, it is possible to define custom SLD styles, which can be used in W3DS GetScene requests. Based on information retrieved from GetLayer requests, rules can be defined on how to apply materials and 3D symbols.

6) Presentation of information retrieved from additional OGC services such as OpenLS Route Service, OpenLS Geocoder, OpenLS Directory Service, and Sensor Observation Service. Presenting 3D routes require a complex interaction and visualization schema. This includes displaying route instructions as overlays, and viewpoint animation along the route. Point data is displayed as 3D symbols or 2D overlay. Moreover, additional height information must be requested from an Elevation Query Service in case that z coordinates are missing.

Figure 16: The visual significance of tiles in the visualization component depends on three factors: 1. distance to the tile, 2. angle at which tile is rendered, and 3. angle between viewing direction vector and vector from viewpoint to tile.