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.