weogeo and web2.0

A recent article on All Points Blog pointed me to a new web2.0 GIS data/community site called weogeo, still in Beta. Apart from the “whimsical” web2.0 type name the site developers are trying to leverage newer web2.0 capabilities for a data resource community.

Fig.1 weogeo slider workflow interface

The long standing standard for data resources has been geocomm, with its large library of useful and free data downloads. Geocom was built probably a decade ago on a unix ftp type architecture. Over the years it has evolved into a full featured news, data, software community site by keeping focused on low cost immediate downloads with an ad revenue business model enhanced with some paid premiere services. It has been successful, but apart from the revenue model, definitely archaic in todays online world.

Curious about the potential, I decided to look at the beta weogeo in detail. I was especially attracted to its use of Amazons Web Services, AWS:

S3 Simple Storage Service
EC2 Elasctic Compute Cloud
SQS Simple Queue Service

Amazon’s Web Services are a new approach to commodity web services that provide services on a lower cost time rate. This approach is called utility computing because of its mapping to the utility industry pricing models. For example S3 services on Amazon infrastructure are available for the following:


$0.15 per GB-Month of storage used
Data Transfer
$0.10 per GB - all data transfer in
 $0.18 per GB - first 10 TB / month data transfer out
 $0.16 per GB - next 40 TB / month data transfer out
 $0.13 per GB - data transfer out / month over 50 TB
Data transfer "in" and "out" refers to transfer into and out of Amazon S3.
Data transferred between Amazon S3 and Amazon EC2 is free of charge
$0.01 per 1,000 PUT or LIST requests
$0.01 per 10,000 GET and all other requests

This can translate into a convenient offsite storage with costs linked to use.
For example a 250Gb data store would be charged a $25 upload transfer fee and thereafter a $37.50/month storage fee. Storage fees would slide up or down as the use varies so you never pay for more than needed at a specific time.

S3 is not especially novel, but EC2 is, moving from storage to virtual computing resources. Now a virtual computer is set up on an as needed basis and torn down when not needed. EC2 is competitively priced at 0.10 per instance hour. This is especially attractive to small businesses and startups in the online world whose computing resources may fluctuate wildly. Ramping up to a highest expected load can require costly investments in dedicated servers at a managed hosting firm with little flexibility. Amazons SQS is a similar pricing model for queued message services on demand.

Weogeo provides a data service built on top of EC2 and S3. Their goal is to attract numerous data producers/sellers to provide a community of data sources with a flexible pricing model sitting on top of Amazons web services.

The weogeo founders are coming from a large imagery background with years of experience in scientific hyperspectral imagery which produces very large images, in the 40Gb/image range. The distribution of large image files poses a serious strain on bandwidth, but also on backend cpu. This is especially true of an environment which hopes to provide flexible export formats and projections. Community sellers are encouraged to build a data resource which can then be provided to the community on a cost basis using Amazon S3 for storage and EC2 for cpu requirements.

To make this feasible the weogeo development team also came up with an EC2 specific management tool called weoceo, which automates the set up and tear down of virtual computers. For example a request for a large customized data set can trigger a dedicated server instance specifically for a single download and then remove the instance once completed. As a side benefit weoceo adds a service level guarantee by insuring that lost compute instances can be automatically replaced as an effective failover technique. This failover still requires minutes rather than seconds, but the trend to virtualization points to an eventual future with nearly instant failover instance creation.

This service model was evidently used internally by FERI for the large imagery downloads generated by research scientists and academic communities. The use of open source gdal on EC2 is an effective way to generalize this model and reduce delivery costs for large data resource objects. The developers at weogeo are also extending this distribution model for vector resources.

To try this out I created a few WPF terrain models over Rocky Mountain National Park for entry into the weogeo library. These are vector models which include the necessary model mesh as well as overlay image and a set of binding controls to manipulate camera view, elevation scale, scene rotation, and tilt. Admittedly there is a small audience for such data sources, but they do require a relatively significant file size for vector data, on the order of 20Mb per USGS quad or 4.5Mb compressed.

Fig 2 Fall River Pass quad WPF 3D terrain model

In addition to the actual resource I needed to create a jpg overview image with a jpeg world file and a description html page. Weogeo Beta is currently waiving setup costs on a trial basis.The setup is fairly straightforward and can be streamlined for large sets by also creating an xml configuration file for populating the weogeo catalog. Once entered, weogeo will list the resource in its catalog based on coverage. The seller is allowed considerable flexibility in description and pricing.

