Tuesday, 3 September 2019

Announcing: MapGuide Open Source 4.0 Preview 1.1

When I announced the availability of the 1st Preview release of MapGuide Open Source 4.0, I discovered shortly afterwards, a nasty show-stopping bug in one of the new APIs that breaks interaction with the bleeding edge version of mapguide-react-layout (the sole consumer of this new API).

As this is somewhat of a blocker in terms of what I'm am currently working with, I've put out a new 1.1 Preview release that includes a fix for this bug.

Download/Release Notes

If you don't use mapguide-react-layout, this bug probably doesn't affect you and you can stick with the existing Preview 1 release, if you have already downloaded and installed that.

And since we're here, the Linux binaries will be delayed until Preview 2 as my revised packaging scheme still needs more incubation time.

Wednesday, 21 August 2019

Announcing: MapGuide Open Source 4.0 Preview 1

Time to get the first part of my plan in motion: Get a new release of MapGuide out there!

This 1st preview release of MapGuide Open Source 4.0 is the culmination of 2+ years (Wow! Time flies!) of trunk development since the release of MapGuide Open Source 3.1. Competing interest in other side projects like mapguide-react-layout undoubtedly contributing to the long stretch.

A cliff-notes summary of what's new in this release (along with the download links) can be found on the 4.0 Preview 1 release notes wiki page. This blog will showcase all the new features in an upcoming series of posts.

Only 64-bit windows binaries are available as of this post. Linux binaries will soon follow as I am still experimenting with a new packaging mechanism for the Linux builds.

And if the "Preview" designation does not give it away, this release represents a work-in-progress and is not indicative of what the 4.0 final release will look like. There is still plenty of work to be done and more preview releases to follow.

Friday, 26 July 2019

Plans and stuff

Since I'm back, I'll start with some rough plans for MapGuide and my related projects.

The next version of MapGuide Open Source will be: 4.0

The next version of MapGuide Open Source was originally slated to be 3.3, but due to the volume of features implemented for this milestone and with some planned future work that will have "breaking change" ramifications (namely dropping support for PHP5 and supporting PHP7) means that the next release is better represented as 4.0

I'll be putting out a 4.0 preview release shortly that showcases all of the features implemented thus far, all of which I will be blogging about here. This will still support PHP5 for the PHP flavor of the MapGuide API for now.

Supporting PHP7 is a non-negotiable blocker towards a final 4.0 release, MapGuide Open Source 4.0 will only be final once we have stable and reliable PHP7 support.

I have an experimental testbed on GitHub which has been somewhat dormant since I first announced it, but will soon be re-activated and most likely incorporated back into the MapGuide sources where I'll continue this work on an experimental sandbox branch.

That's not to say that PHP7 support is the only remaining feature between the 4.0 preview and the final release. There may still be new features implemented in the meantime.

I currently can't tell you how long this journey will take (I honestly do not know how long this work to support PHP7 will take), but at least you know what the final destination will be.

MapGuide Maestro

The main theme for the next milestone of MapGuide Maestro is to support or take advantage of the capabilities/features introduced in MapGuide Open Source 4.0. Check this issue for details.

mapguide-react-layout

I will shortly put out a new 0.12 release which will bridge the 750+ commit gap since the last 0.11.2 release (the bulk of these commits, undoubtedly greenkeeper-assisted pull requests)

After this release, this project will be on a short hiatus as I give MapGuide Open Source 4.0 development maximum priority

mapguide-rest

I will eventually sunset this project with the release of MapGuide Open Source 4.0. The final pieces (which will finally culminate in a 1.0 final release) are:

  • Knocking off the remaining items on this list
  • Blocker: Being fully operational under MapGuide Open Source 4.0
Having mapguide-rest fully operational under PHP7 (that we assume MGOS 4.0 final will be shipping with) will be my final barometer of "it is done" for this project.

Monday, 22 July 2019

Ping replied in 10095780000ms

This blog has been quiet as of late. Not because I have run out of things to blog about, merely I've been on a self-imposed blogging hiatus to get a serious chunk of MapGuide development time in.

And the time is right to start talking about some of the stuff that has landed into MapGuide in the past few months as well as a some updates on my other MapGuide/FDO-related projects.

Stay tuned!

Thursday, 28 March 2019

