Like the ODBC provider, the OGR provider is a quick and easy way to tap into the vast array of data formats out there which do not have a dedicated FDO provider (most notably, MapInfo). However the OGR provider itself could do with some improvements to better support the FDO-isms like:

FDO Join support. The OGR SQL dialect supports JOIN statements as well (only LEFT JOIN, but still a FDO supported join type)

3. FDO Join support for other FDO RDBMS providers

For the best Feature Join performance scenarios, all RDBMS-based providers should support this new API. Given the SQL Server provider (which supports FDO joins) is derived from a common base that all other FDO RDBMS providers come from, I'd gather that adding support for would be a case of flipping a few bits here and there.

MapGuide

1. Improve MapGuide's standing as a geospatial services platform

Or to put it in one word: Interoperability. Currently, MapGuide has excellent data interoperability (due to FDO) but has weak service interoperability. It only does WFS/WMS and not much else. Talking to a MapGuide Server and tapping into the services available still requires specialized and dedicated client code or software and not something that can work via one or more OGC standards.

OGC standards is the glue by which geospatial software and services (Closed or Open Source) can talk to each other. So we should support as many of them as we can! Here's a few worth supporting:

Let's face it, nobody really plots to DWF. Everybody wants PDF, and it's easier to tell users to download/install a 5MB PDF reader application instead of Autodesk Design Review. The current solutions that are out there only embed an rendered map image to the PDF instead of rendering directly to the PDF. The easiest way to implement such support would be to implement a new MapGuide renderer with a Cairo backend. The upside of using Cairo is that it supports SVG output as well, so we can support an additional output format for free!

So there you have it, a much shorter list this time round because from an internal perspective, MapGuide has reached a point where it is a solid web mapping platform on most fronts. However if you take an outsider's perspective, there's still room for improvement.

A whole load of bugfixes and minor enhancements since Maestro 3.5 (all of which you can find in changelog.txt in your Maestro installation)

The Maestro API has also undergone some major changes, bringing back some of the niceties that have been missing since Maestro 2.1. A special thanks goes out to the following people who've helped make the Maestro API into a more developer-friendly experience:

Hans Milling

Gunter Becker

Crispin Hoult

The job's not finished on this front. There is still many things that can be done to improve the Maestro API developer experience even further. We'll leave that for next year :-)

Thursday, 15 December 2011

How did we achieve such godly performance numbers from a provider (SDF) that cannot take advantage of the recently implemented Feature Join optimization shortcut yet produces numbers just a tad higher than the new shortcut?

The answer: The existing Feature Join engine can actually perform well, it just picked the absolutely wrong join algorithm to do the join!

As explained previously, the GWS Query Engine "joins" two input feature readers (from both sides of the join) and returns a merged feature reader. Depending on the capabilities of both sides of the join, the following join algorithms are employed:

Sort-Merge is the best algorithm of the lot here because it does not need to re-iterate any side of the join to process all the results. The new performance numbers in the second screenshot is due to the use of the Sort-Merge algorithm.

The reason we got such terrible numbers in the first screenshot is because Nested Loops was the algorithm chosen by the GWS Query Engine. It chose this algorithm because it determined that the SDF provider could not support ordered results.

This is actually incorrect because both SDF and SHP can actually produce sorted results, but can only sort on a single property (which I would wager is the standard Feature Join use case. Joining on multiple properties would be quite uncommon). It turns out that the GWS Query Engine fails to notice this when selecting the join algorithm to use.

So after tweaking the sortability check in the GWS Query Engine, the existing Feature Join performs slightly slower than the optimization shortcut, which brings up another interesting point: Aside from some obscure providers (OGR, WFS), nearly all the vector FDO providers support ordering, meaning now there is a very high chance that the feature joins you set up will have both sides as sortable, and thus the most optimal join algorithm (Sort-Merge) will almost always be used.

So with Sort-Merge being the most likely algorithm being used with this new modification, performance then boils down to how fast we can read the rows of data and in this arena, SQLite is the king. Another reason why SQLite should be the default format of choice for your spatial data.

So in summary: For best feature join performance, use SQLite or data formats that can be sorted by MapGuide (which will be nearly everything with this patch)

Wednesday, 14 December 2011

Around this same time last year, I made a wishlist for MapGuide and FDO. As this year has passed along, that wishlist somehow slowly transformed into my personal to-do list :P So how did things turn out 365 days later?

MapGuide

1. A desktop-based variant of the Geospatial Platform API

Yep, and mg-desktop is it's name. Last year, I had a faint idea of how this would flesh out. Now it's fully realized.

2. A HTML5/Flash/Silverlight vector viewer with offline support

My desire for this type of viewer at the time was predicated on the lack of a viewer like in MapGuide 6.5 that can operate with limited to no MapGuide Server connectivity. mg-desktop has solved this particular need for me, so my desire for such a viewer is no longer there.

Still if we want to have a HTML5 viewer, this may be a good starting point. The examples work on local SHP files (Sheboygan Parcels actually renders quite snappy), but this can probably be extended to a common feature model (allowing support for other spatial data formats) and then start trickling in support for MapGuide's rendering/stylization rules.

