Resource Schema versions in Maestro and why it matters.

When you choose to create a new resource in Maestro, you are probably overwhelmed by the choices available:

Why all these different versions? Read on for an explanation.

In the very beginning (MapGuide Open Source 1.0), the available types of resources you can have in a Site Repository were initially defined. All such resources used v1.0.0 of their respective XML schemas, which defines the XML content model of each respective resource type. Any XML document is a valid Feature Source, Layer Definition, Map Definition, etc if their XML content validates against their respective XML schema.

As time went on, new features have been added to the product. To expose settings for these new features in the resources you are editing and authoring, either a new resource type has to be introduced with a respective initial XML schema (Application Definition, Watermark Definition, etc). Or, a new version of the existing XML schema is introduced, that contains the new XML content model elements that define settings for these newly introduced features.

As you can see from the dialog above, some resource types like the Layer Definition have had many revisions to their respective XML schema due to the multi-phased introduction of Advanced Stylization

So why is Maestro making so many different versions available to you? One simple reason: data compatibility with older versions of MapGuide/AIMS.

This author understands that some of you may not be on the latest version of MapGuide/AIMS so Maestro offers you the ability to choose the appropriate resource schema version of the resource you want to create. Where Studio will automatically use the latest schema version of a given resource (making it difficult to package such data and load it onto an older MapGuide/AIMS server), Maestro gives you the choice of what version you want to work with. Maestro will never automatically upgrade your resources to the latest schema version. The choice to upgrade is yours alone to make.

Notice that these items are filtered and sorted by MapGuide/AIMS version, indicating the first release where this resource version was introduced, giving you a clear idea what versions of MapGuide/AIMS you can load this data into should you package it up from your current server.

Also, the editors are also aware of schema versions, and will appropriate enable/disable relevant parts of the UI to ensure that you will always be creating resources that match the underlying XML content model as defined by its XML schema. For example, take a look at the editor for a v1.0.0 Layer Definition document.

KML elevation and Composite Style settings are disabled because they were introduced in later revisions of the XML schema and are appropriately disabled by the editor.

So what features are introduced in each new version? Well for now you will have to refer to this text file. Having this information available in the New Resource dialog is definitely something worth my consideration.

Finally with all these choices available, what version do you use when authoring? That choice is completely up to you. Always going to be using the latest and greatest MapGuide/AIMS? Go for the latest schema version. Need to be able to load this data back into a AIMS/MapGuide x.y.z server? Pick the matching version from the dialog.

With Maestro, it's all about freedom of choice (even if there's a lot of them!)

OpenStreetMap support in Fusion

Fixed in time for the eventual final release of MapGuide Open Source 2.4, is the OpenStreetMap support in Fusion. What did we exactly fix?

Notice how when you tick any of the OpenStreetMap layer sub-types in Maestro's Fusion editor

The OpenStreetMap layer in Fusion always seem to look the same?

This is because of bugs in Fusion's layer and basemap switcher widget that causes:

• Any selected OSM layer sub-type to always default to the "Mapnik" tileset so regardless of the OSM sub-types selected, Mapnik will always be the chosen OSM tileset.
• The basemap switcher to choke on un-recognised OSM layer sub-types

And it's also because of a bug on the Maestro side that fails to inject the required script that defines these additional sub-types.

So with this fix in place (and some post-release fixes on the Maestro end), you now have the choice of the following OSM tilesets in Fusion:

Mapnik

CycleMap

and TransportMap (in place of Osmarender, which is no longer provided by OpenStreetMap)

If you installed 2.4 with the SVN metadata feature, this fix is just one "svn update" away.

One thing to note when taking advantage of the SVN metadata feature, if you get conflicts when updating it's generally because of un-mergable local changes made in the SVN working copy. Unless you've been doing some serious local modifications, such local changes are usually version numbers stamped when creating the MapGuide release, which should generally auto-merge safely without any conflicts. If you are using the SVN metadata feature purely as an update delivery mechanism and you get conflicting files, then simply just delete the conflicting files and re-update the working copy.