The user experience is quite beautiful. It appears to be a very nice Ruby Rails design and seems to fit well in the newer web2.0 world. Those familiar with iPhone slide interfaces will be up and running immediately. The rest of us can appreciate the interface beauty, but will need some amount of experimentation to get used to the workflow. Workflow proceeds in a set of slide views that query the catalog with a two stage map interface, then provide lists of available resources with clickable sort functions.

Fig.3 weogeo slider maps selection interface

Once a resource is selected the workflow slides to a thumbnail view with a brief description. Clickable access is provided to more detailed descriptions and a kml view of the thumbnail.The next step in the workflow is a customization slide. This is still only available for imagery but includes things like crop, export format selection, and projection, which are cost selections provided by weogeo rather than the seller. Finally an order slide collects payment details and an order is created.

Fig.4 weogeo slider customization interface

At this point the web2.0 model breaks down and weogeo resorts to old web architecture by sending an email link to the user. The url will either provide a temporary download access to an EC2 resource setup specifically for the data or direct the user to the sellers fulfillment service. In either case the immediate fulfillment expectation of web2.0 is not met. This is understandable for very large imagery object sizes but becomes a user drawback for typical vector data downloads.This is especially true of users familiar with OWS services that provide view and data simultaneously.

Since I believe the weogeo interface is effective (perhaps I’m a pushover for beauty), I decided to look deeper into the Amazon services on which it’s based. Especially interesting to a small business owner like myself, is the low cost flexibility of EC2. In order to use these services its necessary to first setup an account and receive access public/private keys for the security system. An X509Certificate is also setup which is used for SSH access to particular EC2 instances. Each instance provides a virtual 1.7Ghz x86 processor, 1.75GB of RAM, 160GB of local disk, and 250Mb/s of network bandwidth with some Linux variant OS.

Amazon provides both REST and SOAP interface models. REST appears the better choice for S3 since it’s easier to set up data streams for larger files, while SOAP is by default memory bound. Access libraries are provided for Java, Perl, PHP, C#, Python, and Ruby which seems to cover all the bases. I experimented with some of the sample Java code and was quickly up and running making simple REST requests for bucket creation, object uploading, deletion etc. It is, however, much easier to populate S3 space using the opensource library called JetS3t, which contains a tool called Cockpit.

EC2 requires access to S3 buckets. Amazon provides a few preconfigured Amazon Machine Image files, AMIs, but they are meant as starting places for building your own custom AMI. Once an AMI is built it is saved to an S3 account bucket where it is accessed when building EC2 instances. I experimented with building an AMI and managed to get a basic instance going, customized, and saved without too much trouble following the “getting started” instructions. I can get around a little in basic Linux, but setting up a useable AMI will require more than the afternoon I had allotted to the effort. I was able to use Putty from a windows system to access the AMI instance but I would want to use a VNC server and TightVNC client to get too much further. Not having a Remote Desktop is a hindrance for the command line impaired among us.

The main drawback of AWS especially EC2 ( in comments I noted), is the lack of a Service Level Agreement. EC2 which is still in Beta will not guarantee the longevity of an instance which can be mitigated somewhat by adding a management/monitor tool like weoceo. However the biggest issue I can see for a GIS platform is the problem of persistent DB storage. The DB is part of an instance which is fine until an instance disappears. In that case provision needs to be made for a new instance setup using an AMI, but also a data transaction log capable of preserving any transactions since the last AMI backup. This problem does not seem to be solved very elegantly yet, although some people seem to be working on it, ScaleDB

If weogeo extends very far into the vector world, persistent DB will be necessary. Vector GIS applications, unlike imagery, rest directly on the backing geospatial DB. However, the larger issue in my mind is the difference between vector data models and large imagery objects. Vector DB resources are much more amenable to OWS type interfaces with immediate access expectations. The email url delivery approach will only be a frustration to weogeo users familiar with OWS services and primed by VE and GE to get immediate results. Even web1.0 sites like geocomm provide immediate ftp download to their library data.

It remains to be seen if the weogeo service will be successful in a larger sense. In spite of its beautiful Ruby Rails interface, its community wicki and blog services, its seller incentives, and its scalable AWS foundation, it will have to attract a significant user community with free and immediately accessible data resources to make it as a viable business in a web2.0 world.


http://www.web-demographics.com/GMTI requires .NET 3.0 enabled IE browser.
Alternatively here is a video showing part of the time sequence simulation.

Fig 1 – Screenshot of 3D WPF browser interface to GMTI data stream

