ENC with <Checkbox> items

I was able to run down my problem with the Checkbox items in the ENC OWS example.

Fig 1 – ENC WMS over WPF XAML TIN model using Checkbox tree for WMS layers


I was using an XmlDataProvider to populate a TreeView
with a Hierarchical DataTemplate like this:

<TreeView Name=”ENCGetCapabilities”
   Width=”Auto” Height=”500″ BorderThickness=”0″
   SelectedValuePath=”{Binding XPath=Name}”
   Background=”{DynamicResource {x:Static SystemColors.ControlBrushKey}}”

   <Binding Source=”{StaticResource ENCWMS}”
   XPath=”Capability/Layer/Layer[(ScaleHint/@max = 0.0033645577994830035) and
    (ScaleHint/@min >= 0.0) and
    not(starts-with(./Name,'1')) and
    not(starts-with(./Name,'2')) and
   <HierarchicalDataTemplate DataType=”Layer” ItemsSource =”{Binding XPath=Layer}”>
    <CheckBox Checked=”CheckBoxChange” Unchecked=”CheckBoxChange” Margin=”2,2,2,2″    Tag=”{Binding XPath=Name}” Content=”{Binding XPath=Name}” FontSize=”9″>


This works very well providing the GetCapabilities layers in a tree of checkboxes. The problem
was when the Checked event fired, the CheckBoxChange callback was having trouble determining the layer.

   void CheckBoxChange(object sender, RoutedEventArgs args)


      CheckBox checkedBox = args.Source as CheckBox;

      string layer = checkedBox.Content.toString()

checkedBox.Content.toString() returned an object label instead of a string. I finally noticed that the object
returned was a System.Xml.XmlElement.
I was then able to cast checkedBox.Tag as an XmlElement and access its InnerText.

string layer = ((XmlElement)checkedBox.Tag).InnerText;

Now the layers from the ENC WMS service can be additive and overlay the base textures
from the toolbox selection list.

New approach to ENC views

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

NOAA ENC WMS: http://ocs-spatial.ncd.noaa.gov/wmsconnector/com.esri.wms.Esrimap/encdirect?Service=WMS&Version=1.1.1&Request=GetCapabilities

Esturine Bathymetry: http://estuarinebathymetry.noaa.gov/

USGS DEM: http://edc.usgs.gov/products/elevation/dem.html

3D Flood Plain Models

WPF 3D Flood simulations:

Fig 1 – Terrain with a planar sweep simulating water levels
After last week’s import of SketchUp building models into WPF xbap, I decided it was time to work with some of the higher resolution DEM data available from the USGS. The USGS has been upgrading a number of quads to 10m DEMs. These are scattered over the US and provide 9x number of points for building TIN models for select areas than the older 30m DEM. Much of the updating is in the western states which have a good deal of relief to model.

I downloaded the USGS 10m DEM for Colorado Springs, CO. The data consists of about 1.5 million points in a 10mx10m grid over the USGS 1:24000 quadrangle for Colorado Springs. The data I downloaded was in the SDTS format. I used a couple of existing tools to first convert the data to the older and more accessible USGS format ASCII DEM, sdts2dem.exe. The DEM format is setup in column dominant profiles but because the profiles are clipped to the geographic boundaries of the 1:24000 quadrangle the points are not in a symmetrical grid structure. Profiles on the east and west edges of the quadrangle will be only partial profiles which does complicate life when building a TIN.

Another tool takes these DEM profiles and converts them to simple x,y,z ascii, DEM2XYZN.EXE. From that point I was on my own. I had already created a small utility for converting JPL SRTM30 png files into TIN models. The JPL data is row dominant so it took just a little bit of editing to change to column dominant. The data I wanted was far from the quad edges so I could make the simplification of assuming a symmetric col x row matrix and calculate triangles from adjacent columns without accounting for the partial profiles at the edges.

I did not want to create an enormous Geometry for the model so I cut out the portion of interest surrounding the previous Broadmoor Hotel model. This 1.86km x 2.18km subset became a context terrain model for adding to the building model. Vertical relief for this smaller area ranged from 1844.6m to 2052.9m. The resulting TIN model was left in the UTM-13 metric coordinate projection.


Next I took the resulting TIN Geometry and added it to my project as a Page Resource MeshGeometry3D. I could then bind the mesh to a GeometryModel3D element called “surface” inside the Model3DGroup.Children used to hold the Broadmoor model. The Broadmoor model was previously translated from DXF which produced a WPF Geometry3D model normalized to 0,0,0. If I had written a KMZ translator I could have had the model in georeferenced coordinate Lat,Long which could then be transformed to a UTM projection, but the normalizing would still be required in WPF to make it visible inside the Canvas viewport. Since the surface TIN I am adding is in UTM I also had to add a Model3D.Transform, specific to the TIN Model3D, to scale and translate the surface under the building. The translation takes the UTM center point of the Broadmoor location in UTM and translates that center point to 0,0,0. In addition I noticed that AutoCAD models are in architectural inches rather than metric units. This made it necessary to add a uniform scale of 39.36999 inches per meter. The set of transform parameters was not easily obtained and did require some playing with the translation parameters to get a good fit. Fortunately I did have a DOQ and a DRG material surfaces that I could use to compare locations and make adjustment.

The result places the Broadmoor model in a terrain context with a 10m resolution. I kept the same set of scroll tools for rotation and scaling which I used to experiment with viewing my new model. I soon discovered that the rendering quickly broke down as the scaling moved in closer to the building. It appears that z-fighting is a problem with this model when inside the bounds of the terrain surface. I played with the camera near plane and far plane parameters but these did not seem to make any difference to the z-fighting breakup. I then assumed that it was best to leave the WPF to calculate its own near and far plane distances.

I also tried setting the camera Position and LookDirection to zoom the scene but again z-fighting occurred at positions close to the building. I finally did get a helpful clue with a post to the WPF forum. It was suggested I use the FieldOfView parameter to adjust the zoom value rather than scaling the entire scene. The only zoom method that seemed to ameliorate the z-fighting turned out to be the FieldOfView. This was unfortunate since ultimately I was hoping to develop some type of interface to fly the camera into and through the scene. Using camera parameters such as Position LookDirection, Rotate, and Tilt would let me fly the camera through the scene space while also adjusting its LookDirection with some type of trackball wrapped camera icon. I believe I can still do this but will need to substitute a combined FieldOfView variable and scene rotation for the position 3D location of the camera. For example I can rotate and tilt the camera as a substitute for the LookDirection vector while narrowing the FieldOfView and rotating the scene to simulate camera position changes. Although this works without the z-fighting affect I hope that future releases of WPF will do better with the z-fighting problem using actual camera position.

So now I have a Broadmoor Hotel building model placed on a USGS 10m Terrain with material selections of USGS DOQ or USGS DRG. At the cost of scroll bar proliferation, the added camera controls let the client move around and through the scene. This is clumsy but valuable for experimenting. The unfortunate workaround for z-fighting limits the usefulness of actually entering inside the model. Interior lighting and textures would help with orientation inside, however, the small relative scale of the interior along with the extremely narrow FieldOfView required to get to that zoom level, make minor adjustments have large results. I think this is nearly the definition of chaos and means it is easy to get lost inside. Moving from outside to inside may require two discontinuous models, with an abrupt model switch at the entrance. These are areas obviously well worked out in gaming tools but WPF is a simpler set of tools at this stage and I doubt that sophisticated 3D browser gaming will result from WPF 1.0.

Once I had this terrain to play with I decided to take it a step further. My first thought was to make a simple line of site mapping leveraging the “RayMeshGeometry3DHitResult” (a terrifyingly long name for a method) for a series of rays emanating from the viewer eye height. This would not provide a full view shed for the scene but might be useful for a simplified view analysis. However, I was distracted by another opportunity. In order to display the line of sight view map I needed to add a simple plane to the scene for overlaying my view calculations.

I discovered that adding a plane to the scene would let me play with a planar sweep and simulate a water level. Of course at 6000 feet above sea level this is not a dramatically realistic addition but it is fun. I simply added a geometry plane with a blue color and a fractional opacity. By binding yet another scrollbar to this plane’s associated TranslateTransform3D OffsetZ parameter I am able to raise and lower the water level as desired.


Fig 2 – Water rising at the Broadmoor

There are some scenarios where this might actually be useful. In the past I have translated ENC charts for use in a web application with SVG. ENC charts are detailed 2D charts of navigable water ways. NOAA and the Army Corps of Engineers have ENC chart data available for areas such as harbors and rivers, http://chartmaker.noaa.gov/MCD/enc/index.htm. I had previously used ENC charts for the Mississippi up to Baton Rouge and around Galveston harbor. These charts are highly symbolized in 2 dimensions. Transferring to 3D and using a water plane above a bathymetry/terrain model would add some realism. In addition it would be interesting to fly around a navigation chart scene and see the affect of tidal variation (connected to the server clock with a tide table http://tidesandcurrents.noaa.gov/) and ship draft on navigation in well known channels. Of course the standard FEMA flood plain models might also make interesting subjects for this type of planar sweep.

Fig 3 – SVG ENC chart for Mississippi channel near New Orleans

Fig 4 – Water rising at the Broadmoor view from above