Otherwise you'll have to learn how to properly resolve such conflicts. Anyone who has used source control will inevitably have to deal with such cases one way or another.

Announcing: MapGuide Maestro 5.0 beta 3 and 4.0.2 maintenance release

Here's a long overdue update which includes the following changes

Secured Credential Support (5.0b3 and 4.0.2)

A major client-side security hole has been plugged. All applicable Feature Source editors now secure login credentials by default. Maestro will no longer create Feature Sources with plaintext credentials.

If your FDO provider uses login credentials but does not have a specialized editor, no worries. The generic editor also supports specifying secured credentials. A new "Set Credentials" link is available.

Click it and you get a new dialog that lets you nominate the username and password connection properties and their respective values. These values are saved to MG_USER_CREDENTIALS and are replaced in the connection properties with the %MG_USERNAME% and %MG_PASSWORD% placeholder tokens.

However, we still have problems packaging such feature sources (we lose the encrypted MG_USER_CREDENTIALS in the packaging process due to design limitations). The only workaround for packaging such feature sources, is the use the official method via the Site Administrator. New validation rules have been added to warn you about such feature sources.


Theme Improvements (5.0b3 and 4.0.2)

If you know how theming works, it's just taking a given rule and duplicating it a certain number of times with various different fills and/or border colors based on a given set of matching rules. To this end, Maestro now let's you use the first style rule as a template for generating the theme.

Live Map Editor improvements (5.0b3)

The Live Map Definition editor now shows all Layers and Groups regardless of visibility, which is important because you need to be able to "see" all the Layers and Groups that you can edit. Such layers and groups are greyed out to distinguish from the visible Layers and Groups.

The map viewer component also has many of the viewer enhancements ported over from mg-desktop, so yes! The Live Map Definition Editor can now do mouse wheel zooming among other things.

The mg-desktop wrapped implementation of the Maestro API now also includes a wrapper for the Runtime Map, meaning Map Definitions in a mg-desktop repository can now also be edited by the Live Map Definition Editor.

Other tweaks and enhancements (5.0b3)


The Point Feature Style dialog now uses tabs for screen space optimization.

For SDF and SHP Feature Sources, we now label what that file and folder buttons stand for

The status bar now shows the active connection, as some commands operate against the active connection and it helps to know what that connection is.

And finally, that bug is also fixed. You can stop asking about it :) And ODBC configuration works again for 4.0.2.


Download

New mg-desktop binaries (now with comprehensive sample code)

This latest drop of mg-desktop still doesn't do tiled maps (I've got a basic idea at the moment, which involves using BruTile), but it does have the following new features and fixes:

• Lots of internal traces added to mg-desktop. If you turn on internal trace logging in Platform.ini, your Trace.log should be filled with much more useful information now. Note that you only need to turn on internal trace logging if you need to do some serious debugging. This is turned off by default in Platform.ini
• Support for secured Feature Source credentials
• We do basic XML content validation with our implementation of MgResourceService. The checks are currently for well-formedness of content and that top-level element matches resource type.
• APIs in our implementation of MgFeatureService (namely GetClasses and GetClassDefinition) now work properly with extended feature classes.
• Plenty of viewer and component fixes

But the most important change is that the sample App Layout in the binary distribution now includes a comprehensive set of examples in how to use the mg-desktop API. Basically we ripped out the MapGuide Developer's Guide samples and stuffed them into the App Layout extension model.

The interesting thing about this was that the sample code was that it was mostly copy and pasted from the MapGuide Developer's Guide samples with the ASP.net stuff replaced or removed, which goes to show the striking similarity of mg-desktop's APIs with the official MapGuide APIs, which is 100% intentional.

The source code for this sample extension is also available for download

A note about Maestro's Package Builder and feature source credential security

If you use Maestro to create packages, be careful when working with Feature Sources using %MG_USERNAME% and %MG_PASSWORD% tokens.

