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.

http://www.web-demographics.com/Broadmoor/Broadmoor.xbap

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.

http://www.web-demographics.com/Earth3D-Neo/Earth3D-Neo.xbap

  
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