According to NATO documentation STANAG 4607/ AEDP-7, ” the GMTI standard defines the data content and format for the products of ground moving target indicator radar systems.” The GMTI format is a binary stream of packet segments containing information about mission, job, radar dwell, and targets. These packets contain a variety of geospatial data that can be used in a spatially oriented interface.

Over the past couple of weeks I have explored some options for utilizing this type of data in a web interface. I was provided with a set of simulation GMTI streams that model a UAV flight pattern and target aquisition in a demonstration area in northern Arizona.

My first task was to write a simple Java program to parse the sample binary streams and see what was available for use. The data is organized in packets and segments. The segments can be one of a variety of types, but the primary segments of interest were the Dwell Segment and Target Segments. Dwell segments contain information about the sensor platform including 3D georeferenced position and orientation. Target segments are referenced by a dwell segment to provide information about detected ground targets which includes ground position and possibly classification.

Since I was only interested in a subset of the entire GMTI specification I concentrated on fields of interest in developing a visual interface. The output of the resulting translator is selectable to xml, GeoRss, and sql.

Here is a sample of a few packets in the xml output:

  <time units="milliseconds">75099818</time>
  <z units="centimeters">106668</z>
  <PlatformHeading units="degree true N">334.1217041015625</PlatformHeading>
  <SensorHeading units="degree true N">0.0</SensorHeading>
  <SensorTrack units="degree true N">334.1217041015625</SensorTrack>
  <SensorSpeed unit="millimeters/second">180054</SensorSpeed>
  <SensorVerticalVelocity unit="decimeters/second">1</SensorVerticalVelocity>
  <DwellAreaRangeHalfExtent units="kilometers">11.0</DwellAreaRangeHalfExtent>
  <DwellAreaDwellAngleHalfExtent units="degrees">0.999755859375</DwellAreaDwellAngleHalfExtent>
  <DwellTime unit="milliseconds">75099818</DwellTime>
  <time units="milliseconds">75099978</time>
  <z units="centimeters">106668</z>
  <PlatformHeading units="degree true N">334.18212890625</PlatformHeading>
  <SensorHeading units="degree true N">0.0</SensorHeading>
  <SensorTrack units="degree true N">334.18212890625</SensorTrack>
  <SensorSpeed unit="millimeters/second">180054</SensorSpeed>
  <SensorVerticalVelocity unit="decimeters/second">1</SensorVerticalVelocity>
  <DwellAreaRangeHalfExtent units="kilometers">11.0</DwellAreaRangeHalfExtent>
  <DwellAreaDwellAngleHalfExtent units="degrees">1.0052490234375</DwellAreaDwellAngleHalfExtent>
  <DwellTime unit="milliseconds">75099978</DwellTime>
  <classification>No Information, Simulated Target</classification>

Listing 1 – example of GMTI translator output to XML