Because Maestro is 100% managed code, we do not have the ability to portably access the C++ logic that encrypts/decrypts the MG_USER_CREDENTIALS resource data element, which is used to store the encrypted username/password you specified when creating that Feature Source and is decrypted by the MapGuide Server when it needs to establish a connection to this feature source. This is mostly applicable to feature sources that have username and/or password as part of its connection parameters (ie. RDBMS providers)

This is the reason Maestro stores such credentials in plaintext as part of the feature source XML, which is understandably not secure. Until we have a solution for encrypting MG_USER_CREDENTIALS in pure managed code (ie. A verbatim .net version of MgCryptographyUtil with 100% matching behaviour), storage of credentials as part of the XML content in plaintext is the only thing Maestro can do if you ever want to be able to create such feature sources with it.

If you attempt to package such feature sources with Maestro, it will pack MG_USER_CREDENTIALS resource data unencrypted. Maestro does a series of GETRESOURCECONTENT and GETRESOURCEDATA calls to assemble the package. Doing a GETRESOURCEDATA on MG_USER_CREDENTIALS will return you the un-encrypted username (MapGuide Server will auto-transform such requests), this is what gets packaged by Maestro which is incorrect. This doesn't happen with MapGuide's packaging as it obviously works behind the scenes and can retain the encrypted form of MG_USER_CREDENTIALS

Having just said that, it is probably impossible "by design" to create a package client-side with properly encrypted credentials as the mere act of fetching the MG_USER_CREDENTIALS resource data will automatically give you back the decrypted version. If you ever get a MgDecryptionException trying to load a Maestro-created package, it is because that package contains plaintext MG_USER_CREDENTIALS resource data instead of the encrypted version.

As an interim measure, Maestro will have a new validation rule that warns you about such Feature Sources, so you know that you are dealing with this particular problem. If this issue (Maestro creating feature sources with plaintext credentials and creating packages such feature sources incorrectly) is a problem for you, your options currently are:

1. Always use MapGuide/Infrastructure Studio to create and/or re-secure such feature sources. Of course if you don't have a licensed copy of Studio, you are totally out of luck here. You'll have no choice but to create feature sources with credentials exposed in plaintext in the XML content.
2. Always use the official packaging method (ie. with the Site Administrator) for such feature sources to retain the encrypted feature source credentials.

If Maestro was windows-only, the solution would be easy as we can just use some C++/CLI glue to tap into MapGuide's existing encryption/packaging logic. SWIG and/or P/Invoke though portable is un-proven because getting .net code to call into a glue layer (whether generated by SWIG or a hand-crafted C interface) into MapGuide's encryption/packaging logic on Mono in Linux/Mac is a very tall order!

As you can see, this is a very complex problem with plenty of pros and cons on the current set of proposed solutions. Need to think about this some more.

MapGuide Open Source 2.4 RC1 released

Get all the information and downloads from here

This includes plenty of viewer (AJAX and Fusion) and schema report fixes from beta 1. Just like the beta 1 release, this does not include the ArcSDE provider. We hope to get an official FDO 3.7 release out before we put out the final release of MapGuide Open Source 2.4

Also here's a sight for sore eyes

Yeah, RC1 can serve working KML again!

Using SQL Server Management Studio to preview WKT geometry

Here's a little trick I discovered with SQL Server Management Studio today trying to visualise some bounding boxes.

Since the 2008 version, SQL Server has has support for spatial data. This support also extends to associated tooling like Management Studio. Any query you run against a table/view that contains a geometry/geography column will also show the results visually in the Spatial results tab.

It also turns out queries that return adhoc rows of geospatial data also work in this fashion, for example the result of geometry::STGeomFromText(). These queries don't even have to be against actual tables/views!

These results can also be aggregated together using the SQL UNION ALL keyword.

And because the Spatial Results view can use any non-spatial column for labeling, you can also include arbitrary text as part of the select query to "label" each associated geometry.

Pretty nifty!