Thursday 18 October 2012

We can do that with MapGuide too! (or: Turning features into 3d charts)

I haven't been in the Autodesk partner game for quite some time now, so my knowledge about their commercial products (besides AIMS) have atrophied somewhat over time. Nevertheless I do keep in touch with the Autodesk blogosphere, and one particular blog post today caught my attention.

The reason it caught my eye, is that it turns out we can do pretty much the same thing in MapGuide through the combination of Google Earth and MapGuide's KML support. For this to work, you will need the recently released 2.4 version of MapGuide Open Source, as that contains some important KML-related fixes. This post will use the Sheboygan dataset to demonstrate this.

Here's the Sheboygan Parcels layer in Maestro


Notice the KML Elevation button. It is disabled because the Layer Definition is based on an XML schema that pre-dates KML support. So to enable it, just upgrade the resource to the latest supported schema version. Clicking on the KML elevation button gives you this dialog


This dialog has 4 simple settings:

  • The Z offset: Defines the vertical offset distance
  • The Z extrusion: Defines the associated "height" of each feature
  • The Z offset type: Defines how to apply Z offset distance
  • The units: Defines what units to interpret the Z extrusion as
So for example, if we wanted to "chart" the land value of each parcel, we'd apply the settings like so:

1. Enable the elevation/extrusion settings
2. Click the [...] button beside the Z Extrustion to bring up the FDO expression editor
3. The Z extrusion can be any FDO expression that evaluates to a number, so we put in the land value (RLANDVC), but for practical display purposes inside Google Earth, we divide this value by 1000. Because if we used the default elevation units of "Meters", a million-dollar parcel of land will extrude into Low Earth Orbit :D


4. For Z offset type, we can leave this unchanged. You only want to use Absolute if you want the extrusion to be interpreted from sea-level. But since Sheboygan looks to be a pretty flat area, we'll leave it as RelativeToGround
5. Finally the units we'll keep as-is


The only other thing we'll change is the scale range back to the default of [0 to Infinity]. From my experience, Google Earth has a bit of trouble zooming to the region if the layer's constricted to a discrete scale range.

Also we'll change the layer's tooltip to also show the land value (RLANDVC). Notice the use of the refined concat expression eliminating the need to construct what I like to call "concat pyramids" in the past.



Layer Definition tooltips are transformed into popups when you select such features in Google Earth.

Once that's done save the layer definition and then house it within a Map Definition. We do this so that the Map Definition acts as a "funnel" into the WGS84 coordinate system (which features must be in for them to properly line up in Google Earth), any non-WGS84 layers we add will be automatically re-projected to WGS84 via MapGuide's powerful coordinate transformation facilities.

Once it's been housed within a Map Definition. We can invoke GetMapKml on the Map Definition through the mapagent to produce a KML document for that map. Opening the KML document in Google Earth and clicking the Parcels node, takes you to that familiar region


Which you'll notice is not as flat as the data you're used to seeing :) Because these parcels have now been extruded based on the FDO expression we've provided earlier (RLANDVC / 1000). Notice how dividing by 1000 has indeed capped the extrusion to a reasonable level for display purposes. 

And if we tilt the view a bit, we can get a better view of the land value.


And if we select the tallest feature there, we find out that Leon B is sitting on a gold mine and that in general, land owners under Voting District 4 are filthy rich :)


The popup content is the same content that would be in a MapGuide tooltip if we were looking at this data via the normal AJAX viewer.


One thing to keep in mind here is that the KML support in MapGuide is still somewhat basic. There isn't much ability to fine-grain control the KML content that gets generated by MapGuide. If you have such requirements, you are better off serving KML from the GeoREST extension for MapGuide instead.

Speaking of which, we could certainly do with a 2.4-compatible release of GeoREST

No comments: