W orkflow Me rging 3D mode ls from W 3DS and image ry from W VS in XNavigator

38 Copyright © 2012 Op en G eos pati al Consortium

8.10 Me rging 3D mode ls from W 3DS and image ry from W VS in XNavigator

The motivation for this experiment was to figure out how image-based services Web View Service, panorama images, webcams, video feeds, orthographic imagery and geo - referenced imagery can be integrated into real 3D geo applications : Photographs and web cams may provide a much more accurate impression of how a site looks like. A precondition of merging such imagery with a 3D model is a proper definition of the location and viewing angles at which the photographs were taken. Often, switching to perspective and panoramic images requires an alternative set of behaviors for zooming and panning actions. Displaying imagery can be realized within the 3D application using textured spheres, boxes or canvases, without switching to a 2D rendering mode. Also, rendering s of synthetic 3D worlds can be “outsourced” to a dedicated rendering server which allows free definition of camera location, angles and other properties, in contrast to photographs. This is the purpose of the Web View Service. Performing server side rendering may be necessary, e.g., if 14. the 3D model is too big or too detailed to be rendered by the client at acceptable frame rates, 15. the network bandwidth is too limited to transmit the amount of data required for 3D models at reasonable time, 16. the rendering exploits advanced algorithms usually not available in real time graphics ray tracing, ray casting, caustics, soft shadows, depth blurring.

8.10.1 W orkflow

The XNavigator client was used as frontend for accessing W3DS and WVS. To have a basic 3D model as reference, the OSM-3D W3DS was used. The basic setup is identical to the setup used by the live osm-3d.org service. An additional panel was implemented as plug-in for accessing a WVS. It allows the user to set the URL of the service and a spatial reference system as EPSG code, which is used for describing coordinates in WVS requests. Once the user has navigated to a place where data is provided by the WVS, he can manually trigger GetView requests towards the used WVS. The GetView requests contains a perspective definition, which must be derived from the virtual camera of the 3D viewer Figure 14. The virtual camera is always defined as a 4x4 transformation matrix in computer graphics, from which the current position and viewing angles pitch, heading, roll can be easily extracted. A GetView request requires a point of camera POC, a point of interest POI, and an up vector UP. A POI can be generated using POC, camera orientation, and a default distance in that direction. Copyright © 2012 Op en Geos pati al Consortium 39 Figure 14 : Ex tra ction of GetView persp ective pa ra meters fro m the ca mera definition in XNavigato r and crea ting a virtual canvas for imag e display. Since the reference system used by the viewer may not be supported by the WVS, an optional coordinate transformation step must be implemented. For this purpose an external Coordinate Transform Service CTS can be used, supporting the full set of EPSG codes. This takes effect if the EPSG code in the WVS panel does not match the internally used reference system. The constructed request URL is used as texture on a small rectangular geometry that is placed in front of the camera. The so constructed virtual canvas occludes the 3D model in the background and displays the output of the WVS GetView request. 40 Copyright © 2012 Op en G eos pati al Consortium Figure 15 : Persp ective i mag ery fro m a WVS displayed in the 3D viewer XNavig ato r. The monta ge shows 3D con ten t from W3 DS left and WVS right for the sa me camera position.

8.10.2 Re sults