As for Flash or Sliverlight, I'm not even gonna go there. HTML5 is capable enough IMO. A plugin-free world is a beautiful one.

Still not there, but anyone affected by this problem knows about it and has probably come to accept it as a minor inconvenience.

5. Feature Write capabilities for the mapagent

GeoREST is still the way to go here. Given this is part of AIMS 2012 as a technology preview, perhaps this will be integrated into MapGuide proper in the future?

6. A DWG FDO Provider

Still nothing here sadly.

FDO

1. A way to use the FDO API in languages other than C++/.net in a multi-platform manner

In my current line of thinking, mg-desktop is the way to go. It already uses/wraps FDO and is already developed in a way that facilitates easy generation of SWIG bindings. I just have to overcome my fear of gcc and automake and their cryptic error messages :P

This leaky abstraction is a small annoyance for anyone who wants to write provider independent code. If you have to write provider-specific code paths (FDO Toolbox had to employ quite a few), it just highlights some of the failings of FDO as an abstraction layer for spatial data access. Sadly, nothing's changed here.

5. Parametric Capabilities

Still nothing's changed here. Of course if ODBC and OGR don't expose capabilities of their own that are translatable to FDO's capabilities, then this leaky abstraction is one we'll just have to live with.

6. Android/iPhone support

Given Autodesk's recent focus on having mobileversionsofeverythingknownto man, this may look like a possibility. But you know Autodesk, I'm just staring at an opaque crystal ball here :-)

Tuesday, 6 December 2011

Is this be the end of FDO Toolbox as I proclaimed some time ago? Probably.

I'll still probably put out occasional releases to coincide with newer versions of FDO but other than that, FDO Toolbox has fulfilled all my needs (and I'm sure many of your needs as well). So I'll guess it's time to put this project into semi-retirement.

I am going to call it right now. If you've been holding back from moving to Fusion due to the assortment of bugs and performance problems, then the version of Fusion that will appear in the next version of MapGuide Open Source and Autodesk Infrastructure Map Server will be the one which will finally sway you across.

Thanks to work undertaken on behalf of Hume City Council, we have finally tackled most of the deal-breaking issues which have made Fusion unsuitable for production use for many years ... Until now.

What issues in particular? Read on below.

Legend Performance

This is the number one showstopper to wider adoption. The root problem with the legend widget performance is that each icon in the legend requires an individual http GETLEGENDIMAGE icon request to the mapagent. Now suppose you have a layer with a 900-rule theme, attempting to preview this layer will grind your browser and the MapGuide Server to 100% CPU usage, because it will fire off 900 individual icon requests (yes you heard that right!). And that's just for one single user!

We solved this problem through a multi-pronged approach:

1. To speed up the server-side initialization, we use the new GetResourceContents API introduced in MapGuide Open Source 2.2 to fetch all our required layer definitions in a single batch. Performance gains will be readily apparent for really chunky Map Definitions with lots (in the 100s) of layers

2. We exploit the data URI feature that supported by most modern browsers. We pre-cache icons by generating the legend icons server-side and embedding them as base64 encoded data URIs as part of the json content that is returned to the legend widget for initialization. Each legend icon represented as a data URI will eliminate a mapagent icon request that would have to be executed. We use a metric of pre-caching 25 layer icons per scale range. For an average Map Definition (like the Sheboygan sample data set) no icon requests are ever made through this optimization. Now for those primitive browsers from Redmond that don't support data URIs, have no fear. Because there is also the next optimization.

3. The theme compression logic that is used by the AJAX viewer now also exists in Fusion. We use that same number (25) to determine the number of style rules that must be exceeded for a theme to be compressed. Compressed themes in Fusion look like so:

And like the AJAX viewer, you have the option of expanding compressed themes. To avoid unnecessarily expanding say: a 900-rule themed layer, we prompt for confirmation. So the choice to flood a mapguide server with icon requests will be yours and yours alone to make ;-). Even if your browser doesn't support data URIs (It means you are using IE6/7. Don't deny it!), the theme compression means that icon requests will be capped at a certain level by default, just like the AJAX viewer.

So with these changes, our map with the 900-rule themed layer now loads just slightly slower than the AJAX viewer, which is a major improvment from never.

Support for Map Definitions with Tiled and Dynamic Layers

This one wasn't our doing, but Autodesk themselves have finally addressed the other long-standing complaint of not being able to view a map that contains a combination of tiled and dynamic layers.

And as an added bonus, if you are using commerical underlays your tiles can also line up with the Google/Bing/Yahoo/OSM tiles if your Map Definition uses a Google-compatible finite scale list (and is using the WGS84.PseudoMercator coordinate system of course). In anticipation of supporting this new feature, I've added support for generating this Google-compatible scale list in the final release of MapGuide Maestro 4.0 which will be coming out soon.

Redlining

Ever used the Fusion redline widget? Me neither.
So what do you do with the downloaded redline GML file? Hell if I know!
What about if I want to plot the map with the redlines? Dream on. You can't do that!

