Friday, 31 August 2012

New mg-desktop binaries

(I think I'm just going to stick with this title from now on. Thinking up new blog titles for every significant mg-desktop announcement is just too hard :D)

So yeah, I've put up a new release of mg-desktop in .net 2.0 and .net 4.0 flavors. Before you go ahead and download the files and compile against this release, be prepared to fix a lot of compiler errors for your existing code, because there is a grand-sweeping API change across the board:

  • All classes^ in the mg-desktop API are now prefixed with "Mgd" instead of "Mg"
The reason for this breaking change is two fold:
  1. Consistency. If a class begins with "Mgd", you know it's a class from mg-desktop.
  2. This opens up the possibility of building applications that works against both mg-desktop and the official MapGuide API without the risk of conflicts due to naming collisions.  
So with that out of the way, this release is mainly performance-focused, with improvements in several areas:
  • We keep cached copies of resource contents in memory to avoid hitting the hard disk for each GetResourceContent() call. These cached copies are flushed out anytime a SetResource() call is made with a matching resource id.
  • The legend component now caches layer icons and other assorted information, to reduce the unnecessary extra fetching of Layer Definition documents
  • The legend component now constructs the layer and group nodes in a background thread, and are added to the tree afterwards in a single batch. No more clogging up the UI.
  • The viewer's tooltip behaviour now matches what you see in the AJAX and Fusion viewers. That is, the tooltip query is delayed, and will only get dispatched if there is no significant mouse pointer movement within the delay interval (configurable via a new TooltipDelayInterval viewer property). The viewer no longer fires off a new tooltip query on even the most minute of differences in mouse pointer positions.
  • Tooltip and selection behaviour now goes through the QueryMapFeatures API, instead of our own custom implementation, which was previously needed as QueryMapFeatures was not ported over to mg-desktop yet. This is just another case of keeping mg-desktop as close to the MapGuide Server as possible in terms of behaviour.
This release also now exposes pre and post map rendering events in the map viewer control. You can hook in custom rendering behavior before or after the map images is rendered onto the control as part of its paint routine. The sample AppLayout extension now includes a Pre/Post rendering sample that demonstrates rendering underlay and overlay text.

Also, I've not only updated the previously blogged sample code demonstrating mg-desktop, but these samples are now also included in the zip distribution with dead simple build instructions. No need to setup any complex post-build steps or things like that. That's all been done for you in the sample code projects. All you have to do is just drop the mg-desktop files into the expected directory and the samples will build without issues.

Unfortunately, I did want to be able to also say that the .net 4.0 build of mg-desktop is now also available as a NuGet package. But the NuGet gallery doesn't seem to like the size of my mg-desktop NuGet package (38MB) that I've tried to repeatedly upload with no success :-( Does anyone who's versed in NuGet know if packages of such sizes are even allowed? I don't think I can cut down the package size significantly without gimping some of the functionality. Any ideas? I'm all ears.

^ This does not cover the classes in the Map Viewer library. Only classes in OSGeo.MapGuide.Desktop.dll assembly are affected.

Wednesday, 29 August 2012

A 200 post retrospective

When I first opened shop, I knew this blog was going to be about MapGuide and FDO in some form or another.

I just didn't imagine that 4 years and 200 posts later to the present day, that this blog would become the defacto knowledgebase of all things MapGuide and FDO, and that I would still have plenty of MapGuide-related things to talk about.

So to celebrate the 200th posting on this blog, here's some highlights of my double-century blogging run (in chronological order).

See you later at 300 posts (assuming I haven't ran out of interesting things to blog about)

Improving the MapGuide API documentation

A majority of you last week said that the MapGuide documentation is one area that definitely has lots of room for improvement, so I went to see what parts of the documentation can at least be improved immediately for the imminent 2.4 release, namely the API documentation.

Here's how the documentation looks with the 2.4 RC1 installation

Which is somewhat of a radical departure from what is currently published on the OSGeo site

It turns out, the one published on the OSGeo site (circa MapGuide Open Source 2.0) used a very ancient version of doxygen to crank out the API documentation. And the documentation as of 2.4 RC1 is the result of incompatibilities of our current doxygen configuration files with the version of doxygen I was using (1.8.0)

So after a bit of tweaking about with the doxygen configs (and a bit of MapGuide public header documentation cleanup and some link fixing), here's what the new MapGuide API documentation looks like:

Despite looking visually cleaner, it's also functionally better as it now has integrated search. Information about a given class or method in the MapGuide API is now just keystrokes away

Not only that, we've fixed up some of the doxygen markup in the headers, allowing us to show you deprecated APIs in the API reference as well (you probably didn't know there's deprecated APIs did you? Well there is, and you should avoid using them wherever possible)

This will appear in the next RC or final release of MapGuide Open Source 2.4. Not fully decided yet whether to make another RC or go straight to final. You'll find out soon enough.

Also got to figure out how to upload new API docs to the OSGeo site.

Thursday, 23 August 2012

The inaugural MapGuide state of the union address (or: Results of the user/developer survey)

So last week, I made a survey for you lot to fill and we got back 74 responses. Thank you to all who participated.

In hindsight, there were some important questions I forgot to include in this survey, but I didn't want to risk screwing up the incoming stream of responses, so I guess we'll put that in another survey in the future.

So prepare for a very long post with lots of charts and graphs with some interesting stats and some uncomfortable truths. Just remember the sample size of these results (74) when reading my analysis or when making your own conclusions about the state of where MapGuide is currently at.

About the MapGuide user base

Let's get some things straight. I'm not a GIS user (Map Projections? That's just a black box where point goes in and another point goes out right?). I'm a software developer who happens to be in a GIS/Geospatial heavy field. The purpose of the questions below was to gauge how many of you are basically in my type of situation.

Turns out, there's a sizable percentage of people like me.

I also wanted to gauge the general programming skill level. Turns out there is a good balanced spread.

Most programmers I know of would've at least heard of sites like Stack Overflow and its related sites on the Stack Exchange network (there's a GIS one too). So this next result was a bit surprising.

We encourage users to keep content on the mapguide-users mailing list as MapGuide-specific as possible because general programming and technical questions are easily answered by these others sites. Telling users to Google the answer to your general programming/technical question is somewhat superfluous because the first result is generally a post on Stack Overflow / Stack Exchange.

On that same vein, I was also interested in how many of you follow blogs of a technical nature as I believe blogs are an excellent medium for spreading knowledge.

It's good to see most of you are indeed switched on to the technical blogosphere.

About your Programming skill set

The MapGuide platform and ecosystem consists of code written in various languages and utilizing many different technologies and concepts. So I wanted to gauge how many of these things specific to MapGuide you are familiar with.

First off, programming languages

MapGuide (and its component technologies, FDO and CS-Map) are primarily written in C/C++. So this graph does illustrate the difficult barrier-of-entry to contributing bug fixes and feature enhancements.

Then there's the technologies involved

Sadly like the chart above, the polling results on the lower end of the spectrum just happen to be the ones with greatest emphasis in the MapGuide Server code-base, imposing another set of technological barriers to external contribution.

There are many interesting things we can do with HTML5 and it is good to know that at least half the respondents were familiar with HTML5 as this is the path that I think we should take our viewer technologies in.

Your knowledge of Linux

MapGuide is not a windows-only piece of software. It works on Linux as well, and so I wanted to gauge how familiar you people are with this Operating System.

NOTE: It seems I either fumbled the form design or Google Docs completely disregarded my form settings because the page containing the Linux-specific questions was supposed to be optional, so this data may have been fudged by the "no" and "other" responses.

The next question was an important one because I wanted to know if we are targeting the right distros for our Linux builds.

It turns out we were pretty much on the money providing builds for Ubuntu and CentOS. Whatever build resources spent on doing Linux builds would've been wasted if we had targeted the wrong distros.

Building MapGuide on Linux is a very complex and technical affair (just looking at the various out-of-date build instructions for $LINUX_DISTRO can attest to that!), so I wanted to know how many of you at compiled some code at least once on the predominant compiler toolchain for Linux.

How you install MapGuide

So the first important question here was what version of MapGuide you are currently using.

It is comforting to know that most of you are either on the latest stable release (2.2) or the soon to be final 2.4. Our go-to answers for most technical issues is "use the latest stable version" or "try the latest development version". We don't say this out of laziness (ok maybe a little), but because it helps us reduce our window for reproducing defects, because we simply do not have the resources to support X older versions of MapGuide.

Judging by the next result, it seems that 4GB of addressable memory may still be enough for everybody for a bit longer.

This next one makes for disheartening reading

Maybe it is because of this?

I have no problems admitting that I too share the same sentiments right now about the state of Linux support in MapGuide. I'm sure there's many things we can do to improve the Linux side of the MapGuide equation but the main problem I see is just the lack of knowledge more than anything else.

gcc/automake is such a radical departure from those weaned on the Visual Studio style of development/coding (those evil Microsoft drug dealers and their super addictive developer tools!), that it makes understanding and solving MapGuide problems from a Linux context quite difficult. I only just recently mastered the art of comprehending gcc/make build errors to finally be able to put out matching Ubuntu and CentOS builds of MapGuide 2.4. Don't even get me started on the lack of 64-bit Linux support. I'm still taking baby steps with this thing.

If the person who started these development and debugging guides for Linux actually finished them, I'm sure this situation might have looked better (at least for me). We're real knowledge-poor about Linux support at the moment. Things are where they are because nobody knows a better way.

These next set of numbers are pretty much what I expected.

Given the majority of you answered "Windows", it makes sense that users would favor the Microsoft-specific configuration as they are the ones that integrate best with Microsoft technologies (obviously). Java may have a low representation here, but it's significant enough of a language/platform in the server/enterprise space that it would be crazy to drop support for it.

I don't hold much of a high opinion about PHP as a programming language, but the ubiquity is understandable given the ease of setting up new PHP applications in IIS and Apache and that the PHP environment is always installed regardless of configuration options (as it is required by Fusion and the MapGuide Site Administrator).

I would've also been interested in what kind of associated tooling you people use for PHP/Java (.net is obviously Visual Studio), but again it's one of those questions I realized I should've added after publishing the survey. Oh well, leave that for next time.

How you knew about MapGuide

I was interested in knowing how and when you became acquainted with the MapGuide Open Source

That first graph pretty much correlates with my perception of Autodesk's involvement with MapGuide Open Source. Lots of mailing list activity and various presentations about MapGuide in the early years (2005-2008), winding down to mainly code contributions and -internals mailing list discussions in the present day.

Speaking of which ...

Your relationship with Autodesk (or lack thereof)

With these following questions, I wanted to test the notion of whether Autodesk has provided enough value in its commercial offering of MapGuide to justify owning one or more commercial licenses, despite the zero-dollar value of using the open source equivalent. Judging by the results below:

I'd say that is indeed the case.

Having used and beta tested the really early commercial releases of MapGuide (2007-2009), I was somewhat dubious about the value of the extra features that were included:

  • Production quality raster provider. Not much use if you are serving only vector data
  • Production quality SQL Server provider (for 2000 and 2005). Not much use if you don't use said version of SQL Server. Also it's been long supplanted by the Open Source provider for SQL Server Spatial.
  • Production quality Oracle provider. Not much use if you are not using Oracle. Also has a suitable Open Source alternative in the King.Oracle provider

But as of the 2013 release, Autodesk Infrastructure Map Server truly has a unique commercial advantage in terms of features:

  • The product formerly known as Topobase now integrated.
  • A native FDO provider for DWG files. The killer feature that was 6 years waiting. No more export/translation/publish to dumb DWF!
  • A specialized viewer for mobile devices.
  • Integrated GeoREST
These are real features of value that's well worth the price of a commercial license. And it seems most of you agree based on the above numbers.

Or could it be that AIMS is part of the many suites that Autodesk is so keen on selling now days? Or maybe you have an existing investment in Autodesk geospatial products that you want to leverage with AIMS?

Or maybe many were previous customers of Autodesk MapGuide 6.5?

How you customize and work with MapGuide

In terms of viewer-ship, the AJAX viewer is still king, but Fusion is closing the gap. I hope our Fusion enhancement work for 2.4 can close this gap further. There's still plenty of room for improvement in Fusion, but I think there is will always be a minimum modern browser requirement for Fusion while IE 6,7,8 are still in prominent use. There is only so much javascript wizardry we can do for IE 6,7,8 before we hit the limitations of their crappy javascript engines.

In terms of API usage, the choice of API obviously correlates with the installation configuration in the previous chart. It's nice to see some respondents understanding the capabilities that the mapagent http interface offers, of which the MaestroAPI is basically a .net object-oriented wrapper around and is the backbone of the Maestro authoring application.

Speaking of Maestro

Sort of expected these numbers (not tooting my own horn here. really :)), given that Maestro is the only available authoring option for MapGuide Open Source and Autodesk Infrastructure Studio is only included with the commercial version. I'm interested in what the "other" option could possibly be.

As a web developer, this chart below pleases me

A good distribution of modern web browsers (I even classify IE9 as a half-modern browser). IE7 and IE8 are borderline tolerable. My condolences and sympathies to the 5 respondents who still have to deal with IE6.

On the data front, it gets a bit interesting

Despite its storage and technical limitations, the ever ubiquitous SHP file still seems to be the preferred flat-file of choice for spatial data. I guess it's the format most users are provided the data in, because if I had a choice of format for my spatial data files, there's no way in hell I'd ever choose SHP unless I needed to share such files with other GIS applications. I'm surprised that SDF is still going strong over SQLite as it surpasses SDF in so many different areas:
  • Read performance. SQLite is the fastest format of the lot, bar none.
  • Tooling support. You can open SQLite files with any SQLite db admin tools, and there's tons of them out there. Important when you need to access such data through non-FDO tools.
  • Greater capabilities. The SQLite FDO provider is a first-class provider that gets all the new FDO API toys. You can use views, indexes and all other assorted DBMS goodies that is completely independent of MapGuide/FDO in most cases.
  • Ease of integration with thirdparty applications. SQLite data access through MapGuide/FDO is completely opt-in. You are free to use alternate means (eg. for data access through these files, as long as you properly maintain the required FDO metadata tables when doing structural changes with non-FDO tools. The only small integration issue is with writing/updating geometries as they are internally stored as FDO geometry BLOBs, but you would probably be already using MapGuide/FDO for that.
I lumped relational databases into a single category, because if you're using a relational database:
  • You care about ACID-ity and referential integrity of your data.
  • You are integrating with an existing system or application
  • You get to exploit the full capabilities of your DBMS for optimal performance.
And all the supported RDBMSes that FDO can access provide these qualities in one shape or another.

In terms of customizations, most respondents fell within the default extension points provided by MapGuide

I guess the hardcore stuff like mg-desktop fulfills a niche that the average MapGuide developer probably doesn't need or require. But it does goes to show that the MapGuide Server code-base does have utility outside of being a Web Mapping Server which was so concisely demonstrated in that AU presentation 3 years ago.

MapGuide Documentation and Learning

This set of questions was made to gauge the quality of the documentation and samples that currently exist out there. We asked about your current perceived knowledge of MapGuide

It appears the majority of you know comfortably enough about MapGuide and its APIs to build your specific applications and customizations which is a good thing. The small number of true experts (besides myself), does limit our ability somewhat to fix and improve the software outside of Autodesk. If some of these respondents are Autodesk developers themselves (the survey *is* anonymous after all), it just exemplifies this problem even further.

As to how you acquired this knowledge, mostly through the expected channels.

Now as to the quality of the documentation and samples themselves

The numbers aren't exactly flattering, and I can definitely see some areas where documentation can be definitely improved. Some of the samples could definitely do with a makeover to reflect modern patterns of software development. 

Take .net for example. The .net viewer sample is still inline aspx (yuck!). Anyone versed in the current way of developing web applications will undoubtedly scratch their heads looking at this. We could probably do with one done in the style of MVC, or maybe some examples with the new fancy Web API.

We have a section in the MapGuide wiki dedicated to code samples that could do with some love.

The mapguide-users mailing list

Besides sample code and documentation, the mapguide-users mailing list is the other primary place for discussing all things related to MapGuide Open Source, so it helps to get some statistics about that too.

Firstly, I was interested in how you use this mailing list. Gotta say, there's a lot of lurkers we've got here (if you were to extrapolate these results)

Then there's the frequency of usage. I see a fair chunk of you follow my daily ritual of firing up the nabble front-end to mapguide-users in your web browser the moment you fire up your work computer :)

Then the important one, the quality of the content on the mailing list and it seems it is fulfilling its purposes in helping with your MapGuide-specific problems on an average basis.

In terms of the quality of content, I tend to agree with the majority here. Most of the chaff you could probably categorize into the following:

1. Posts with lack of specific details. A one sentence question saying something "doesn't work" doesn't really help us in trying to assist you solving your problem. There are many other factors we normally need to know about like:
  • System Specs
  • MapGuide Install Configuration
  • Steps to reproduce
  • etc, etc.
These are the stock pieces of information that any software support personnel would require in order to provide help. Yet we are somehow expected to magically read your minds to understand the exact environment you are running MapGuide on.

2. Coding/Programming problems that can be easily answered by a Google search or Stack Overflow or any related Stack Exchange site (it's why I posed this question in the survey, just to make sure you're aware of such sites). Or posts containing pages and pages of unformatted source code, ending with "how can I fix this? Plz help me, it's urgent". Or people who follow up your answers with "It doesn't work" because they probably copy/pasted your sample code verbatim without fully understanding the context of the answers given. These type of posts reek of pure laziness on the part of the OP.

3. English not being the OP's primary language. I don't think we can't do much about this one. Whether we like it or not, English is the de-facto language we are expecting questions and answers to be written in on the mailing list.

We even stick a link on the nabble front-end to tell you how to not ask questions like the aforementioned types, but it's probably like a EULA or Terms of Service that you just automatically accept. Nobody reads it!

So once again, not surprised about the perceived quality of questions asked on the mailing list.

Your MapGuide pain points

We asked whether MapGuide as a whole does what you (or your users) require

For the majority of you, it seems that MapGuide ticks most of your boxes, so I was interested to know if the software/tools that help you tick the remaining boxes were competing products

So in terms of actual un-ticked boxes, I basically took my own wishlist and added in things that people never seem to stop complaining about :)

Given that "other" polled last, it seems my pain points echoes yours as most of the items in question polled with evenly spread numbers. So given these pain points, I wanted to know if you could "put your money where your mouth is" so to speak.

I'm guessing for those that responded "yes", your specific pain points must've been all different because otherwise one of the pain points I commonly hear on the mailing list (GDAL provider stability/performance) would've already been solved.

A small group of you expressed concern about MapGuide's future, which is the reason why I formulated this survey in the first place, so you can see the results here and form your own conclusions.

MapGuide's standing as an OSGeo project

MapGuide is just one piece of software under the umbrella that is OSGeo. So it was of interest to me to see if you used any other software/tools in the OSGeo stack besides MapGuide/FDO/CS-Map/Fusion
As expected, the major players (OpenLayers, QGIS, GDAL, PostGIS) have major representation. One thing I would see MapGuide do is be better friends with its fellow OSGeo software. Off the top of my head, some QGIS-MapGuide-FDO integration would be really interesting.

All OSGeo projects have an integrated issue tracker and wiki powered by Trac. So it was interesting to find out how many of you actually use the MapGuide/FDO/CS-Map/Fusion ones.

For those that do use the MapGuide/FDO/CS-Map/Fusion trac, it seems the wiki gets a good mileage, but there isn't that many that keep this wiki content fresh and relevant. 

I guess this sorts of ties in to our quality problem with samples/documentation. We have the means to improve them, we just need to do it in a proactive way through blogs, wiki content and documentation updates instead of reactively through mailing list answers.

The next one is a bit disappointing and ties into the general theme of there being very few non-Autodesk contributors.

I guess this could be the result of:
  • The general non-Autodesk brain drain.
  • Lack of knowledge about source control and applying patches. I sure hope this isn't the case. Using source control is so important in software development it should be the next thing taught after writing "hello world". Learning subversion isn't rocket science and using a graphical SVN front-end make this dead easy.

Other things that cannot be quantified into pretty charts and graphs

I couldn't determine the suitable set of pre-defined responses for the following questions, so I left them open-ended, making quantification in the form of charts and graphs impossible, but there left here for completeness.


So what can we conclude from all this? Here's a few of mine:
  • You all aren't freeloaders :) There is enough value in the commercial version of MapGuide for most of you to own a commercial license, and you are knowledgeable enough about the differences to know whether the commerical or open source version is more suitable.
  • On that same subject, there is a sizable interest to donate/fund for any improvements. I'm guessing there just isn't a unified consensus as to what should be improved. It certainly doesn't look like GDAL raster performance/stability is one of them.
  • We are strained in the technical knowledge department. We definitely could do with more non-Autodesk active developers/maintainers. The non-Autodesk bus factor is dangerously low. We seem to have a healthy group of "power users", we just need some of these users to upgrade to the next level and start becoming involved in actual development/maintenance. That's all an open source project needs to stay alive isn't it? A core group of passionate users.
  • Linux support is bad because we just don't know any better. Sad but true. If there's a better way then we're all ears.
  • Documentation/Samples definitely can be improved a lot. We seem to be more reactive (mailing list answers) than proactive (wiki/blogs/etc) when it comes to this however.
  • The 2.2 to 2.4 gap was just too long. We need to release more early and release more often.
But these are just my thoughts, you can draw your own conclusions.

Wednesday, 15 August 2012

MapGuide User/Developer Survey

I'd like to get a pulse on the MapGuide User/Developer community and the state of the MapGuide Open Source project, so I've made a survey for you guys and gals to fill. Whether you've used MapGuide Open Source (or its commercial counterpart) since its inception (like me) or you've only briefly used it, I'd still like your input.

Google Docs Survey

I'll leave it open for a week and have a follow-up post to analyze the survey results.

Wednesday, 1 August 2012

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:



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.