3D Flood Plain Models

WPF 3D Flood simulations:
http://www.web-demographics.com/FloodPlain/FloodPlain.xbap

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

Comments are closed.