Wednesday, 28 May 2014

Announcing: MapGuide Maestro 6.0 Alpha 2

Here's the 2nd alpha of Maestro 6.0. Here's what's new

Theming Improvements

You can now control the border color for basic point or polygon themes that are generated. You can either specify a static color or a dynamic darker/lighter variation of the generated theme color.

For stylization expression functions, we now provide specialized editors to easily build LOOKUP() and RANGE(), ARGB() and HTMLCOLOR() expression functions from the Tools menu in the Expression Editor.


MgCooker has undergone some major changes.

Firstly, the official method of tile generation is now the only supported method. This method requires a valid meters-per-unit value to ensure the correct number of tiles will be requested.

Secondly, the UI has been updated and superfluous options in the UI have been removed.

The native connection option has been replaced with a connection string interface which allows in theory for MgCooker's UI settings to apply to any connection provider that supports the required interfaces.

Advanced Stylization

We've improved the Layer Editor for scenarios involving Advanced Stylization (composite styles).

Instead of providing an option to add a new composite style, we now provide the option of adding a new composite style for the types you are going to be working with (point/line/area)

Each option will create a default monochromatic composite style for the given type. A much better default state to work from than a blank composite style that was created in previous versions.

The previously mega-verbose Composite Symbolization dialog is now less verbose.

The moment of clarity when dogfooding this feature was that generally speaking, you'll rarely care about editing the actual component Symbol Definitions because you'll be working more with the parameters exposed by the component Symbol Definitions. So the inline Symbol Definition editor is really a waste of screen space and has been removed from this dialog into its own dialog that is shown when you click Edit Symbol on a selected component Symbol Definition.

Also from that screenshot, you'll see other notable changes:

  • Component symbol definitions in the list now show the name of the symbol in addition to its type
  • The symbol properties grid now shows the data type of each symbol parameter so you know what to enter in for the value.
  • You can find more information about a symbol parameter by clicking the Property Info button on a selected parameter row.
  • The Edit Instance Properties button has been moved into the toolbar of the Symbolization Components list.
And like the parent layer editor, we provide several pre-canned symbolization components to easily create new composite symbolizations from scratch.

When editing symbol parameters, you can now edit via:
  • Directly editing the cell content
  • Via a specialized editor in the Edit Value dropdown
  • Via the Expression editor in the Edit Value dropdown

Currently we provide the following specialized editors based on the type of the selected symbol parameter

For boolean parameters or parameters that evaluate to true or false

For numerical parameters

For color-based parameters

For parameters that accept a fixed set of known values

For everything else, we fall back to the Expression Editor

Thursday, 22 May 2014

Solving the XYZ problem in MapGuide

I think I've finally cracked the XYZ problem in MapGuide.

The XYZ problem for those wondering, was how to consume tiled maps in MapGuide as XYZ layers (ala. Google Maps, OSM, etc). For the longest time, my line of thinking was that there must've been some kind of black magic mathematics involved that allowed us to translate X, Y and Z into Row, Column and ScaleIndex parameters that the MapGuide Tile APIs use.

Well unfortunately that went nowhere. The two tile schemes are not inherently translatable, so I went back to the drawing board. After reading this page about XYZ tiles for the umpteenth time the concept finally clicked.

  • Formulas exist to translate X, Y and Z to longitude and latitude
  • Translating X, Y, Z and (X+1), (Y+1), Z gives us two pairs of longitude/latitudes forming a bounding box for a given XYZ cell.
  • Given a bounding box, we now have the means to render whatever lies within that bounding box with the MapGuide API. If necessary, we can also transform this bounding box into map coordinate space using the MgCoordinateSystem APIs.
Now unfortunately, we cannot use the existing Tile APIs in MapGuide to render XYZ tiles because they only accept row, column and scaleindex and not a bounding box. In addition, parameters such as tile size and image formats are locked to whatever's globally defined in serverconfig.ini. So to produce XYZ tiles we use a different primitive for tile rendering: The RenderMap API. 

The RenderMap API can accept bounding boxes so the XYZ tile rendering process is simply:
  • Convert X, Y, Z to a lat/lon bounding box
  • If the map is not WGS84, transform this bounding box to the map's coordinate system
  • Invoke the RenderMap API with the computed bounds to render our 256x256 XYZ "tile"
To verify this process works, I cooked up an implementation in mapguide-rest and used this wonderful page on and the Sheboygan dataset as a frame of reference.

For our test, we made a tiled version of the Sheboygan Map using the web mercator (WGS84.PseudoMercator) coordinate system.

Our XYZ route in mapguide-rest is as follows:


So let's zoom in on the Sheboygan area in maptiler

Based on the above image, our tiles of interest (to verify if our XYZ tiles are correct) are:
  • X: 2099, Y: 2985, Z: 13 (Top Left)
  • X: 2100, Y: 2985, Z: 13 (Top Right)
  • X: 2099, Y: 2986, Z: 13 (Bottom Left)
  • X: 2100, Y: 2986, Z: 13 (Bottom Right)
Here's our top left tile in mapguide-rest

Here's the top right tile

Here's bottom left tile

And finally, the bottom right tile

If you cross reference these tiles against the above grid on maptiler, you'll find that the MapGuide-rendered XYZ tiles do indeed line up with the Google ones, which tells us that our XYZ tile rendering implementation is working. Yay!

So what does this mean now that we have the means to serve XYZ tiles? It means your maps can be consumed by a greater range of clients. 

Not just OpenLayers

But also Leaflet

And much more.

Do you know what else happens to use a XYZ tiling scheme? Vector Tiles!

