34
Copyright © 2012 Op en G eos pati al Consortium
8.8.1.2.1 Te st: 3D sce ne in X3D format.
Figure 11 : Blacksburg 3 D scene in InstantPlay er on Linux.
Result: There are some minor incompatibilities with the viewpointcoordinate setup. When getting closer to the buildings, the scene was clipped. After adjusting the near
plane zratio in the InstantPlayer the s cene could be visualized as expected Figure 11.
8.8.2 Portrayal through W3DS using BS C ontact Ge o
In this experiment, the interoperability of X3D client software and a W3DS server was tested. In general the tests were successful in rendering 3D graphics data retrieved from a
CityServer3D instance in Bitmanagement’s BS Contact Geo. The experiment was run
with Bitmanagements Client software BS Contact Geo, Version 7.220, Development build 112011 accessing IGD’s CityServer3D instance hosting the Mainz data.
The client did use the server’s operation GetTileDefinition: http:IGD.3DPIE.OGC.orgMainzW3DS?do=GetTileDefinitiontemplate=entrypoint
surface=mainz_stadt This experiment did identify some inconsistencies regarding the interpretation and
implementation of the X3D standard, which could be resolved in the course of the experiment:
4. The field height of the GeoElevationGrid node was not exported correctly. Some of the numbers were replaced with a certain Unicode character.
Copyright © 2012 Op en Geos pati al Consortium
35 5. In XML coded X3D files some of the MFString attributes containing only one
string value were not coded correctly. The double quotes were missing. 6. In VRML coded X3D fields the PROFILE statement was missing.
7. In VRML coded X3D files all top-level nodes were enclosed in a Scene node. This is done only with XML coding.
8. Some MFString values in XML coded X3D files were not yet coded correctly. 9. Non-equal values for the xSpacing and zSpacing fieldsd of the GeoElevationGrid
node did lead to distorted geometries and renderings.
8.9 Me rging data from multiple We b 3D Se rvice s in XNavigator
The motivation for this experiment was to demonstrate the interoperability between multiple W3DS instances. We used the OSM-3D W3DS and the CityServer3D W3DS
implementations on server side and the integrated client XNavigator as client. The goal was to merge both data sets in the client by accessing the servers in parallel with only a
few configuration settings.
XNavigator is an open source development specifically designed as W3DS client and for visualizing global data sets with the accuracy needed for showing even the smallest
details in a global reference system. As W3DS client it supports the W3DS logic and syntax. It supports version and language negotiation as well as automatically parsing the
contents section providing information of available layers , styles, CRSs etc. Since the W3DS logic is supported, it must be possible to connect to any service instance.
XNavigator was already used as a client for GIScience’s W3DS in the OpenStreetMap3D project, which is available as live service.
The CityServer3D, developed by Fraunhofer was used as a second service instance due to its support of X3D. It contains the Mainz data sets, comprising building geometries,
sewage ducts, as well as a detailed model of an area around the Münsterplatz. The OSM - 3D W3DS by GIScience contains a terrain model, simple building geometries and points
of interest.
8.9.1 W orkflow
The workflow for integrating multiple W3DS servers in the XNavigator is illustrated by the sequence diagram in Figure 12.
As a first step, the service description meta data of CityServer3D was accessed using the GetCapabilities request and processed by the W3DS parser of XNavigator. This
proved to be possible without major problems because both, the service and the client connectors, were derived from the same reference XML schema.
The second step involved modification of the client code in order to support several server instances simultaneously. The client is configured at startup using an XML file,
which contains all service URLs, camera, light and navigation settings. The configuration