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:


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

Comments are closed.