The available documentation is complete and includes all the specialized format specifications such as binary angle, signed binary decimal, etc. I had to dust off bitwise operations to get at some of the fields.

	public double B16(short d){
		int intnumber = (int)d;
		int maskint = 0xFF80;
		int number = (intnumber & maskint)>>7;
		int maskfrac = 0x003F;
		int fraction = intnumber & maskfrac;
		return  (double)number + (double)fraction/128.0;

Listing 2 – Example of some bit twiddling required for parsing the GMTI binary stream

Since I wanted to show the utility of a live stream I ended up translating the sample gmti into a sql load for PostGIS. The PostGIS gmti database was configured with just two tables a dwell table and a target table. Each record of these tables contained a time field from the gmti data stream which I could then use to simulate a time domain sequence in the interface.

Once the data was available as PostGIS with a time and geometry field, my first approach was to make the tables available as WMS layers using Geoserver. I could then use an existing SVG OWS interface to look at the data. The screen shot below shows TerraServer DOQ overlaid with a WMS dwell layer and a WFS target layer. The advantage of WFS is the ability to add some svg rollover intelligence to the vector points. WMS supplies raster which in an SVG sense is dumb, while WFS serves vector GML which can then be used to produce more intelligent event driven svg.

Fig 2 – SVG OWS interface showing GMTI target from Geoserver WFS over Terraserver DOQ

This approach is helpful and lets the browser make use of the variety of public WMS/WFS servers that are now available, however, now that WPF 3D is available the next step was obvious. I needed to make the GMTI data available in a 3D terrain interface.

I thought that an inverse of the flyover interface I had built recently for Pikes Peak viewing would be appropriate. In this approach a simple HUD could visually track aspects of the platform including air speed, pitch, roll, and heading. At the same time a smaller key map could be used to track the platform position while a full view terrain model shows the target locations as they are aquired. I could also use some camera controls for manipulating the camera look direction and zoom.

At one point I investigated making use of the dwell center points to see what tracking a camera.lookDirection to the vector from camera position to dwell center points would look like. Being a GMTI novice I did not realize how quickly dwells are moving, scanning the area of interest. The resulting interface was twitching the view inordinately and I switched to a smoother scene center look direction. Since I had worked out the Dwell center points already I decided to at least make use of them to show dwell centers as Xs in cyan on the terrain overlay.

Fig3 – WPF 3D interface showing GMTI target layer from Geoserver OWS on top of DOQ imagery from TerraServer draped over a DEM terrain from USGS

The WPF model followed a familiar pattern. I used USGS DEM for the ground terrain model. I first used gdal_translate to convert from ascii DEM to grd. I could then use a simple grd to WPF MeshGeometry3D translater which I had coded earlier to make the basic terrain model. Since the GMTI sensor platform circles quite a large area of ground terrain I made the simplification of limiting my terrain model to the target area.

The large area of the platform circle made a terrain model unnecessary for my keymap. Instead I used a rectangular planar surface draped with a DRG image from TerraServer. To this Model3D Group I added a simple spherical icon to represent the camera platform position:

                    <GeometryModel3D x:Name="cameraloc" Geometry="{StaticResource sphere}">
                        <DiffuseMaterial Brush="Red"/>
                          <ScaleTransform3D  ScaleX="0.02" ScaleY="0.02" ScaleZ="0.02"/>
                          <TranslateTransform3D x:Name="PlatformPosition" OffsetX="0" OffsetY="0" OffsetZ="0.0"/>

Listing 3 – the geometry model used to indicate platform location

Now that the basic interface was in place I built an Ajax timer which accessed the server for a new set of GMTI results on a 1000 ms interval. To keep the simulation from being too boring I boosted the serverside query to a 3000ms interval which in essence created a simulation at 3X reality. My server side query was coded as a Java servlet which illustrates an interesting aspect of web interfaces, multiple technology interoperability.

On the client side the timer is triggered from a start button. It then reads the servlet results using C# scripting.

            Uri uri = new Uri("http://hostserver/WPFgmti/servlet/GetGMTITracks?table=all&currtime=" + currentTime + "&interval=3&area=GMTI&bbox=-112.56774902343798,34.65681457431236,-111.256958007813,35.7221794119471");
            WebRequest request = WebRequest.Create(uri);
            HttpWebResponse response = (HttpWebResponse)request.GetResponse();
            StreamReader reader = new StreamReader(response.GetResponseStream());
            string responseFromServer = reader.ReadToEnd();
            if (responseFromServer.Length > 0)

          // use the resulting platform position to change the TranslateTransform3D of the camera location in keymap
          Point3D campt = new Point3D(Double.Parse(ll[0]), Double.Parse(ll[1]), Double.Parse(ll[3])/1000.0);
                            PlatformPosition.OffsetX = campt.X;
                            PlatformPosition.OffsetY = campt.Y;

Listing 4 – client side C# snippet for updating keymap camera positiony

The camera location is changed in keymap and its look direction is updated in the view frame. Now some method of showing targets and dwell centers needed to be worked out. One approach would be to use a 3D icon spherical or terahedron to represent a ground position on the terrain model. However, there are about 6000 target locations in the GMTI sample and rather than simply show icons moving from one location to the next I wanted to show their track history as well. In addition the targets were not discriminated in this GMTI stream so it would not be easy to distinguish among several moving targets. A better approach in this case is to take advantage of the DrawingBrush capability to create GeometryDrawing shapes on a terrian overlay brush.

                                <DrawingBrush Stretch="Uniform">
                                  <DrawingBrush.Drawing >
                                    <DrawingGroup x:Name="TargetGroup">
                                      <GeometryDrawing Brush="#000000FF">
                                          <RectangleGeometry Rect="-112.0820209 -35.31137528 0.332466 0.332466"/>

Listing 5 – using a DrawingBrush to modify the terrian overlay

As targets arrive from the server circles are added to the DrawingGroup:

                            GeometryDrawing gd = new GeometryDrawing();
                            gd.Brush = new SolidColorBrush(Colors.Red);
                            GeometryGroup gg = new GeometryGroup();
                            EllipseGeometry eg = new EllipseGeometry();
                            eg.RadiusX = 0.0005;
                            eg.RadiusY = 0.0005;
                            Point cp = new Point(Double.Parse(ll[0]), Double.Parse(ll[1]));
                            eg.Center = cp;
                            gd.Geometry = gg;


Listing 6 – C# code for creating a new ellipse and adding to the DrawingGroup

The Dwell center points are handled in a similar way, creating two LineGeometry objects for each center point and adding them to TargetGroup.

This completes a simple 3D WPF interface for tracking both the sensor platform dwell segments and the target segments of a gmti stream. The use of WPF 3D extends tracking interfaces in the z dimension and provides some additional visual analysis utility. This interface makes use of a static terrain model made possible by foreknowledge of the GMTI input. A useful extension of this interface would be generalizing terrain. I explored this a bit earlier when building terrain from JPL SRTM WMS resources for the NASA Neo interface. This resource provides world wide elevation data set exposed in a WMS, which can be used to create GeometryModel3D TINs, enhanced with additional overlays such as BMNG, any where in the world.

In a tracking scenario some moving platform is represented in a live stream of constantly changing positions. Since these positions are following a vector another general approach would be an Ajax WebRequest to a set of terrain patches, either static for performance or dynamic from JPL SRTM for small footprint. As a tracked position moves across the globe new patches of GeometryModel3D would be dynamically added to the forward edge, while old patches are removed from the trailing edge, reminiscent of the VE and GE map services. GeometryModel3D requirements are much more intense than image pyramids so performance could not match popular slippy map interfaces. However, real time tracking is generally not a high speed affair, at least for ground vehicles.

A variation on this Ajax theme would be a retinal model that adjusts GeometryModel3D patch resolutions depending on the zoom. For example a zoom to a focus could increase the resolution of the terrain model from 100m to 30m and then again to 10m. If the DEM is pre configured it would be fairly simple to create a pyramid stack of GeometryModel3D patches using perhaps 160m, 80m, 40m, 20m, 10m resolutions. Starting at the top of the pyramid in the interface would provide enough resolution for a wide area TIN. Zoom events could then trigger higher resolution Ajax calls to enhance detail at a focus. These kinds of approaches will need to be explored in a future project.

WPF 3D Resource

I’ve been following Eric Sink’s fascinating The Twelve Days of WPF 3D blog leading up to the important release of Charles Petzold’s new book due to be released tomorrow, July 25th. Eric was involved as a technical reviewer and had early access to its content.

3D is one of the most important distingishing characteristics of WPF XAML. 3D is new to the browser world, at least in a native browser form, and WPF 3D affords a rich set of capabilities that make possible 3D web applications. Eric’s blog provides a nice tutorial with helpful pointers on the use of 3D WPF. Without going into great detail it describes his insights from developing an application called “Sawdust”. The application itself is not online but the insights are applicable to online xbap as well as a standalone program.

Charles Petzold is a legend in the Windows programming world. He has produced a long line of reference books for those needing to program in WIndows and his latest is
3D Programming for Windows

Anyone developing 3D content for .NET 3.0 will need to study Charles Petzold’s new book as well as Chapter 12 of Nathan Adam’s book Windows Presentation Foundation Unleashed.

WPF Camera flight over Pikes Peak terrain model

In this experiment the WPF camera flight control is used in a terrain of the Pikes Peak Colorado area. This is similar to the previous Broadmoor Flyby but uses a larger terrain model. The YouTube video below is a screen recording using the iCord screen capture project from sourceforge.net. This screen capture was done from a low end tier0 XP PC, which would be a worst case system.

Fig 1 – Flying WPF Camera – Pikes Peak


The terrain model in this example is about 20Mb. The WPF GeometryModel3D TIN was constructed from USGS 30m DEM data. In this larger terrain the flight timer interval was set to 500ms. Z-fighting occurs again when using the camera gimbal control. However, in this model the camera can descend into the mountain without a rendering problem. This was not the case in the previous Broadmoor model. Feedback from several viewers confirms that this rendering breakup occurs on a variety of hardware configurations including a tier 3 Vista setup.

Flying the camera

In the past few experiments using WPF terrain meshes I’ve made use of scrollbar bindings to manipulate the scene. Although this is satisfactory for experimental proof of concept it remains an obstacle for flying through a 3D scene. This week I finally built a flying camera with instrument controls for throttle, banking, and tilting which lets me fly my camera around in the model and swivel its LookDirection with a gimbal tool.

Fig 1 – Terrain model with a camera flying control


There are at least three ways of manipulating a viewport in WPF/XAML:

      1) transform the scene itself

      2) move the camera position

