Announcing: MapGuide Open Source 4.0 RC1 and MapGuide Portable

We're on the home stretch now!

The first (and hopefully only) release candidate of MapGuide Open Source 4.0 is now available.

Changes since Beta 3

This release has the following changes since Beta 3:

• A new .net repository admin tool that replaces the existing series of PHP scripts that required a super-ancient PHP binary.
• Apache httpd updated to 2.4.65
• PHP updated to 8.3.25
• Tomcat updated to 9.0.108
• Plugged a memory leak in selection processing if it throws an FDO exception
• The .net bindings now have experimental support for Linux

New nuget packages

As a test run for the final release, the .net bindings have also been published to nuget.

• OSGeo.MapGuide.Foundation
• OSGeo.MapGuide.Geometry
• OSGeo.MapGuide.PlatformBase
• OSGeo.MapGuide.MapGuideCommon
• OSGeo.MapGuide.Web
  

To get started building a .net MapGuide application for 4.0 RC1, install the above packages (ver 4.0.0.10185) via the nuget package manager or via the dotnet CLI.

Need an idea or example of how to build a MapGuide application using these packages in modern asp.net core? Have a look at the mvc core sample.

As already stated, these bindings also have experimental support for Linux, meaning you can publish your .net application to run on Linux as opposed to Windows. Here's a screenshot of the mvc core sample application published to and running on Linux, talking to a MapGuide Server also on Linux being contacted from a web browser on Windows.

MapGuide Portable

The sub-project formerly known as mg-desktop is now known as MapGuide Portable (or mg-portable).

Why the name change? The "desktop" moniker felt too constricting. You're not exclusively tied to building just desktop applications. You could build "headless" console applications or maybe even MapGuide Server-free web applications with this library. As such, "portable" is the better moniker as it is a MapGuide Platform that goes with your application, in effect being portable.

Why are we mentioning MapGuide Portable in a 4.0 RC1 announcement? Because our extensive work on generating API bindings with vanilla SWIG had some minor splash damage. As MapGuide Portable builds on top of the shared Foundation/Geometry/PlatformBase series of libraries, we'd be leaving this in the lurch if we got these new fancy .net bindings for MapGuide proper, but still had to resort to the old crufty legacy bindings for MapGuide Portable, so extra effort was spent to get the .net bindings for MapGuide Portable to not only be generated through vanilla SWIG as well, but also retain package modularity by being able to depend on the new Foundation/Geometry/PlatformBase nuget packages.

The end result is a new series of nuget packages that you can use either in a legacy .net Framework 4.8 WinForms application or a WinForms application in the new modern .net!

Unlike the proper MapGuide API nuget packages, the MapGuide Portable packages are still Windows-only (since WinForms is tied to Windows). The new MapGuide Portable packages are:

• OSGeo.MapGuide.Portable - The MapGuide Portable platform
• OSGeo.MapGuide.Viewer - The MapGuide viewer component library
• OSGeo.MapGuide.Viewer.Portable - The MapGuide Portable platform provider for the viewer library

The older mg-desktop-* packages on nuget should be considered deprecated and you should move over to these new MapGuide Portable nuget packages as these packages support modern .net while the mg-desktop-* packages can only be used in legacy .net Framework.

The final stretch

Between RC1 and the Final release I will be primarily focusing on an API documentation sweep, getting functional API documentation up and ready. Only bugs of a show-stopping nature will be addressed and only if such bugs have easy means of reproducing (I can only do so much). I am allowing for up to a month for this development window before the Final release, so that we can wrap things up before Windows 10 reaches end of life, just over a month from now.

This long and arduous journey is almost at an end!

Download

Announcing: MapGuide Open Source 4.0 Beta 3

A new beta release of MapGuide Open Source 4.0 is now available.

The main driver for this release is updating an assortment of bundled components:

• PHP updated to 8.3.20
• Apache httpd updated to 2.4.63
• Tomcat updated to 9.0.104

Sticking with PHP 8.1 would've meant that come November this year we would be bundling something that would've been end-of-life. Updating our bundled PHP to 8.3 gives us the maximum possible runway in terms of support (on the PHP side) as its end-of-life is 2.5 years from now.

This release also plugs an assortment of memory leaks found in:

• The King Oracle FDO provider
• Rendering of tiles from tile sets
• Rendering of watermarks
• In-memory feature joins
• Render profiling

Download

Announcing: mapguide-react-layout 0.14.10 and MapGuide Maestro 6.0m13

We start the new year with a double-header release of:

• MapGuide Maestro 6.0m13
• mapguide-react-layout 0.14.10

What prompted these new releases other than (it's long overdue)?

Namely, it is to do with a notification I received about the coming deprecation (and eventual shutdown) of the epsg.io service that both pieces of software use to do proj4 projection lookups for any given EPSG code. This service will shutdown in Feburary (next month) and transition over to the MapTiler coordinates API. This new API requires an API key to use their services.

In the context of these 2 projects, the API key requirement introduces too much friction.

• If I take up the offer to use MapTiler, I have to register and bake my API key into both Maestro and mapguide-react-layout and am now responsible for API usage/monitoring under this key from users I have no control over. Last thing I want to deal with is bug reports from users because, let's say for example: proj4 lookup is broken because the API is no longer accessible for my API key due to quota exceeded. I just don't want to deal with such a scenario.
• Which means the alternative is to change the code to the extent that users can "bring their own API key", taking such API key usage/monitoring concerns out of my hands. This too is also too much hassle. I just want to do EPSG code to proj4 lookups nothing more nothing less!

If I was building a bespoke/custom mapping application for a client with EPSG > proj4 lookup functionality, then this API key requirement would not have been an issue, but this is not the case here.

So in light of these concerns, instead of moving to MapTiler coordinates. Instead I have opted to use spatialreference.org to do EPSG -> proj4 lookups. No API keys are required there.

So since this was the main driver for needing to put out new releases of MapGuide Maestro and mapguide-react-layout, we might as well take this opportunity to lump in some other fixes and minor changes, which are detailed below.

mapguide-react-layout changes

(reworked) Stamen and (new) StadiaMaps support

Stamen tiled layer support was broken for some time since it was taken over by Stadia Maps. I had already taken care of this in the VSCode map preview extension which had the same problem. But for mapguide-react-layout, the fix was a bit different due to it not using the latest version of OpenLayers and it is too much work right now to update to the latest OpenLayers in mapguide-react-layout.

So what was done for mapguide-react-layout instead is to create these Stamen tile layers as XYZ layers  instead of using the (now broken for that OL release) Stamen tile source. This works because Stamen tiles are ultimately tilesets using the XYZ web mercator scheme. The only other changes is that a Stadia Maps API key is required. So if your appdef defines one or more Stamen tile layers and you didn't specify an API key, you'll get the same startup warning you get when you have Bing Maps layers and didn't specify a Bing Maps API key

But if you do provide a Stadia Maps API key, you'll get the Stamen layers you've seen before.

Since a Stadia Maps API key is now required, we've also added support for other tilesets provided by Stadia Maps, like:

Alidade Smooth

Alidade Smooth Dark

Alidade Satellite

Outdoors

So if you are loading your mapguide-react-layout viewer from a Flexible Layout document, where do you need to specify this new Stadia Maps API key?

That's where the new release of MapGuide Maestro comes in to help!

MapGuide Maestro Changes

Stamen Maps (changed) and Stadia Maps (new) support

The Fusion Editor has reworked Stamen Maps support and added support for Stadia Maps

You'll notice that Stamen and Stadia Maps have 2 variants for every layer.

• A specialized version
• An XYZ layer variant ("... as XYZ")

What is the deal with this?

This was done so that if you are still authoring Flexible Layouts for Fusion instead of mapguide-react-layout, you can still view Stamen and Stadia Maps layers in Fusion through the existing XYZ layer support that is available in Fusion as demonstrated in the screenshot below, using the Stadia Maps alidade_smooth_dark tileset + API key.

So depending on the context:

If you are authoring a Flexible Layout for Fusion, choose the "... as XYZ" version and enter the Stadia Maps API key when prompted.

Otherwise, if you are authoring a Flexible Layout for mapguide-react-layout, choose the specialized version and enter the Stadia Maps API key in the provided field

This release of mapguide-react-layout will read the Stadia Maps API key from this new setting in the Flexible Layout when initializing with Stamen and Stadia Maps tile layers.

Using spatialreference.org for EPSG > proj4 lookups

As stated above, the projection management dialog of the Fusion Editor now uses spatialreference.org for resolving proj4 strings from EPSG codes

Other changes

• WMS Feature Source Editor: Improved the responsiveness and usability of the Advanced Configuration Dialog
• You can finally copy (ctrl-c) content in the IronPython console!!! You can now truly iterate on automation scripts by finally being able to copy the snippets of working Python code you just entered and eval-ed.

Download

• MapGuide Maestro 6.0m13
• mapguide-react-layout 0.14.10