When the redline widget was first introduced with the query and theme widgets, I was personally surpised that they didn't base the redline widget from the same sample the query and theme widgets were derived from: The Generic Tasks AJAX viewer sample.

So we've thrown out this useless widget and replaced it with one based from the Generic Tasks sample, giving us a redline widget that is much more powerful and useful:

If you've used the Generic Tasks markup sample, this redline widget functions almost the same. For those unfamiliar with the Generic Tasks markup sample, here's what the new Redline widget can do:

Configure redline layers with support for labels using the same MapGuide stylization rules

Add, Create, Remove and Manage redline layers with respect to the current map

Draw geometries using the same digitizing tools provided by OpenLayers

Your redlines will be part of the whatever plotting or rendering operation you do on the current map.

Redline feature sources can be downloaded as SDF files, allowing for overlaying in AutoCAD Map3D and other Autodesk Geospatial products.

Quick Plot

The Quick Plot widget has improved reliability. This is due to the widget now using the actual MapGuide Rendering APIs to grab the initial un-rotated image and dumping that to a temp file, where the PHP gd library is then used to rotate the image and outputted back to the user. This approach is a more memory efficient use of the PHP gd library, and as a result should result in significantly less occurrences of this useless message:

ProTip: If you get this message, it's due to a failure of some sort in GeneratePicture.php. Inspecting the GeneratePicture.php request in Firebug should give you more information. As there was no mechanism in place to propagate back error messages, GeneratePicture.php fails silently at least from a user perspective. The QuickPlot changes improve memory efficiency and should result in signifcantly reduced (can we say no?) occurrences of this message.

The widget itself can now also have customizable paper and scale lists, which will require hacking the widget's extension XML element.

One small note: If you planning to wedge fusion trunk into an existing MGOS 2.2 installation, this widget will break because it uses APIs introduced in the next version of MGOS/AIMS. Other widgets should work just fine.

General Usability

Having tackled the major showstoppers, I became comfortable enough with the fusion framework to address a whole bunch of bugs and usability issues with other widgets. The Search, Measure and Query widgets have gotten a bunch of bugfixes.

Wrapping things up

All these changes have already landed in Fusion trunk (some have for quite some time now). Given this is usually branched off at some point, where it is then used by the Open and Commerical versions of MapGuide, you can expect these drastic Fusion improvements to a MapGuide release near you.

As a small aside. Many thanks to Hume City Council for providing the funding for us to implement these long overdue improvements. If you went to AU 2011, you may have seen some of our handiwork on display (including our Fusion work) in this presentation.

As a second small aside, if you have to use Internet Explorer, use Internet Explorer 9. Fusion absolutely FLIES in IE9 and even outperforms Firefox/Chrome in some cases! (yes, I am shocked)

Thursday, 1 December 2011

Not everyone speaks English, so neither should your MapGuide Applications.

Currently, the process of translating your MapGuide Application is to hunt down all the english strings in your Basic or Flexible Web Layout XML document and manually replace each string with your translations. This is a slow and painstaking process.

The final release of MapGuide Maestro 4.0 will include a new convenient command to assist with the translation of Basic and Flexible Web Layouts.

Clicking the Translate button will bring up a dialog containing all the localizable strings (Maestro searches for all known XML elements that can contain localizable text). From here, tick the strings that require translation and give your provided translation. I did a quick and dirty french translation via Google Translate for this example.

Once you have completed your translation, click Apply to apply these translations to the affected strings. The editor will reload itself with the translated strings. Previewing the layout will show your translated layout.

The final release of MapGuide Maestro 4.0 (which will include this feature) will be arriving shortly. Doing a lot of API cleanup and documentation.

Monday, 21 November 2011

Time for an explanation. This screenshot was the result of an experimental mg-desktop addition to make feature joins perform much faster (around 100 times faster as evidenced by the screenshot), by taking advantage of new FDO Join APIs that were recently introduced with the 3.6 release. Why does the FDO Join APIs perform so much faster? Time for a little backstory...

Why Feature Joins suck (performance wise)

Feature Joins are performed by the GWS Query Engine component of MapGuide. From a high-level overview, this component takes two input iterators (with interfaces similar to a FDO/MG Feature Reader), and depending on the capabilities of the left and right sides of the join a "merged" feature reader is returned that will loop the two iterators in the following fashion:

Now these join algorithms themselves are also sensitive to the data you're working with. For example, any sorted block algorithm is going to perform bad on datasets with high-spread of join key values (low-spread of join keys means lots of sorted duplicate joins values which can be skipped). Sort merge has issues regarding case-sensitivity of key values (though this may be a bug in the implementation). Nested Loops is obviously terrible if both sides are large (as is the case of a SDF to SDF join as per the above screenshot)

MapGuide in its current form is not aware of join factors which impact performance:

The size of both sides of the join (Nested loops is obviously bad, but the inability to determine size means this can't be avoided if this is the designated algorithm)

The spread of join key values (Sorted blocks work best on lookup-value type spreads not foreign-key type spreads)

It is all of the above factors which make having good performing feature joins a difficult proposition. ^

The FDO Join API (or: Let the data store figure it out)

So it's clear that MapGuide does a terrible and/or erratic job as a query optimizer, so assuming we want respectable performance of joined data, you would've probably avoided Feature Joins altogether and have the bits you want to join in question residing in the same centralised RDBMS, do the joins at the database level and wrap the result in a database view.

This approach is a good solution in terms of performance because figuring out the best way to join data is now a data store responsibility, and you can apply a whole assortment of indexes and other DBMS performance improvements that MapGuide is not aware of. From MapGuide's perspective all it sees is a table/view and it just queries that. But this approach presents its own problems:

The need for metadata hacks for views to be properly recognised as a feature class (eg. SDO_GEOM_METADATA in Oracle)

The type of view affecting selectability (eg. SQL Server, which requires schema overrides to work around)

With the introduction of FDO Join APIs, it allows us to do these type of joins in an ad-hoc fashion without needing to wrap our joined data into database views. Joining data with the FDO Join APIs is basically the equivalent of doing a SQL SELECT query with JOIN clauses. In other words, the FDO Join APIs lets you delegate join optimization to the data store and let it figure out the best performing way to do it.

So as already explained, work on bringing support for this into MapGuide started with mg-desktop. Being essentially a self-contained version of MapGuide meant that mg-desktop was a nice sandbox for playing and experimenting with new features. So once support was built into mg-desktop, bringing it over to MapGuide proper was quite an easy affair.

So how does mg-desktop and MapGuide take advantage of FDO Joins?

We use the existing Extended Feature Class mechanism to construct an equivalent FDO Join select query, applying the proper property/class aliasing to ensure that the reader that is returned presents the same property list as a default feature join query.

When querying an Extended Feature Class, MapGuide does several checks to see if the FDO Join optimization path can be taken. These checks include:

Does the underlying FDO provider for the Feature Source support FDO Joins? (obvious one!)

Does the primary and joined feature classes of this Extended Feature Class originate from the same feature source? (this is important, because FDO Joins work within the context of the same connection, thus the classes we are joining must come from the same source)

A whole bunch of other minor conditions which your Extended Feature Class will most likely satisfy (detailed in the RFC)

If the Extended Feature Class being queried passes the above checks, MapGuide takes the FDO Join path, which as seen from the screenshot above, can be up to 100 times faster than the regular Feature Join approach.

Additionally, Extended Feature Classes also double up as the metadata. You don't need to do SDO_GEOM_METADATA hacks or FDO Schema Overrides for these classes to be recognised. Because MapGuide already understands these elements out of the box!

Also, in case you're wondering, the performance numbers in MapGuide are even better than mg-desktop (up to 1s faster than the numbers in the above screenshot) due to connection pooling and object caching mechanisms present in the MapGuide Server code.

Conditions Apply

Now as you can see, only certain Extended Feature Classes can take advantage of this optimization. The other limitation is FDO provider support. As of writing this post, the following providers implement the FDO Join APIs:

SQL Server

SQLite

Given the high usage of these providers (you are using SQLite for all your spatial data aren't you?), there is a good chance of this optimization path being used.

The beauty of FDO is that as soon as an FDO provider implements the FDO Join APIs (like King.Oracle wink, wink, nudge, nudge), such configured Extended Feature Classes in MapGuide can automatically take advantage of this optimization path.

So there you have it. 100x faster feature joins if your data ticks all the boxes.

^ There is a 5th type of join algorithm that is (suprisingly) not implemented by the GWS Query Engine: Hash Joins. Though probably the most memory intensive join algorithm (due to needing to store one side of the join in a hash-table), this should always perform better than the default nested loops. Anyway, it's 2011. Memory is cheap! Having this join type implemented should improve the Feature Join user story even further. Guess that's another item on the TODO list.

Friday, 11 November 2011

It turns out that as far back as the first beta release of Maestro 3.0, that the window installers I've been making did not include the XML schema files required for validating XML content.

So I've posted an updated 4.0 RC1 installer with the missing XML schema files. Note that this is only applicable if you've been downloading the windows installer package. If you have been using the zip packages, the XML schema files have always been in there, so everything's ok on that front.

To make sure that the XML schema files are properly set up, go to Tools - Options and check that the XML schema path is configured to point to the Schemas directory under your MapGuide Maestro installation directory

Or, you can click Reset and Maestro will reset all preferences to default values and auto-discover all the required paths.

Update: OSGeo is back in order. So the fixed 4.0 RC1 installer is available for download from here

Wednesday, 21 September 2011

The major new feature of this release is non-transactional package loading, which greatly improves the reliability of loading very large package files, at the small cost of losing the repository ACID-ity of the official approach. Should you encounter any failed operations during the package loading, Maestro will give you the ability to retry these failed operations until all failed operations are accounted for, or you choose to abort yourself.

Once again, this beta is available in the fat NSIS installer or the lean zip package (which excludes local connection mode). Users of non-windows operating systems will have to download the zip package.

Friday, 16 September 2011

The next beta of MapGuide Maestro 4.0 will feature a new way of loading packages which I call "non-transactional" package loading.

Normally the package loading process in Maestro is as follows.

Select the package file

Maestro invokes APPLYRESOURCEPACKAGE on the MapGuide Server and uploads the package file

Twiddle your thumbs, because there is no way to know how long this operation will take

The operation being transactional means that the operation will wholly suceeed or wholly fail.

Loading a package several hundred MBs in size only to be told that the entire operation failed at the end is needless to say, a very frustrating experience.

Non-transactional package takes a different approach. It eschews using the APPLYRESOURCEPACKAGE API (the cause of the thumb twiddling and waiting because there is no way to track progress) for an approach that allows progress to be measured. At the heart of a MapGuide Package is the resource package manifest, which is simply a list of resource service operations to execute on the MapGuide Server, which are generally a mixture of:

SETRESOURCE

SETRESOURCEDATA

DELETERESOURCE

The existing approach executes all these operations on the server-side under one big transaction, the new approach executes all these operations one at a time from the client side and because we know how many operations need to be executed, we can measure the entire progress of the package loading operation.

Now when you load a package, you will be asked to choose the method of uploading:

Choosing the Transactional method will load the package in the existing fashion. Choosing the other option will use the non-transactional method and because this approach is measurable, we get a nice meaningful progress dialog to relay the upload progress.

So in what cases would you use non-transactional package loading over the default transactional one? Here's a few I've thought of:

The package file is several hundred MBs in size

The package file contains hundreds of resources to be loaded

The package file is not loadable via the transactional method, which is generally the result of any of the above items.

Finally, because it's non-transactional if one operation fails it will keep continuing with the upload of the others, failed operations are logged. As a result, the upload can partially succeed and fail. Should the operation partially fail, it is planned to re-use the list of failed operations to allow you to re-run the package upload, but to skip all the successful operations, thus turning a partially failed upload to a fully successful one.

I've received some test packages which completely failed to load under the official package loading methods. These packages loaded without issues in the non-transactional mode. So no matter low large or small your data packages are, Maestro can upload it for you. One way or another.

The multi-site feature majorly affects most workflows in Maestro and as a result of the yet-to-be-stabilized nature of this new feature, I will only recommend you download this release for testing and feedback purposes only

You may also notice a significant increase in the windows installer size (84MB). This is due to the inclusion of the full set of CS-Map coordinate system dictionary files that is required by the new local connection mode feature. I wish CS-Map stored its thousands of coordinate systems in a more space-efficient manner! Anyway, I am pondering whether to offer the new local connection feature as a separate download or keep it bundled it with the NSIS installer as I have done for this beta release. Let me know what you think.

This beta can reside side-by-side with older versions. The new local connection mode also shouldn't conflict or clash with any existing MapGuide Open Source or AIMS installations

Now truth be told. I was not a major fan of Autodesk MapGuide 6.5. I guess that could be attributed to the following:

I was just getting started not only with Autodesk products and technologies, but also on the basic concepts, practices and workflows of GIS systems. So for all intents and purposes, I was a total noob at the time.

Windows only. Ewwwwww!

The viewer is an ActiveX control that can only be embedded in Internet Explorer. Ewwwwwww!

Now the first time I got acquainted with MapGuide was in 2005 with the 6.5 version. It was also the time at my first ADN event when I heard about Autodesk's next version of MapGuide. Seeing the demos of this next version in action was quite a mind-blowing experience, given my not-so-positive experience with MapGuide 6.x.

The AJAX-based viewer, multi-platform support, purty looking maps, flexible data access through this mysterious (at the time, to me) FDO technology and the list goes on. It just ticked all the boxes of what a modern, open-ended web mapping system should be. But then came the biggest bomb-shell of them all: It will all be open source!* So then several months later, the very first version of MapGuide Open Source was released and the rest (as they say) was history.^

Now despite my less-than-flattering opinion about MapGuide 6.x. It did have some very unique qualities to it that has yet to be replicated in MGOS/AIMS. Its map viewer, due to being based on ActiveX meant it could be embedded into .net applications. The second quality was that MWF files can contain static layers. This combination meant that it was possible to build mobile anddisconnected MapGuide applications in .net or any other windows technology that supports COM (Component Object Model)

And it is in this respect that MGOS/AIMS has nothing comparable in its technological offerings.

Disconnected? Not a chance! Client applications must be connected at all times. No server connectivity = no maps for you! Even the latest mobile extension for AIMS still requires constant connectivity.

Mobility? You could have a full blown MGOS/AIMS installation on localhost, which your windows application can communicate via an embedded Internet Explorer. A functional, but very inelegant configuration. Nothing approaches the simplicity of a windows application + static MWF + 3mb ActiveX control configuration that was possible with MapGuide 6.x

So while MGOS/AIMS does most things leaps and bounds better than MapGuide 6.x, there are some other things where it pales in comparison.

Enter the MapGuide Desktop API (hereby known as mg-desktop for the rest of this post). mg-desktop is a desktop implementation of the MapGuide Platform API allowing for the same feature data access, map rendering/stylization functionality as the MapGuide Server, but without needing a MapGuide Server installed on your machine!

Genesis

The seeds of the MapGuide Desktop API were planted with this groundbreaking AU 2009 presentation. This presentation, for those unable to access that link showed how MapGuide Open Source actually has lots of shared components that can actually be re-used outside of the MapGuide Server and Web tiers.

The main example from that presentation was a simple snapshot application that can produce a rendered map image or DWF file from a list of named Layer Definition documents without ever needing to contact a MapGuide Server ever! The first thought I had after seeing that presentation, was simply: Can't we just use a Map Definition to drive all this?

The second thought was, that AutoCAD Map already proved that the MapGuide API can be taken in a different direction, away from the MapGuide Server/Web Tier to become a API inside AutoCAD Map

So couldn't we have another implementation that makes it a fully self-contained framework that is usable by any desktop application, taking the concepts proven feasible by that AU presentation to its logical conclusion? mg-desktop is my answer to that question.

mg-desktop is a desktop implementation of the Geospatial Platform API, with its own implementation of the core platform classes, as shown below:

Where the MapGuide API operates in the context of the MapGuide Server/Web Tier and the AutoCAD Map Platform API operates in the context of inside AutoCAD Map, mg-desktop operates in a standalone context, with no dependencies on any particular application. It provides a suitable foundation for creating your own desktop-based MapGuide application.

In addition to implementing the core classes and services of the Geospatial Platform API, it also includes some of the additional service APIs provided by the MapGuide API, such as:

MgRenderingService

MgDrawingService

MgTileService

mg-desktop also supports loading of MapGuide Packages (*.mgp). So you can transfer data and resources from a MapGuide Server to an mg-desktop installation.

Key Differences from the MapGuide API

Because mg-desktop is a desktop implementation of the Geospatial Platform API, some concepts which were applicable in MapGuide and/or AutoCAD Map no longer apply in mg-desktop:

There is no session expiry :D Session resources still exist as a way to have temporary resources

There is no resource security model

On the same subject, there is no authentication required for access to services.

There is no need to open/save runtime map state. Everything operates off of the current state of the runtime map in memory.

The mg-desktop implementation of MgResourceService wraps a pre-defined directory on the file system. Folders and resources in the mg-desktop repository conceptually map to files and folders in the file system.

The mg-desktop implementation of MgFeatureService is a thin wrapper around FDO. Each service API maps to a corresponding FDO command. All FDO types that would be returned are wrapped up and/or converted to their corresponding Mg* counterparts.

Aside from these differences, it's the same MapGuide API that you've come to know all along.

Unique APIs

mg-desktop not only just implements the abstract classes in the Geospatial Platform API, but extends them with our own additional APIs to correct my perceived shortcomings of the current MapGuide APIs. Here's an overview of the unique APIs of mg-desktop.

MgdFeatureService

MgdFeatureService is the desktop implementation of MgFeatureService and includes the following extra methods:

RegisterProvider - Registers a new FDO provider into the provider registry by its library path

UnregisterProvider - Removes a registered FDO provider from the provider registry by its provider name

InsertFeatures - Allows for individual insertion of features into a feature class, instead of having to use the monolithic UpdateFeatures

DeleteFeatures - Allows for individual deletion of features in a feature class, instead of having to use the monolithic UpdateFeatures

UpdateFeatures - Although it unfortunately shares the same name as the monolithic method it's trying to replace, this allows for individual updates of features in a feature class.

SelectFeaturesExtended - Almost identical to SelectFeatures, except this returns a scrollable feature reader that behaves similarly to the FDO scrollable feature reader

MgdLayer

MgdLayer is the desktop implementation of MgLayerBase which adds extra convenience methods, allowing you to operate on the layer itself instead of needing to obtain an MgFeatureService reference and the layer's feature source id and class name:

BeginTransaction - Convenience form of MgFeatureService.BeginTransaction

SelectFeaturesExtended - Convenience form of MgdFeatureService.SelectFeaturesExtended

InsertFeatures - Convenience form of MgdFeatureService.InsertFeatures

DeleteFeatures - Convenience form of MgdFeatureService.DeleteFeatures

UpdateFeatures - Convenience form of MgdFeatureService.UpdateFeatures

The Map Viewer Component

So having a reusable library to build your own geospatial applications is good and all, but is there something out-of-the-box like a map viewer that we can embed in a .net application? The answer is an emphatic yes. mg-desktop includes an embeddable map viewer component!

This is not some trick of embedding a web browser to use the AJAX viewer to talk to a local or remote MapGuide Server, this is all native .net WinForms controls and using the same self-contained MapGuide rendering and stylization services provided by the mg-desktop library and it does pretty much everything you can do in the AJAX/Fusion viewer.

What about more complex stuff like digitizing and redlining? No problem. It can do that too!

And all of this is functionality is contained in one single sub-100kb dll! (OSGeo.MapGuide.Viewer.dll). The next release of Maestro will be using this viewer component for previewing Feature Sources, Layer Defintions, Watermarks and Map Definitions in the new Local Connection mode

In Closing...

I have submitted a pending RFC to have this included in the official MapGuide source tree, which would greatly improve integration, code re-use and ability to receive fixes and enhancements to upstream components.

The source and binaries# for the mg-desktop library (and map viewer) are available from the Google Code project home page. Note that FDO that is included with the binaries is a partial distribution (because I lack the ability to build certain FDO providers). You will need a Mercurial client to checkout the source code.

If you want to build the source, you will need to do a full svn checkout of MapGuide Open Source and FDO trunk. Then you will need to build FDO and the MapGuide Oem components first before you can finally build mg-desktop. The hg clone needs to reside in a Desktop subdirectory under MgDev in your MapGuide svn working copy. There is currently no 64-bit or Linux targets yet, so feel free to submit any patches.

* Let's give credit where it's due here. mg-desktop, Maestro and FDO Toolbox would not exist if it weren't for Autodesk open sourcing the MapGuide product and FDO technology. Similarly, my knowledge of MapGuide and FDO wouldn't have reached encyclopedic levels that they are today if these technologies were not open sourced.

^ As most of us found out, v1.0.0 of MapGuide Open Source turned out to be pretty rough round the edges and performance of Feature Joins (which 6.x handled brilliantly) was absolutely woeful and buggy, which sadly is still applicable to this very day. But this is a known problem with a known workaround, which is to have all the data in a centralised, spatially-enabled RDBMS, which you should be already doing in the first place.

# To reduce download size, mg-desktop contains a reduced distribution of CS-Map. If there are problems due to missing coordinate systems, download the country-specific grid files here and drop them into the Dictionaries directory.

With the Local Connection mode, you can completely author up a whole bunch of Maps completely disconnected from any MapGuide Server and when you're done, use the magic of packages to instantly load this onto a given MapGuide Server without having to leave the application at all!

Because the MapGuide API uses FDO, we have the (near) full capabilities of FDO available to us, allowing my grand vision of merging FDO Toolbox together with Maestro to finally become reality. Here's some ideas that are possible with Local Connection mode:

Bulk Copying of feature source data with support for re-projecting features provided by the MgCoordinateSystem API

On a similar theme: Creating optimized datasets from Feature Sources containing Feature Joins

Supporting the Convert to SDF and Generalize Data options of Load Procedures

Every other conceivable feature that currently exists in FDO Toolbox, but not in Maestro

Super blazing fast localized tile-generation^

Now sadly, this groundbreaking new feature has one small caveat just like FDO Toolbox. It will be windows-only :( Because even though the MapGuide Desktop API itself was written in the most portable fashion of C++, it is the glue libraries that allow a .net application like Maestro to interop with it that are not compatible with Mono in Linux/Mac. But hey, having one revolutionary new feature is just as good as two revolutionary new features is it not?

Stay tuned for a more in-depth overview of the Desktop implementation of the MapGuide API that powers this new feature.

^ This idea is predicated on the fact that the Desktop implementation of the Tile Service APIs is nearly identical to the MapGuide Server, thus it would be theoretically possible to generate the tile cache client-side and copy the tile cache directory over to its corresponding directory in the MapGuide Server installation.

Monday, 15 August 2011

I'm happy to announce the final release of MapGuide Maestro 3.5 and SDK

New Features from 3.5 beta 2:

Layer editor now supports multiple composite styles per scale range

New informative progress dialog for map definition extent calculation

New "Copy Resource IDs to clipboard" context menu command

New Symbol Definition Validation rules

Client-side support for transforming coordinates to WGS84.PseudoMercator. It should now be possible to change your Map Definition coordinate system to WGS84.PseudoMercator, and have the extents automatically transformed to match, and immediately usable in a Fusion Application Definition with a Google/Yahoo/Bing backdrop

New in the SDK is a new sample: StandaloneWebLayoutEditor. This sample illustrates how to use the Maestro.Editors library to re-use the Maestro resource editors from outside of MapGuide Maestro.

Friday, 5 August 2011

As explained previously, the Maestro API allows you to work with MapGuide resources in an object-oriented manner, completely avoiding the need to work with raw XML content (although the Maestro API provides such facilities should you require them)

What I didn't fully explain was how one actually can create retrieve and work with these objects. In the Maestro API, there are 3 ways to do this.

First way: Using the ObjectFactory class

The ObjectFactory class allows you to create resource objects from scratch. This method was available in the previous version of the Maestro API, but because you were working with generated classes, there was a very high chance of NullReferenceExceptions and DBXML errors being thrown at your face because you forgot to instantiate one or more of its many child properties.

The ObjectFactory class insulates these concerns away for you. Any resource you create via this approach satisfies the minimum content model requirements of its respective XML schema.

Here's an example of creating a feature source object to a SQL Server 2008 Express database from scratch

Here'a a useful tip to assist in reporting bugs and debugging in Maestro.

At the heart of Maestro is the editors to let you edit the various types of resources that can be stored in a MapGuide Server. Now these editors are fully functional for most general cases, but should some part of a resource editor not work as advertised, here's what you can do.

Use the Edit As Xml command to view the XML form of the resource you are editing.

This command is not only convenient in that it allows you to bypass the editor and work on the actual XML content, if you know what you're trying to edit, but it also shows the xml content of the edited resource in its current state.

The resource editors in Maestro do not operate on raw XML content, instead they operate on a deserialized in-memory object form of that content. It is here that certain properties and attributes may be set incorrectly or missed due to bugs in the editor.

By invoking that command, Maestro is instructing the in-memory resource object to serialize itself back into XML, thus allowing you to see for yourself whether edits you have made in the editor have actually been applied.

This command has been very useful for me personally when implementing new resource editors or enhancing existing ones because the XML you see is exactly what gets sent back to the MapGuide Server when you hit the Save button, thus it has proven invaluable for me in debugging editor functionality and XML content model errors.

Friday, 8 July 2011

This message and its exception type of System.NullReferenceException generally means that I (or a library I'm using) screwed up somewhere in the code.

However, just generally telling me this happened does not help me or you one iota because I require additional information:

A stack trace of this exception message (so I can trace down the offending location in the code)

The steps you took to produce this error (so I can construct the possible sequence of events and data that leads up to the offending location in the code)

The data you are working with (where applicable)

Without these pieces of information, it makes it very hard for me to fix the cause of such errors.

The error handling in Maestro 3.5 now uses a more flexible dialog to display such exception information. Exceptions are now displayed in a more flexible dialog.

The message and detail components can both be copy/pasted or you can save the entire error dump to a text file and upload that as part an attachment to your trac issue, allowing for better quality bug reports.

However, what I have just explained doesn't just cover Maestro or this specific error. This is good practice for reporting bugs and issues in any application you use. Bad bug reports will most likely stay ignored because there is not enough information to work on. Developers are not psychic people, we need as much information as possible!

Providing at least the information as I've pointed out is a good start for any bug report and ensures that the developer can provide a suitable fix or workaround for you particular issue.

Wednesday, 6 July 2011

The significant new features of this beta are some new resource editors for:

Simple and Compound Symbol Definitions

Watermark Definitions

These editors are really rough quality at the moment and I would like feedback on these editors to see how the usability can be improved. Especially the Symbol Definition stuff as that has existed in MapGuide since 2007, but until now has not had a specialized editor due to the complexity of the XML schema.

Sunday, 3 July 2011

Many thanks to Packt Publishing for provding me a review copy of this book allowing me to write this review.

Relevance/Shelf Life

The problem with some technological books is that the technology advances at such a rapid pace that is renders the book's content out of date or obsolete after several months.

Fortunately, this is not the case with this book because the current release OpenLayers is still 2.10 and the OpenLayers APIs have been relatively stable that the content in this book is relevant enough for future releases of OpenLayers to come. In short, don't let the version number in the book title fool you, the book does have lasting relevance should you decide to revisit the content in this book in the future.

Content

The problem with writing a beginner's guide is, what level of knowledge do you assume the reader to have (if any)? If we were to take the book title at face value, then it assumes the reader has:

At least heard of a thing called javascript

Has used a web browser other than Internet Explorer.

Fortunately the book's introductory chapter covers the fundamentals of JavaScript, and all other foundational web development concepts (AJAX, JSON, Object Oriented Programming, etc) that eases you into to meat of the book: using the OpenLayers library to make compelling web mapping applications.

It is my own personal opinion that if you are to teach a newbie about web application development, they have to know what Firebug is and how to use it to simplify and optimize their web development workflow. I have stated in the past that if it weren't for Firebug (Ok. Let's extrapolate: If it weren't for modern web browsers like Firefox and Chrome), I wouldn't be in the business of doing web development.

Fortunately the book devotes an entire chapter to the Firebug extension for Firefox, which I believe should be a mandatory chapter in any book that delves into Web application development. In this respect, this book passes my newbie web developer test with flying colors.

So then comes the meat of this book: Using the OpenLayers library itself. The content is structured in a logical fashion, starting with getting a basic map up and running and then spicing it up with many different types of layer objects that you can add to this map (a single chapter is devoted to detailing all the available layer types you can add to your map). The important concept of projections is also significantly covered.

Another important aspect of OpenLayers is using controls to improve presentation and to add interactivity to your maps, and this book throughly covers the different types of controls available and how to use CSS to customize the style and appearance of these controls.

One last important aspect of OpenLayers is Vector Layers and the book covers all the intricacies of creating, styling and presenting Vector layers. (A sample chapter from the book covers Vector Layers)

The Web 2.0 ecosystem is an open-ended one where many different libraries and web services can talk to each other. OpenLayers is no different and the book clearly demonstrates the "Open" part of OpenLayers by showcasing how to interface and interop with third party libraries and web services. The book covers creating mashups with Google, Microsoft and Yahoo mapping services, as well as consuming photos from Flickr.

This book lives up to the title. It is a comprehensive introduction to OpenLayers and web 2.0 application development. The chapter on Firebug alone is enough to guide new users to the proper path of web development, something I am thankful for, because I do get tired of giving the same "use firebug" response to mailing list questions over and over again!