¬†¬†¬†¬†¬†¬†3) finally change the camera’s look direction and zoom lens.

¬†¬†¬† Under the covers all these approaches would seem to be manipulating the scene viewport with the same set of matrix transforms. Curiously, however, there are differences. When either transforming the scene, or moving the camera position, the view tends to break up at close distances. This is apparently a form of z-fighting, where the rendering stack from front to back gets confused. However, when using the FieldOfView zoom lens the viewport can go right into the scene with no z-fighting. There may be some issue with Microsoft’s DirectX code used for WPF/XAML or it may be related to the specific graphics driver used on my system. Either way navigating a scene at close quarters is not always a smooth journey. I can only hope Microsoft will work this out for the next WPF/Xaml release.


Fig 2 – Terrain model with camera swiveled to show example of z-fighting

Conceptually, viewing the camera as mounted on a flying vehicle using a swivel gimbal seemed better than many scrollbar control bindings. In the flying camera model there are three parameters for the vehicle and three for the gimbal:

  • vehicle bank – left and right
  • vehicle tilt – up and down
  • vehicle throttle – up and down
  • gimbal swivel – left and right
  • gimbal swivel – forward and backward
  • camera zoom lens – near and far

In order to fit these six parameters into a simple interface I attempted to create a flight instrument icon. The target geometry on the right menu provides a simple 2D geometry for connecting parameters to x,y axis. While using the mouse left button inside the target icon, x and y values connect to vehicle bank and tilt. In addition, mousewheel events are used to set throttle for the moving vehicle. A simple horizon line gives the client feedback hints for the vehicle attitude with a position red dot to show current parameter location.