Announcing: MapGuide Open Source 3.1.2

I am pleased to announce the availability of MapGuide Open Source 3.1.2

The notable changes in this release are detailed below:

Updated Web Tier Components

MapGuide Open Source bundles updated web tier components:

  • Apache HTTPD 2.4.37
  • Tomcat 7.0.92
  • PHP 5.6.40
Since PHP 5.6 is now end-of-life, this is most likely the last release in the 3.1 branch as we work to bring PHP 7 support for the MapGuide API in the next major release.

Functional SHP FDO provider for 64-bit Linux

Over the new year, I had set out to solve one of the last remaining blockers that prevented us from having a functional 64-bit SHP FDO provider for 64-bit Linux.

I had speculated that the blocker is due to incorrect data size assumptions in the SHP spatial indexing code on 64-bit Linux which would throw off spatial index queries. Intensive debugging sessions proved this to be the case and I was finally able to land the long-awaited fixes which is now available with the SHP provider bundled with this release.

The proof that the provider was truly functional was being able to load a SHP-heavy dataset into a 64-bit MapGuide Server and being able to pan, zoom, select and buffer SHP features without any errors or features disappearing in and out at various zoom levels (due to previously out-of-whack SHP spatial index queries)


Experimental King.Oracle FDO provider for Linux (32 and 64-bit)

Since I got a major win with one Linux FDO blocker and was on a roll, I figured we can do a double-whammy with the other major Linux FDO blocker: The lack of a functional King.Oracle FDO provider on Linux.

For this one I had speculated that the problem was due to heavy usage of wchar_t for strings which (due to different size assumptions on Linux) meant that most strings going in and out of the provider on Linux were garbage, meaning the SQL queries we think we were sending to OCI for execution were completely scrambled.

Due to the lack of solid examples of using OCI with wchar_t strings on Linux, I figured the code as it currently stands will never work on Linux. So I took the page out of a reference implementation I knew to definitely work on Linux (the OCI driver for GDAL/OGR) and wholesale #ifdef'd the entire provider codebase to use narrow (char) strings for Linux and their expected OCI functions, while retaining wide (wchar_t) strings and current OCI function usage for Windows.

The ability to easily spin up an Oracle XE environment (well until recently at least) meant that I was able to quickly verify that switching to narrow strings on Linux was indeed the way to go. This also provided motivation for me to implement a basic (and repeatable) unit test suite for this provider, finally giving us an objective baseline level of validation and verification for this provider.

The end result of all this is that the King.Oracle provider now not only builds on Linux, but it now finally works!


However, I'm certain that there will be bugs in this provider for Linux waiting to be revealed, so the provider gets the "experimental" label. Use at your own risk/discretion. Please do report any issues you find.

OGR FDO Provider Improvements

The OGR provider has undergone many "quality of life" improvements:
  • We've cleaned up various correctness issues around provider behavior. For example, attempting to access invalid property names in an OGR feature reader will now throw instead of silently failing before.
  • The provider supports a new DefaultSchemaName property that lets you specify a default schema name other than OGRSchema
  • The provider also supports a new DataSourceEncoding property to allow you declare the encoding for an OGR data source where it cannot be inferred by default by the OGR library so that properties/names/etc with non-english characters are rendered properly.
Fusion Changes
Other Changes


Friday, 15 March 2019

Announcing: vscode-map-preview 0.4.6

A kind user alerted me to the fact that my Map Preview extension for Visual Studio Code was using APIs that have long been deprecated and could be removed any moment in a future release, breaking this extension in the process.

Although I haven't touched this code in a while (not intentional btw. One person can only tend to so many different open source projects), getting back into VSCode extension development was a very comfortable affair:

  • Update a few packages here and there. 
  • Update TypeScript. 
  • Read up on the new Webview API, which is what our extension should be using now.
  • Replace usages of vscode.previewHtml with the new Webview API.
  • Verify the extension still works
  • Get re-acquainted with how to publish VSCode extensions
And ... voila! A new version of the Map Preview extension is available for your VSCode installation to auto-update to.


In terms of changes, beyond some updates to OpenLayers and a small bug fix or two, there isn't really much to write home about, it should still be the same extension as before. This release was driven primarily by the need to move away from their old vscode.previewHtml API over to their new Webview API.

