Sunday, 31 March 2013

Announcing: MapGuide Open Source 2.5 RC2

I was wrong.

I thought we would only need one RC before pumping out the final release, but the amount of fixes, polish and shine that's been done to Fusion since RC1 is such that a second RC is warranted.

The changes from RC1 are mostly Fusion-centric, and it's a big list.


We've fixed up some annoyances that are present in the 5 templates that come with MapGuide

Toolbar text on the TurquoiseYellow is much more legible. Black text on a black gradient toolbar did not scream readability

The templates also had various behavioural fixes to improve the user experience:
  • The sidebar of the LimeGold template could not be expanded once it was collapsed
  • For templates with collapsible sidebars, they will re-expand the sidebar if the user invokes any of the (Show Legend/Overview/TaskPane/SelectionPanel) menu items, or a widget has loaded content into the Task Pane.
Greater Widget Autonomy

Some widgets were treated as mutually exclusive widgets. That meant, if you invoke this widget, it became the active widget. These widgets had no business hijacking the active widget state and brought unnecessary confusion to the user experience. The widgets in question are:
  • Redline
  • Buffer
  • Feature Information
  • Measure
  • Query
  • Theme
These widgets all load their UIs into either the Task Pane or a popup window. As long as you can see their UIs, they should be considered active. These widgets are pretty much like Invoke URL widgets anyway: Self-managed and independent of the active widget state. 

Having their UIs open should not interfere with panning/zooming/selecting/etc. The above widgets have been modified to no longer take over or care about active state. In addition certain widgets on that list have been modified to be more self-contained, which are detailed below.


The Redline widget hasn't changed much since the last time I wrote about it. However, we did discover afterwards that SHP-based import/export was broken on Linux due to missing ZipArchive support in its bundled PHP. That has been fixed.


This widget was a prime offender in bad user interactions, the offence being leaving dangling digitizers behind. You could be panning or zooming, and it would still be measuring because the digitizers weren't deactivated and/or properly cleaned up. Other widgets on that list above shared some of the same problems with this widget, but the Measure widget was the worst of them all.

We've changed this widget in the following ways to ensure such a thing doesn't happen again.

The widget still auto-initiates measurement, but we've added manual controls to the UI to stop/start this process.

In addition, we've added an abort link to the information bar in case the Measure UI is easily hidden or obscured (eg. In the Aqua template)

Feature Information

The layers dropdown now has a refresh link, so you don't have to re-invoke the widget to refresh this list.


To be consistent with every other widget that uses a digitizer, the digitizing actions in this widget now use the Information Bar to provide digitization prompts.

The widget also cleans up any active digitizers when unloaded. Part of the greater widget autonomy and self-management that I mentioned above.


The legend widget now properly displays layer nodes above the group nodes at any level in the tree, thus syncing up with the AJAX viewer and presenting the exact visual representation of your layer/group structure as shown in Maestro's Map Definition editor


We have a scalebar widget? Yes we did, it just didn't work until now. What you saw here is the functional scalebar widget.


We have this widget too? Yes we did. This is basically a wrapper around the OpenLayers.Control.ScaleLine control. You couldn't access and include this widget with your Flexible Layouts because it didn't have a widgetinfo XML file.


This widget doesn't actually exist (hasn't for a long time), but its widgetinfo XML file was still there, thus having Maestro give you the false impression that this widget actually exists and can be added to your Flexible Layouts. Well this is definitely not the case, and the widgetinfo XML file has been removed meaning Maestro will no longer show this widget.

Center Selection

Here's another broken widget that's been fixed for this release.

Selection Panel

Did you know this widget is actually configurable with extension properties? Yeah, we didn't document them in the widgetinfo XML, that's why Maestro shows nothing for this widget. That's fixed now.

Did you also know this widget has a horizontal representation as well? Yeah, that was broken too, but fixed for this release as well.

Non-Fusion Miscellany

For this release, we've also officially deprecated Mapping Service APIs related to eMap DWF functionality. The front-end DWF map viewer was deprecated a long time ago, but nothing was official in terms of API documentation about the Web APIs that supported this viewer. Thanks to our SWIG enhancement work, you'll get nice C#/Java compiler warnings when using these APIs. 

We're doing this because eMap functionality support has been long since removed from the DWF Toolkit and MapGuide is still currently hamstrung on a super-ancient version of the DWF Toolkit due to the need to support eMap, which could also present interoperability problems with newer versions of AutoCAD and its verticals (that would be using newer versions of the DWF Toolkit). I've seen several DWF files plotted from MapGuide crash recent versions of Autodesk Design Review probably due to this reason.

Being stuck on an old DWF Toolkit was also one of the roadblocks in my failed 64-bit Linux experiment. And you know why MapGuide still doesn't support DWFX files? Same reason.

Not saying that this is what we're definitely going to be doing with a new DWF Toolkit, but it clearly shows what's stopping us from doing so (eMap support). So if we ever do upgrade our DWF Toolkit, we should at least give a one release-cycle warning. If you happen to still be using the DWF-based map viewer and/or the supporting Web APIs, this is your final boarding call to either migrate or seek alternative solutions.

I'm pencilling in a final release of 2.5 one week from now. What you see in this release will be pretty much be what's in the final release. Any issues filed against this release will be shelved to 2.5.1 or 2.6 unless those issues are of the really show-stopping nature.



javaknight said...

Hello Map Guy(de),

I have a questions concerning DWF. I would like to create maps that are really just floor plans using DWF inside of the either drawing or connected dwf datasource for MGOS. Does your dissertation against using DWF as a viewer affect the use of DWF as a datasource? I am not even sure if MGOS is capable of using DWF as a datasource, I have a client that is still using MG 6.5 with a dwf datasource though and I am thinking of the implications of migrating them. There are thousands of dwfs created on the fly in their 6.5 solution.

Thanks and all the best,


Jackie Ng said...

DWF as a data source (Drawing Sources) and the ability to plot the current view of the map (ePlots) are *not* going away.

It is the means of viewing your maps through the DWF Viewer ActiveX plugin (eMap) and its supporting APIs that we've deprecated for 2.5 that we are saying you should look elsewhere. The viewer part has long been deprecated (since MGOS 2.1/MGE 2010), but the supporting APIs were not. They are both deprecated for 2.5.