The right mouse button changes the gimbal swivel, left, right, forward, and back. The mousewheel is connected to the FieldOfView to simulate camera lens zoom. Feedback is simply a green dot indicating location in the target axis. Once the right mouse button is lifted the gimbal snaps back to straight down.

To help with orientation a key map is displayed in the lower right with a red ball to indicate the current vehicle position. If flying becomes tedious, this red ball can be dragged with a mouse left button to a new location where the camera view is updated.

This simple interface is used to continuously set the six parameters while a timer thread ticks at 500ms to update any changes to the scene view resulting from interface changes. The result is a simple flight interface with a bit of a jerky motion. Setting the tick of the timer to smaller intervals did not seem to smoooth the flight. Perhaps scene transforms are hardware constrained due to the weak tier0 GPU available in my development system. It would be interesting to see how a high performance GPU would deal with a 30ms timer interval.

The model in this case was created from USGS 10m DEM and the Broadmoor Hotel model is a translation from a Google .skp file. The small area was useful for frequent development cycles. In the future it will be helpful to modularize the flight instrument for backporting to other terrain models. Ultimately it would be interesting to work out a terrain stream connected to JPL STRM30 DEM servers and use this type of flight paradigm for navigating across the globe.

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
¬†¬†¬† not(starts-with(./Name,'3'))]“/>
¬†¬†¬†<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

Google skp files

I went to a little promotional seminar in Denver for Google Enterprise. The seminar was mostly marketing Power Points, but the coffee was good and the demonstration pods afterwards were interesting. I have not played much with Sketchup since it was first introduced. The demo overview got me interested again. Once I got back to the office I downloaded the most recent trial version for some experimenting. Sketchup is really an easy to learn tool, at least compared to AutoCAD. It would probably take a week or so to get very proficient but that is really a short time considering the hastle of entering 3D models.


Fig 1 – WPF XBAP version of a Broadmoor Sketchup Model


Sketchup is oriented to the Architectural community more than tools like Blender or MS Expression Blend which appeal more to graphics designers and animators.

Sketchup is Google’s tool for populating their globe data spaces with building models. It has many more uses than that, but I think they were hoping to get a community going to populate Google Earth with models. I notice Microsoft in usual form doesn’t attempt to develop a community but invests money to model whole cities en mass. Google’s recently announced licensing of auto modelling algorithms may help get their city models going faster. Darpa also seems interested in harnessing drive through point LIDAR for creating virtual cityscapes in a more or less automated fashion.

It is always interesting to see how GIS, CAD, and Facility Management tend to blur at the edges. These building and city models are at the crude edge of the technology curve. I predict it won’t be too long before we start seeing full models with interior spaces and walk through capability available on the web.

Sketchup has a generous set of import/export options. I was able to load a model of the Broadmoor Hotel here in Colorado Springs. I then exported to several of the different formats available, including Collada DAE, KMZ , and DXF. DXF is the most accessible and I quickly converted the model to a XAML version to see what could be done. DXF does not preserve the rich material textures and photo overlays in the Sketchup model so the result is rather drab by comparison. However, the fun is that it can be done at all. Once in XAML the usual WPF tools are available to do a bit of manipulation.

