First X3D example to visualise geological layers in the web

Recently I have played around with tools to visualise geological layers in 3D in the web, preferably without any browser plugins. With HTML5 and WebGL some really cool possibilities arise. WebGL is not supported by every browser, but apparently  all newer cool browsers like Chrome or Firefox, as well as Safari and Opera support WebGL at least experimentally. What a surprise that Microsoft Internet Explorer does not net yet support neither HTML5 canvas nor WebGL. But luckily there is the Chromeframe plugin :-)

If anyone has ever been working with OpenGL for 3D stuff probably in C or C++, well, WebGL is quite arcane, too, but in JavaScript ^^

Nevertheless, X3D for the rescue. X3D is a) an ISO standard (ISO/IEC 19775-1.2:2008 ), b) the successor of the working, but not really successful VRML97 (ISO/IEC 14772-1.2:1997) and c) a fully XML-based scenegraph declarative language. And the final ingredient is the Fraunhofer IGD experimental open source framework x3dom that thrives to integrate X3D content into HTML5.

Well, to the actual task. I am supposed to visualise a 3D geological model that originally has been designed with EarthVision(c). EarthVision(c) has its own binary format to store the 3D models, but they van be exported to a simpe XYZ-ASCII file:

2696105 6047205 150 20 11
2696605 6047205 150 21 11
2697105 6047205 150 22 11
2697605 6047205 150 23 11
2701105 6047205 150 30 11

...

The first two columns are Easting and Northing - implicitly known that the spatial reference system is New Zealand Map Grid. Third column is the height value and the further columns represent some additional attribute data. Based on the resolution, the surfaces from the roundabout 20 km  by 30 km range from 50KB (500m), 1MB (100m) to 20MB (20m) per layer (5 layers altogether).
X3D provides two easy (point set based) possibilities to show surfaces (right now the geological layers are represented as surfaces, they are not described as full bodies).

• ElevationGrid
• IndexedFaceSet

Furthermore there are the NURBS and extrusion implementations, which describes surfaces through splines. But that's rather complicated for the first shot :-) ElevationGrid requires an evenly spaced grid of height values, whereas IndexedFaceSet  notes all point coordinates and then defines coordinate indexes to define a mesh of single surfaces (similar to TINs, but not necessarily triangles).
I decided for the ElevationGrid. X3D has a geospatial extension (X3D Earth), which can geographically reference and place 3D objects in a defined spatial reference system. I didn't try this feature yet. And apparently it does not make sense to load 100MB for a 3D model into the browser. Therefore the 500m grid has been used here. The following example outlines a rather simple definition of such an elevation grid in X3D:

<shape> 

    <elevationgrid colorpervertex="false" creaseangle="3.14" def="Greywacke_top_500" 
        normalPerVertx="true" colorPerVertex='false' xDimension='37'
        zDimension='44' xSpacing='500' zSpacing='500' creaseAngle='3.14' solid='false'
        height='
150 150 150 ...
           '>
    </elevationgrid> 
    <appearance>
        <material ambientintensity="0.1" diffusecolor="red" id="Greywacke" 
            shininess="0.2" specularcolor="lightred" transparency="0.0">
        </material> 
    </appearance>
<shape>

To prepare that grid, you need to take care of some things:

• you need to know the extent and resolution of the dataset, from that you calculate and define the x- and zSpacing (how many values will be filled, because you only need the height values)
• the coordinate system orientation of the X3D 3-dimensional space is probably from the 2/2,5 coordinate system from the source dataset
• the source datasets only contained points with actual values, to fill the ElevationGrid properly, NODATA values need to added

Finally I got my data sorted on built a neat first little demo :-) There might happen some improvement, as we are intending to visualise wells, bores and other hydro(geo)logical data in such a scene.

Fig. 1: Preliminary (X)3D  model with five layers and a (not aligned) image as an underlayer

Exchangeable Encodings Getting in Shape

The time is flying by and soon we reach midway of the Google Summer of Code (GSoC) with 52°North. It is the typical time in between – I already managed to meet the first milestones, but there is no proper product yet. Catching up with the changes from the SOS main development branch is a constant challenge, but the infrastructural changes within the “Exchangeable Encodings for SOS” project are slowly but continuously leading towards a robust and standardized, yet limited, encoding plugin API (application programming interface).

The main use case is the request for observations (GetObservation request) that could be delivered in CSV (comma separated values) format for legacy applications, WaterML2.0, an upcoming OGC (Open Geospatial Consortium)
data transfer standard for the hydrological domain, possibly netCDF (Network Common Data Form), also an OGC standard for meteorological applications, and in O&M (Observations & Measurements) for the generic use within sensor networks and spatial data infrastructures.

Link to the article on the 52°North blog