How can we produce vector tiles? We simply take that same bounding box computed from our XYZ parameters and instead of rendering an image, we run a series of FDO queries with that bounding box and write out the appropriate GeoJSON for all features into a GeoJSON "tile" file and serve that file out. For optimal performance and size, we should actually be using TopoJSON, but:
  • This is a first cut implementation
  • If there was a PHP library that can write TopoJSON so I don't have to write one myself, that would be great!
So lo and behold, vector tiles served from mapguide-rest consumed by an OpenLayers 3 client viewer in their full monochromatic glory!

UPDATE: Or how about ... one in full color glory with the bells and whistles that ol3 provides?

So my line of thinking about the mythical HTML5 map viewer with client-side vector rendering is now simply: Let OpenLayers 3 solve that problem. Let's just focus on making MapGuide deliver the required data to ol3 in the desired format in the most efficient manner.

This is hopefully a small step in that direction.

Thursday, 8 May 2014

Announcing: MapGuide Open Source 2.6 Beta 1

I think it's a fact of life that C++ is not the most ideal programming language to rapidly iterate with. Why do you think this comic exists? Due to Linux and its associated build systems conspiring against me for the past several weeks, my original planned release dates for MapGuide Open Source 2.6 have been naturally pushed back as a result.

Anyways, the Linux roadblocks have been mostly cleared (with some compromises), so I can finally say that I am pleased to announce the availability of MapGuide Open Source 2.6 Beta 1.

Here's a major summary of what is new in MapGuide Open Source 2.6


MapGuide 2.6 adds the new CREATERUNTIMEMAP and DESCRIBERUNTIMEMAP operations to the mapagent to allow for creating new server-side MgMap instances without needing any .net, PHP or Java assistance.


MapGuide 2.6 includes an enhanced QUERYMAPFEATURES operation that allows client viewers to request selection query information that previously required several AJAX roundtrips to custom .net/PHP/Java code. Both AJAX and Fusion viewers have been updated to take advantage of this new operation.

New WebLayout

MapGuide 2.6 introduces a new schema revision for the WebLayout resource. This new version supports customization of common AJAX viewer features:
  • Selection Color
  • Image/Selection format
  • Point selection tolerance
  • JavaScript code to invoke on viewer startup
The current 6.0 alpha release of Maestro has specialized editor support for this new WebLayout.

New Code Samples

MapGuide 2.6 includes new code samples demonstrating MapGuide integration with OpenLayers.

New Stylization Expression Functions

MapGuide 2.6 includes new expression functions to support new stylization scenarios. I realised that I haven't covered this feature in my 2.6 showcase series of posts. So stay tuned if you want to know more about what's new here.

Updated Web Tier Components

MapGuide 2.6 includes updates for several key web tier components:
  • PHP has been updated to 5.5.11
  • Apache has been updated to 2.4.9
  • Tomcat has been updated to 7.0.42
If you have PHP-based MapGuide applications, you may want to review your code for any compatibility issues. Similarly, if you have custom Apache configurations, you may want to review those configurations for any changes to configuration syntax.

And in case you're wondering, the versions of FDO, PHP and Apache we're bundling are using versions of OpenSSL that are not affected by the heartbleed security vulnerability, so you can rest easy on that front.


In addition to what was covered here, Fusion includes the following changes
  • OpenLayers has been updated to the latest stable version (2.13.1)
  • The 5 templates now have more robust error handling
  • Fusion now includes source maps for fusionSF-compressed.js to support browser debugging

Windows XP and Server 2003 support has been dropped. Main reason is the move to Visual Studio 2012 as the default windows compiler, where compiled code will not run on XP or 2003 without re-targeting support. But the bigger reason is that XP is end of life and Server 2003 is approaching EOL soon. No real point trying to support an OS that is EOL or is approaching EOL with the developer resources we currently have.

The PostgreSQL FDO provider is now enabled by default as PHP includes the required dlls for this provider.

In addition, the mapagent test pages is now its own installer feature. You can turn this feature off to reduce the attack surface of a production MapGuide installation.

Finally, we've removed the SVN metadata feature that was introduced in MapGuide Open Source 2.4. It was just too much of a burden to support this particular feature and based on an informal poll, it seems nobody even uses this feature!


  • FDO is now 3.9
  • Improved performances and bug fixes for the King Oracle provider
  • New APIs in place to allow GML Features streamed as WFS features from MapGuide to be transformed to other coordinate systems


Nothing has changed here, we are still targeting Ubuntu 12.04 LTS and CentOS 6.x for our Linux builds of MapGuide, and 2.6 will still sadly only be 32-bit :-(

I really wanted to target the new Ubuntu 14.04 LTS release (that's what my past few weeks were spent on), but despite building without issues, it was woefully unstable and the time that would be spent trying to find out why is time that is better spent right now on getting 2.6 out the door.

So Ubuntu 14.04 support and the mythical 64-bit Linux build will be delayed once again to a future milestone.

Other Notable Changes

WFS GetFeature responses are now fully chunked and streamed straight from the server tier.

The Feature Source preview now leverage watermarks to inject additional useful debugging information

Selection transparency in the AJAX viewer is now respected

However, to maintain "compatibility" we retain the existing behaviour if the alpha component of the selection color is fully opaque (ie. FF) so an unmodified AJAX or Fusion viewer will have selections that look the same as before.

And of course, there are plenty of bug fixes since 2.5.


Wednesday, 7 May 2014

Announcing: FDO Toolbox 1.3

Here's the new yearly update of FDO Toolbox updated to use FDO 3.9 and fix a few defects in the bulk copy system.

The move to FDO 3.9 has changed the software requirements as well, you now need to have installed:

You can grab this release from GitHub