Collada DAE appears to be a richer xml based interchange format that includes references to all of the jpg photo and material overlays. The kmz format also identifies these jpg/png overlays but does not automatically export them for reference. Somehow a KMZ/KML to XAML translator has more appeal since it would be useful in other areas. However it would require getting hold of all the jpgs from a different export. I will need to look at the skp apis and see what they offer for helping with various exports.

The building model can be part of a WPF enhanced browser which makes it a part of the web instead of a parallel world like Google Earth or Sketchup. The Google Earth viewer is more focused and in a narrow way much richer, while WPF is a broader approach and gives more freedom to the developer. I have wondered what Google might come up with if they created their own browser. It could obviously include capabilities like Google Earth and Sketchup as well as the usual html/javascript. I’m sure it is something Google has thought about.

It was fun to see what can be done with these kinds of models and Google’s openness to innovation is refreshing. It reminds me of the earlier John Walker days of Autodesk. At that time Autodesk was very community friendly creating portals to their basic CAD functions through DXF, AutoLisp etc. I think it was 1988 when I made my first wire frame earth globe with AutoLisp functions using the old World Data Bank I vectors. A lot has changed in the intervening decades.

Some more XBAP

This week I experimented with a WMS interface using XAML. The idea was to see what could be done with NASA’s new NEO services. These are largely global environmental satellite imagery sets updated on a regular schedule, so there are things like global reflectance and sea temperatures etc. In addition NASA has a series of animations on their SVS Scientific Visualization site. All of these lend themselves to global coverage so I decided to use a globe interface rather than the more traditional 2D.


XAML lets the developer create 3D scenes so it is not difficult to create a tin model of a sphere. In this case I used some code to generate a sphere with 2162 triangles which provides a fairly smooth spherical surface. Directional lighting was added with a camera focused on the North American quadrant. Then a series of tools were added to create DiffuseMaterial overlays. The base overlays are fairly standard global images from JPL and NASA including the ubiquitous Blue Marble. These can be interchanged with a selection from a ListBox added to a ToolTray in the top DockPanel. In addition a ListBox of example overlays was added to verify the use of a local GeoServer WMS service. WMS is the easiest to incorporate as a simple linked ImageSource reference to an ImageBrush for the DiffuseMaterial overlays. These can be stacked nicely as long as a transparent png is returned from the selected WMS layer.

Fig 1 – WPF XBAP interface for NASA NEO WMS site

Leveraging WPF animation triggers lets the client add some spin to the globe, while a TrackballDecorator tag lets the user rotate the globe and scale using left and right mouse gestures. Binding allows a scrollbar to connect to scaling transforms. To add a little more movement a ComboBox filled with NASA SVS references lets the client view thumbnails and select mpegs for playing over the sphere’s material sets. This demonstrates some of the media flexibility in WPF. Since some of these mpgs are opaque I also set the opacity to .75 to allow the sublayers to partially show through.


Images are useful but there are a lot of vectors in the mapping world. As an experiment I also added a few DrawingBrush.Drawing elements as material overlays. A RectangleGeometry patch indicates my area of the globe. There may be a better approach but I used a 360×360 square and added the rectangle in its x,y coordinates which means the latitude had to be adjusted to the exaggerated north/south dimension with a 2x scalar. Some more experimentation with DrawingBrush Stretch might improve this bit of hack.


Using a VisualBrush let me add a Canvas and TextBlock label which is updated with the surface selection, making an earth conforming label. Finally a more complex compass figure was floated above the globe. This involved a simple rectangular surface with a set of DrawingGroup elements added for the compass segments. The complexity here is correctly setting the transforms to allow the compass to show but also let it scale and rotate with the globe.


The NEO WMS site has a wealth of services described in its GetCapabilities request: http://neowms.sci.gsfc.nasa.gov/wms/wms?version=1.1.1&service=WMS&request=GetCapabilities


This allowed me to experiment with a more complex binding to a TreeView element using an XmlDataProvider. This is a great tool that allows Xpath selections to be fed directly into TreeViewItems through a HierarchicalDataTemplate. I did not connect directly to NEO’s getCapability request since there is a problem with using an outside link to another site. The returned xml references an external DTD. This reference evidently triggers a security failure when the xml reader attempts to verify the dtd. As a shortcut I simply added a copy of the GetCapabilities XML with the offending dtd reference removed. This bit of cheating can be fixed but it would involve creating a server proxy servlet to read the GetCapabilities and remove the offending line before feeding it to the XmlDataProvider. The end result is a nice but static tree view selection list of the layers exposed by NEO’s WMS service.


