New plans and stuff

So after finally getting MapGuide Open Source 4.0 out the door, I took a self-imposed hiatus from all things mapping/GIS related for several months, permanently moved from Windows to Linux as my daily driver OS just in time before the end of Windows 10 support, and also to mentally recharge and savor the relief of having this major burden (of releasing MGOS 4.0) being finally lifted off of my back.

I now return with a renewed vigor and some rough roadmaps for things going forward in MapGuide and my other various projects. Part of that renewed vigor is due to the advent of ...

GitHub Copilot

In the past few months in my day job, I have been exposed to GitHub Copilot and it has changed the way I build and ship software, some changes bad, some changes good. Say what you will about AI (or AI-generated code/content) in general, but GitHub Copilot (or any other AI coding assistant) has ultimately been a net positive for me.

What separates how I use AI coding assistants from most depictions of "vibe coding" is that I know the technical and architectural fundamentals of what I am actually after. So I know when GH Copilot is generating what I'm after and when it's generating garbage, and knowing the right prompts to guide it back on track if it starts going off the rails, or know when to cut my losses if the situation is un-salvageable.

So with several months of GH Copilot usage at work, I have been thoroughly convinced that I should get a GH Copilot pro subscription for my own personal use. So last month, I finally bought a GH Copilot pro subscription and ... proceeded to blow my monthly allowance of usage credits in 2 weeks! 😂

But in those 2 weeks, I was able to make some major progress in mapguide-react-layout, knocking off some long standing technical debt and feature requests, some of which you'll see in future dev diary updates on this blog. The productivity gains were massive and turnaround times were quick! A new month has rolled over and with that, a reset of my monthly allowance and I have since learned to judiciously use GH Copilot in a less wasteful manner.

So, now armed with GH Copilot, I have a rough roadmap of things I want to achieve in my various projects, which are all outlined below. So let's start with MapGuide.

MapGuide Open Source

The next release of MapGuide Open Source will be 4.0.1. It will be a bug fix release and include any updated web tier components and upstream FDO fixes since the 4.0 release.

Since permanently moving to Linux as my daily driver OS and understanding that I will still need to produce Windows builds of MapGuide and FDO, I've been re-establishing my windows dev environments for MapGuide/FDO inside a virtual machine and reinstalling all the necessary dev tools. 

One surprise that caught me off-guard was installing Visual Studio 2026 Community Edition. Even though MSVC 2019 is the standardized windows compiler for building MapGuide/FDO on Windows, we can install older compiler workloads on newer releases of Visual Studio. So as part of reinstalling all the required dev tools, I thought it would be a simple case of installing VS 2026 with the MSVC 2019 compiler workloads and everything should be all good, right?

Well, near the tail end of my first MapGuide windows build inside this new VM, I hit a snag on the Windows Installer portion. It turns out our WiX 3.x installer projects are no longer supported in Visual Studio 2026! I was not going waste time and disk space to install VS 2022, so I looked at what options we have for Visual Studio 2026. The answer was to migrate our installer projects to WiX 6.x.

Before GH Copilot, the migration process would've been tedious, having to read migration docs, assess the impact of any breaking changes, etc, etc. But with GH Copilot, I was able to migrate and iterate rapidly towards a WiX 6.x windows installer project that successfully builds and produces a MSI installer.

Now here comes the tedious part that GH Copilot cannot help me with. I still have to manually test this Windows installer, making sure all the feature toggles, custom actions, registry and start menu registrations still work as before and I expect this to take several weeks.

Once this updated Windows installer has been verified as working, there'll be a 1-2 week window of incorporating any bug fixes and updated web tier components before putting out the 4.0.1 release.

mapguide-rest

We will start wrapping up various loose ends on this project. The next release will be 1.0 RC7 and will:

• Drop support for versions of MapGuide Open Source older than 4.0.
• Represent mapguide-rest as being feature complete. RC7 to final will be bug fixes only.

I expect GH Copilot to pull heavy duty in helping me knock off all of these long standing items.

mapguide-react-layout

The next release will be 0.15. It will have some exciting new features that you'll see in future dev diary entries on this blog, but the main feature will be to fully decouple ourselves from the Blueprint UI toolkit. Blueprint gave us a nice cohesive set of UI building blocks, but our production bundle sizes have paid a price for this convenience, not to mention that integrating this viewer into other projects that use other UI libraries is problematic as Blueprint is always included, whether you like it or not.

As part of this dev cycle, I've been taking inventory of everything in Blueprint that we actually use and refactoring their usages through a layer of indirection of "abstract UI components" so that we can supply an alternative implementation that is more bare metal and whose appearance and styling can be customized through good ol' CSS.

0.15 will be on the horizon upon the completion of this Blueprint replacement. GH Copilot has paying massive dividends in terms of progress and momentum on this particular project, so I am hoping for a fast turnaround on these remaining items.

MapGuide Maestro

Finally we come to MapGuide Maestro. I will finally bite the bullet and put an end to this endless series of 6.0mSomeNumber releases by putting a final MapGuide Maestro 6.0 release. This 6.0 final release represents the end of MapGuide Maestro in its current form as a Windows Forms based MapGuide authoring and administration tool.

After the 6.0 final release is out. MapGuide Maestro will be rebuilt from the ground-up as a true cross platform MapGuide authoring and administration tool. It will be built on modern .net (and all of its patterns and practices) and our ability to have a true cross-platform UI will be achieved through the use of Avalonia as our UI toolkit. 

A little experiment some years ago plus experience from building/maintaining a separate personal project that uses Avalonia for the UI (not yet announced/revealed on this blog, maybe I will someday) and once again armed with GH Copilot, I have great confidence in pulling off a ground-up rewrite.

And that is a peek into what's in store in the near future. Exciting times are ahead!

Announcing: MapGuide Open Source 4.0 Final (yes, you read it right!)

I am pleased to announce to final release of MapGuide Open Source 4.0!

It has been 6 years, 6 months and 14 days since the last major stable release (3.1.2). What started as something that was supposed to be the 3.3 release stretched out to what is now the 4.0 release. Maybe some things could've been done better to not make this release gap so big, but things transpired the way they did and what's done is done.

Download

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

Announcing: mapguide-rest 1.0 RC6.1

I've taken a momentary break from our (admittedly) glacial pace of MapGuide development to put out another release of mapguide-rest 

This release includes the following changes:

• Fix missing reverse routing on selection overview
• Fix bad feature query preparation when querying against watermarked layers
• Relax strict-typing on MgReaderToGeoJsonWriter::FeatureToGeoJson() so that it can work with MgPaginatedFeatureReader allowing pagination to work again
• Added missing properties parameter to swagger defn for session-based feature selection route

Download

We now return to regularly-scheduled programming of trying to get MapGuide Open Source 4.0 to the finish line.

As for mapguide-rest, I envision at least once more major RC *after* the final release of MapGuide Open Source 4.0 before finally wrapping things up on development work and pulling the trigger on the mapguide-rest 1.0 final release. Enough of this RC-after-RC business!

Announcing: vscode-map-preview 0.7.0

It has been brought to my attention that my vscode-map-preview extension now produces 401 responses for stamen map tiles, which has prompted me to put out a new release of this extension to better handle this situation.

This new release updates OpenLayers to 10.2.1 and now hides stamen tile layers from the base layer switcher if you don't have a Stadia Maps API key in your extension settings as this API key is now a requirement for viewing stamen tile layers.