Saturday 31 December 2011

My MapGuide/FDO wishlist for 2012

Might as well get this in before the last day of the year ticks over

Here's a list of what I'm hoping for MapGuide/FDO in 2012 (or is this my personal to-do list? :-)).

FDO


1. Raster support for the PostGIS provider


The best open source spatial extension just recently had support for raster imagery. Wouldn't it be nice, to have all your vector and raster data in one centralised database that is accessible via FDO?


2. A more FDO-capable OGR provider

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:

  • Supporting the ability to create data stores (ie. Mapping FdoICreateDataStore to OGR's CreateDataSource)
  • Ability to sort. The OGR SQL dialect supports ORDER BY clauses, so this should be possible. Sortability greatly improves Feature Join performance
  • 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:


2. Native support for PDF output


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.

Happy New Year everybody. Here's to a wonderful 2012!


New Year's Edit: Inflated the list slightly. 

Friday 23 December 2011

Announcing: MapGuide Maestro 4.0 Final + SDK

I'm pleased to announce the availability of MapGuide Maestro 4.0 and SDK, just in time for Christmas!

Here's a rundown of the major changes since Maestro 3.5

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

Improving the Feature Join Experience (or: Sort all the things!)

Remember this screenshot?


Here's the current numbers as of right now


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

My 2010 MapGuide/FDO Wishlist: Revisited

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.


3. A scalable Fusion Legend widget


Yep, Fusion no longer sucks


4. A way to preserve tile sets


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


2. Champion SQLite as the goto flat-file format for FDO


An emphatic yes on this one. The SQLite FDO provider is getting all the new FDO goodies nowadays. It was the first provider to get the new FDO Join APIs, thus allowing the Feature Join optimization shortcut to become possible.


3. A FDO provider for MapGuide


Nothing's changed here.


4. Consistent Schema Naming Conventions


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 mobile versions of everything known to 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

FDO Toolbox 1.0 (yes that's right!)

3 years and 1251 revisions in the making. The 1.0 final version of FDO Toolbox is finally here.

This release includes some small bugfixes from 1.0 RC1

Download

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.

Fusion is actually usable now

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

轻松翻译使用 MapGuide Maestro *

* I trust Google Translate translated the above blog title correctly :D

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

Improving the Feature Join experience

So what was this screenshot all about?


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.

Taking advantage of FDO Joins in MapGuide (with RFC123)

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

Announcing: A fixed installer for MapGuide Maestro 4.0 RC1

Oops!

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 9 November 2011

Announcing: MapGuide Maestro 4.0 RC1

Here's another RC coming your way.

This release re-introduces the Package Editor feature, which has been missing since Maestro 2.1 and includes a big bucket of fixes and small improvements since beta 2.

One particular improvement which I'm proud of finally implementing can be summarised with this screenshot:



Yep, I finally figured out how do do it!

Download (back at OSGeo)

Wednesday 26 October 2011

Announcing: FDO Toolbox 1.0 RC1

About time I started to get this thing to the 1.0 final release.

New Features
  • Now using FDO 3.6.0 final release.
  • Data Preview now supports the new FDO Join APIs
  • You can now dump the contents of a Feature Class in the Object Explorer to SDF/SQLite via the context menu.
Also included is plenty of bug fixes and small improvments

Come and get it

Report Issues/Enhancements

Friday 21 October 2011

A screenshot to tide you over



Stay tuned for more information :)

Wednesday 21 September 2011

Announcing: MapGuide Maestro 4.0 beta 2

I am happy to announce the 2nd beta of MapGuide Maestro 4.0

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.

Also included in this release is:
  • Fixes for defects brought on by the new multi-site support
  • Editor support for FDO expressions in color editor properties
  • Updated to the latest mg-desktop binaries for Local Connection mode
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.

Download (temporarily hosted on the mg-desktop site)

Friday 16 September 2011

Introducing non-transactional package loading

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.
  1. Select the package file
  2. Maestro invokes APPLYRESOURCEPACKAGE on the MapGuide Server and uploads the package file
  3. Twiddle your thumbs, because there is no way to know how long this operation will take
  4. 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.

Thursday 8 September 2011

Announcing: MapGuide Maestro 4.0 beta 1

I'm happy to announce the first beta release of MapGuide Maestro 4.0

This first beta contains 2 new groundbreaking features, which have already been covered previously:
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

Download

Monday 5 September 2011

Taking MapGuide beyond the Server and Web right into your desktop




Previously, I briefly mentioned how the new Local Connection mode in the next release of Maestro was backed by a new desktop implementation of the MapGuide API. This (lengthy) post covers this

Preface

Let's start with a little personal backstory of mine.

Remember this software?

The MapGuide ActiveX viewer (source: Directions Magazine)

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 and disconnected 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.




Thursday 25 August 2011

Something (even more) revolutionary this way comes

When I announced that Maestro 4.0 would give you the revolutionary ability to connect to multiple sites at the same time, there was actually a reason for that. Because also coming in Maestro 4.0 is an entirely new way of managing and authoring your MapGuide resources.

Introducing the Local Connection Mode



When you click Connect Locally, you still have to supply a configuration file as you would a TCP/IP connection, exception this file will be provided by the Maestro installation.



And it functions and operates like any other connection



But here's the main difference. Unlike the TCP/IP connection, which is just a wrapper around the official MapGuide API, and thus requires a connection to the MapGuide Server and a cumbersome assembly signing process to properly set up, the Local Connection does not require any MapGuide Server at all!

This is because the Local Connection wraps our very own implementation of the MapGuide API, which runs entirely on the desktop allowing for fully client-side spatial data access and map rendering/stylization.

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

  • Fully client-side previewing of Maps, Layers and Feature Sources with the exact rendering/stylization engine

  • 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.

Tuesday 16 August 2011

Something revolutionary this way comes

Each release of Maestro until now has brought with it a series of enhancements that are mostly incremental and evolutionary in nature that improves your MapGuide authoring productivity.

Coming to the next release of Maestro (4.0) is a new feature which I can safely say will be nothing but revolutionary



That's right! Maestro 4.0 will let you connect to and work with multiple sites at the same time! Can you imagine the possibilities?

Monday 15 August 2011

Announcing: MapGuide Maestro 3.5 final + SDK

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.

Download
Download SDK

Saturday 6 August 2011

Announcing: MapGuide Maestro 3.5 beta 2

I'm happy to announce the second beta release of MapGuide Maestro 3.5

One of the interesting new features is in-place upgrading of resources to the latest schema version. You know that pale yellow bar at the top with that upgrade button that's always disabled?



It's now enabled, and when you click it it will upgrade the edited resource to the latest schema version supported by the MapGuide Server you're connected to.



Once upgraded, the editor refreshes itself and the new editor features for that schema version become activated.


This is supported for all resource editors. Currently the conversion is one-way (always to the latest schema version. I may look at converting to a specific version in a future release.

Other new features and changes include

  • Enhanced Autodesk Infrastructure Map Server 2012 support

  • Previewing is now enabled for Watermark Definitions

  • Map Definition support for re-ordering layer groups

  • Layer Definition editor now supports inline symbol definitions for composite symbolization

  • A whole bunch of assorted productivity improvements (too many to detail, but you'll recognise it when you see it)

  • The usual assortment of bugfixes


This is the last beta release before the final 3.5 release

Download

Friday 5 August 2011

Maestro API: 3 ways to create and work with resources

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

IFeatureSource fs = (IFeatureSource)ObjectFactory.CreateFeatureSource(conn, "OSGeo.SQLServerSpatial");
fs.SetConnectionProperty("Service", "(local)\\SQLEXPRESS");
fs.SetConnectionProperty("DataStore", "MyDatabase");
fs.SetConnectionProperty("Username", "mapguide");
fs.SetConnectionProperty("Password", "maestro");

where conn is an instance of the IServerConnection interface

Second way: Using the IResourceService

The GetResource method of the IResourceService interface automatically fetches XML content for the specified resource id and returns a strongly-typed IResource object.

Here's an example of fetching a feature source object

IFeatureSource fs = (IFeatureSource)conn.ResourceService.GetResource("Library://Test/Data/SQLServer.FeatureSource");


where conn is an instance of the IServerConnection interface

Final way: Using ResourceTypeRegistry

The final way is to use the ResourceTypeRegistry class to go from raw XML content to IResource objects and vice versa.

Here's an example of creating a feature source object from an feature source XML document on disk.

string xml = File.ReadAllText("FeatureSource.xml");
IFeatureSource fs = (IFeatureSource)ResourceTypeRegistry.Deserialize(xml);
fs.CurrentConnection = conn; //Need to assign a connection if you want to use any extension methods
where conn is an instance of the IServerConnection interface

And here's one example of going the other way, from feature source object to file

IFeatureSource fs = ...;
using(Stream sr = ResourceTypeRegistry.Serialize(fs))
{
using(FileStream fs = File.OpenWrite("FeatureSource.xml"))
{
Utility.CopyStream(sr, fs); //Or if you use .net 4.0 use the new CopyTo() method
}
}


So there you have it, 3 simple ways of working with resources in the Maestro API

Debugging with the Edit As Xml command in Maestro

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.