VisualBrush could be used to add WFS GML or for that matter KML. This would involve adding a couple of servlets to translate GML and/or KML to VisualBrush GeometryDrawing elements that become another DiffuseMaterial overlay. I leave that to experimentation down the road.


I should also comment on the SpecularMaterial. This is added to give a bit more of a dimensional quality to the sphere. It adds a bit of specular reflectance which unfortunately is not especially smooth due to the coarse nature of the TIN model. I left it in as an interesting artifact and it doesn’t detract too much except for the darker overlays. It also requires a bit of manipulation on the overlays since it needs to be last in the list.


The coordinate mouseover required some digging. The 3D aspects of XAML are nice for modeling and viewing but the interactive capabilities are a bit restricted. I was able to use RayMeshGeometry3DHitTestResult to get the 3D point of the ray intersect of my globe. Adding a bit of code to transform the 3D point to Lat,Long gives the coordinate readout, but I have yet to actually get access to any of the Drawing elements at that intersection. In other words I didn’t find a way to query into the scene for a particular element at the ray intersection which would be very useful for external queries to the backing server.


The lat,long does give me a way to utilize a GetFeatureInfo query to WMS servers but I would have also liked to access drawing elements from WFS overlays directly in the client. A little more research may reveal a way to do this. I am aware that the 3DTool kit provides a way to fool the viewer by adding a transparent surface that tracks the 3D underneath. User interaction with the 3D scene is simulated by actual interaction with the 2D surface. I don’t quite see how this will work with a globe once it starts spinning.


Having lat,long coordinates did allow me to add one additional function. Using Ctrl+Mouse Left Click lets me capture a lat,long point and using NavigationService to activate a GetTerrain servlet. This servlet takes advantage of the JPL DEM WMS site. JPL has kindly added a WMS extension “styles=feet_short_int” to allow elevation pngs. The 16bit grayscale provides elevation values which the GetTerrain servlet uses to create a TIN model. Obviously these require a big chunk of memory so this approach probably doesn’t scale too well. The TIN model is streamed back to the client as a loose XAML 3D terrain model. Using a 1/3 degree patch results in about a 12Mb xaml. This is helped a bit with the Apache compression but is still a cumbersome download unless the client has a high bandwidth connection.


Since the source is global the GetTerrain used the best possible DEM which has global extent, the SRTM3. This provides 3arc global DEM coverage. I use the NASA BMNG as the surface overlay since it also has global coverage and a fair resolution. There is much better coverage in the USA with 30m DEM or 10m DEM and a number of possible overlays such as USGS DRG, USGS DOQ, and Hi Res Urban imagery. The public imagery services don’t come too close to the universal offerings of Google, Live Maps, or MapQuest but hopefully the government will keep adding additional resolution over time. I was tempted to sneak in a set of Google tiles as overlays but beyond the legal challenges the projection requirements require a bit of customization I didn’t care to reproduce.


The resulting Terrain WPF model is loose xaml. This means that it cannot take advantage of code behind C# and is somewhat restricted in its capabilities. Some bindings can be added for scaling and rotating but the TrackballDecorator, for example, requires C#. Unfortunately the C# code behind can only be created using a compiler to xbap. There doesn’t appear to be a dynamic way to serve xbap from a Tomcat server. It may be possible in some manner using an IIS server but that is beyond my expertise presently. Another possibility would be to dynamically create the necessary XAML with its C# code behind and then execute a command line build. This might work for small sites but building a new version with each change of selection on a real website would not scale at all. The revision increments could easily climb out of the possibly shortint space allotted to the Microsoft compiler. This seems to be a real restriction to WPF in the browser and will prohibit its adoption in many situations.


WPF/E uses JavaScript and could operate more like a rich browser client, however, at this time it is restricted to 2D elements. One possible work around is to utilize AJAX techniques to load loose xaml with an XML reader and create dynamic xaml inside the original download. This is a bit complex but was an approach often used in SVG. The code behind C# for the entire application is compiled and downloaded initially. Then as selections are made instead of doing the normal REST link to new content, content is requested from the server as xml and inserted into the existing DOM. I imagine this will be the solution of choice for any more complex xbap application.


This experiment turned out to be a fair exercise of WPF and shows the real utility of the WPF XAML approach. It is not too hard to imagine Google Earth like interfaces created using interoperable OGC sites and WPF browser solutions. This in fact would seem to be a more enterprise friendly approach to in house services than dependence on a Google or Microsoft branded mapping service.

Fig 2 – Night in the Rocky Mountains