Once things have settled down on my other projects, I'd like to give this project some more attention. There's still some cool ideas I want to explore with this extension. I don't know if I still want to go down the Cesium route as previously hinted as there have been many more data viz players that have arrived on the scene since then and I also sort of do not want to detract from the original goal and purpose of this extension: An easy way to preview on a Map textual content that you are already editing or viewing in VSCode.

Thursday, 24 January 2019

MapGuide tidbits: Updating coordinate system dictionaries

DISCLAIMER: This procedure is unsupported. Use at your own risk.

The coordinate system dictionaries that ship with a MapGuide installation are effectively coupled with that particular version of MapGuide. Should support for new coordinate systems, datums, etc be introduced into CS-Map, ideally you should upgrade your version of MapGuide to one that uses a version of CS-Map that incorporates these new definitions.

However, since the next major of version of MapGuide will still be some time away and the next immediate release (3.1.2) is a minor release, which we're being conservative with regards to updates to upstream libraries, it means there's a potential long wait to be able to use some coordinate systems, datums, etc if they were added to CS-Map since our last major release of MapGuide.

So if you can't afford to wait, you can try this method of updating your coordinate system dictionaries. We assume you are using the current latest version of MapGuide (3.1.1).

Firstly, use a subversion client to check out the current CS-Map source code from trunk.

svn co http://svn.osgeo.org/metacrs/csmap/trunk

Once checked out, you will need to build the CS_Comp.exe dictionary compiler. To build this dictionary compiler, open the OpenSource.sln file (under any VC* folder) in Visual Studio and build. If you do not have Visual Studio to build this executable, you can download this pre-compiled binary.

Either way, make sure the CS_Comp.exe is in your Dictionaries folder.


Then open a command prompt, navigate to this folder and run the following command:

CS_Comp.exe /b /c . .

You should see output like this


This produces a whole series of files with a .csd extension


Now locate the Dictionaries folder of your MapGuide installation and copy all the .csd files and NameMapper.csv into it, overwriting all existing files. In case things go wrong, you should make a backup of the existing files first.

Some new definitions may require new supporting grid files (eg. These files are required for the new Australian GDA2020 datum). Such files have to be copied across as well.

Once you have copied these files over, (re)start your MapGuide Server.

Now there's 2 ways to verify the new coordinate systems, datums, etc are in place.

Firstly, in MapGuide Maestro, when bringing up the coordinate system picker. You should see newer definitions for your particular country.


Secondly, as a sanity test you write a simple PHP script that verifies you can transform coordinates into these new coordinate systems. Here's an example script:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
<?php

MgInitializeWebTier(dirname(__FILE__)."./webconfig.ini");

$csFactory = new MgCoordinateSystemFactory();
$srcCs = $csFactory->CreateFromCode("LL84");
//Map Grid Australia, Zone 55, with new GDA2020 datum
$dstCs = $csFactory->CreateFromCode("MGA/20-55");

$xform = $csFactory->GetTransform($srcCs, $dstCs);

$srcX = 144.9674853;
$srcY = -37.808262;

$txCoord = $xform->Transform($srcX, $srcY);

echo "Lng: $srcX, Lat: $srcY";
echo "<br />";
echo "X: " . $txCoord->GetX() . ", Y: " . $txCoord->GetY();

?>

Save this and when you run it, if it prints out the transformed coordinates then your new coordinate systems should be working.

Some caveats

The key thing to watch out for here is whether a new coordinate system, datum, etc requires only a data file update or it requires both a data file update and an engine update

A new definition that only requires a data file update, will only touch one or more of the following files:

  • Any file with an .asc extension
  • NameMapper.csv
For example, this commit to CS-Map that introduces some new coordinate systems only touches the aforementioned data files.

New definitions that require engine updates are indicated by commits that also involve modifications to one or more *.c source files.

Such definitions would require building MapGuide against a newer version of CS-Map with these engine changes, which only happens with every new major release.

Based on my cursory testing, definitions that only require a data file update can be incorporated into your current MapGuide install with this approach. Otherwise, such a definition is unlikely to be usable until we release the next major version of MapGuide.

How would you know if a given coordinate system, datum, etc only requires a data file update or both? The only thing I can suggest is to hit up the CS-Map trac instance and search for commits involving your coordinate system, datum, etc and see if they change the above aforementioned files.