San Francisco Bathymetry model
Fig 1 – ENC over WPF XAML TIN model of San Francisco Bay
ENC is a data resource for coastal and waterways describing bathymetry and navigation features. It has a great deal of detail associated with icons and is generally available in the US as IHO S-57 ENC format. It is typically a 2D format with bathymetric contours. I decided to play a bit with displaying this type of data in a more 3D mode or at least 2.5D.
First I needed a terrain with some bathymetry. I looked up available esturine bathymetry from NOAA and decided on a subset of the San Fancisco Bay area around Golden Gate. The esturine bathymetry can be downloaded in 30m and 10m versions for this area. The USGS also has both 10m and 30m DEM data for the land area. To prevent size blowup I decided to stick with a 30m model.
The bathymetry covers only to high tide with land as NODATA_value -32767 filled. DEM 0.0 fills water and sea level. I needed to merge the two sets so I was forced to hack some code to get a complete land and undersea TIN. First I converted the same area subset from both sets to simpler ‘.grd’ sets. In Java it was easy to read in both grds in identical arrays. It was then a matter of replacing all of the bathymetry nodata fill values with the same index in the DEM data. If both arrays had an unknown fill I resorted to borrowing from a neighboring node to make a smooth terrain. The two sources have a different coastline with one using a 19 year tide average and the other average sea level. Once merged I then wrote out a MeshGeometry3D for use in my xbap model.
Once available as a MeshGeometry3D I could use some of my previous WPF XAML tools to pull up a terrain model with some crude manipulation capability and a selection of texture surfaces from the ever useful TerraServer, DRQ, DOQ, and Urban imagery.
Fig 2 – Bay WPF with Urban overlay and ENC depth contour and sea level raised 2 meter
I had at first thought it might be cool to link a sea level surface to a tide estimation SOAP service. I created a simple planar surface positioned over the terrain model at roughly sea level. By adding a blue partial opacity brush to this surface I could emulate a simple sea level and connect it to a slider. This is briefly interesting but as it turns out the 30m model is just too coarse for tidal variations at this spot in the world. The terrain may be more detailed at 10m and perhaps a future project will look at 10m data for a smaller area in a tidal basin for maximum effect.
However, it also occurred to me from work I had previously done with ENC SVG displays that this surface would be ideal for interfacing to the NOAA ENC WMS. Using the WPF DataProvider template approach I was able to load a tree hierarchy from a proxy call to the ENC GetCapabilities xml. The ENC WMS uses scalehints to weed out clutter at low resolution views. There are several hundred layers in the complete GetCapabilities but most are inappropriate at the scale of the model I had created.
It was necessary to work out the XPath filter for limiting my layers to scale hints in the zoom range of my model. Unfortunately the result is just a half dozen layers but this is just a demonstration of the technology so I left it at that. This tree menu provides layers which are then selected for overlay on the planar surface rather than the terrain surface. By using GetMap calls with transparency set true it is possible to stack individual ENC layers on the surface while still seeing a terrain surface such as DRG underneath. The mixing and matching of overlays is a powerful capability.
I attempted taking this one step further by modifing the items template of the tree menu to checkboxes. This would allow mixing multiple layers of ENC as desired by the user. Unfortunately, although I was able to create the checkbox template I was unable to work out the method for accessing the checkbox behind a check event. Until I can grab the checked object and read its name or tag I cannot load a layer from this type of tree. I will need to work this out at a later date.
The other limitation of this technology experiment is due to the model size. It will be necessary to make the model variable to make much use of this type of interface. In other words it will be necesssary to change to a higher resolution model as the user zooms in. Smaller areas of higher resolutiuon would then provide more and more ENC layers for overlay on the planar surface.
Fig 3 – Bay WPF DRG overlay and ENC sea area polygons
An alternative approach in this case is to leave the loaded model alone but manipulate just the planar surface. As the user zooms to smaller areas the sea level plane can be reduced to the current viewbox and the ENC image extracted for overlay would also be smaller in extents resulting in more available layers. Zooming back out would require a change in the other direction. Once I have some time I would like to attempt this type of approach to make the ENC interface more useful within a static terrain model.
The elephant in the room with this type of modeling is the sheer size of data required for adequate terrain/bathymetry. Even with high bandwidth the load time is not insignificant for reasonably sized models. In WPF terrain the client manipulation is not a problem using the local GPU but model cache and zoom filtering will be the challenge.
Coastal USA ENC: http://chartmaker.noaa.gov/staff/charts.htm
Interior waterways ENC: http://www.tec.army.mil/echarts/inlandnav/
IHO S-57 format: http://www.iho.shom.fr/iho.html
Esturine Bathymetry: http://estuarinebathymetry.noaa.gov/