Announcing: vscode-map-preview 0.5.6

This release updates OpenLayers to the latest 6.4.3, ol-layerswitcher to the latest 3.7.0 and adds support for opacity properties of the mapbox simple style spec for GeoJSON features.

Announcing: FDO Toolbox 1.5.1

This is a bugfix release that updates our MapGuide API binaries to the recently-released 4.0 Preview 2 version and fixes the ability to export a schema where one or more classes have an association property.

Download

MapGuide 4.0 showcase: Supercharged tile sets part 2

Previously, we showcased the new tile capabilities of MapGuide Open Source 4.0.

Since the last preview release, we've now introduced a new tile format that will open up new web mapping possibilities not previously possible: Support for Mapbox Vector Tiles.

Vector Tiles are a way to deliver geographic data in small chunks to a browser or other client application Vector Tiles are similar to raster tiles, but instead of raster images, the data returned is a vector representation of the features in the tile.

As a result, Vector Tiles relieves the burden of rendering/stylization on the MapGuide Server as stylization is now a responsibility of client mapping applications, allowing for much richer and interactive user/application experiences as in this case, the MapGuide Server only has to focus on the encoding and delivery of vector tiles.

Consider this new Mapbox Vector Tile sample that ships with the preview 2 release.

In this example, the MapGuide Server is delivering the Mapbox Vector Tiles. The styling and labeling of the features is all done client-side through OpenLayers style functions.

Here's an interesting exercise for the reader (if I don't beat you to it first :)) Implement a JS library that automatically translates our basic Vector Layer Definition documents in MapGuide in clean JSON format, to OL style functions for automatic client-side styling of MVT tiles.

Mapbox Vector Tiles has been around for a while, so what took so long for support to finally land in MapGuide? A few factors.

• The lack of a consensus around a "standard" around vector tiles. Our usual go-to for geo standards (the OGC) have been somewhat silent on vector tiles (last I checked) and if they actually did push any kind of standard for vector tiles, it certainly wasn't reflected in support in the popular GIS/Mapping software out there. Over time, it was clear that Mapbox Vector Tiles is the de-facto standard for vector tiles and if MapGuide was to ever support vector tiles, it should be supporting Mapbox Vector Tiles.
• MapGuide had not yet standardized on adopting C++11 as the base language version of C++, which limited the range of existing MVT encoding libraries available for us to use. Now that we have adopted the use of C++11, it was a case of what MVT encoding library to use for MVT support in MapGuide. I had initially tried using vtzero for MVT encoding, but the low-levelness of the library and uncertainty around how coordinate systems are meant to be handled meant that I had to look for an alternate library. In the end, we chose to graft the MVT tile encoder code from GDAL/OGR's MVT vector driver, which was a much more simpler affair.

So how can you start pumping out MVT tiles for your own MapGuide Open Source 4.0 Preview 2 install? Simply create a new XYZ tile set definition with a tile format of MVT

Then you can start fetching MVT tiles with your favorite web mapping library, whether that be OpenLayers or Leaflet or anything else on this big list!

And because MVT support in MapGuide is through XYZ tile access semantics, you can use MgTileSeeder or any other XYZ tile seeder to pre-load your MVT tile cache.

Announcing: MapGuide Open Source 4.0 Preview 2

Here is the long awaited second preview release of MapGuide Open Source 4.0.

Refer to the release notes for download links and an overview of what's new and change since the last preview release.

For MapGuide users on Linux who use Java, we are sad to say that the Preview 2 release currently has a known issue with Java support being broken (all .jsp requests cause Tomcat to return http 403 forbidden errors, meaning our Java-based viewer and code samples do not work out of the box).

We recently upgraded our bundled Tomcat to the 9.x series and required some config changes. Java support works on Windows, but is failing on Linux and we lack the proper resources to debug and investigate further. All we know and suspect so far is that it is some missing security-related configuration needed since Tomcat 8 or 9, but we don't know what that missing configuration is and as a result all our .jsp requests cause Tomcat to return HTTP 403 forbidden errors, rendering our Java viewer and associated code samples to not work out of the box.

If any of you have any idea what the problem is (by installing the preview 2 Linux build into your spare Ubuntu 16.04 VM or docker container and mess with the existing configuration to get the Java viewer into a working state), please let us know of your findings in this trac issue or by posting your findings to the mapguide-users mailing list.

We will resume our 4.0 showcase blog series shortly to cover the new features of MapGuide Open Source 4.0. To recap, this is what has been showcased so far:

• Supercharged Tile Sets
• Cleaner JSON responses
• Coordinate Transformation in the mapagent

This list is just the tip of the iceberg so stay tuned!

In accordance with my original plans, development efforts will now be focused on the final non-negotiable requirement in order for us to be able to produce a final MGOS 4.0 release: Supporting PHP7 in our MapGuide API so we can finally bundle a version of PHP that is actively supported. This primarily involves resuming development work on our experimental API bindings and getting it into a working shape for bundling with MGOS 4.0.

In awe of what vscode can do

I was originally hoping to drop the long awaited 2nd Preview of MapGuide Open Source 4.0 this week, but sadly some show-stopping bugs have crept up on the Linux side that means that sadly I have to push back the release until at least this one particular show-stopper for the PostgreSQL FDO provider is addressed.

Because this bug is present only on Linux it means we have to dive into gdb and try to debug through how this provider is producing garbage SRID values that result in broken PostGIS spatial queries.

Now normally I would dread at this prospect because gdb is command-line based and I miss being able to easily debug and step through code graphically with Visual Studio, but that was then and nowadays things are a lot different.

• We now have VSCode, un-doubtedly the most popular code editor that is also multi-platform.
• VSCode has extensions for C++ intellisense and integrated debugging with gdb
• For MGOS 4.0, we now also build MapGuide/FDO for Linux inside docker containers.
• VSCode also has extensions for remote development inside docker containers.

So this show-stopper has presented the perfect opportunity to see how hard or easy it is to tie all these pieces together for a nice debugging experience.

I start by spinning up the FDO build container and a PostgreSQL docker container to run our test code against.

Then after installing the remote extensions, I click the green box which then gives me an option to attach to a running docker container.

Which then shows the list of running docker containers, which includes my FDO build container

This then spawns up a second VSCode instance that allows me to open a folder within the running container. The FDO source code which I want to step through is accessible in this container, so I pick that folder.

Now if the experience here is the same as though I wanted to debug through this code from *outside* the container, I would then need to make sure the C++ extension is installed. I notice in this case that the extension UI shows local and remote installed extensions, so I have to install the C++ extension remotely.

If the debug experience for remote sources is the same as for local, then what should happen next is that I make a launch.json set up to run gdb with the executable that contains our test code. VSCode nicely creates a useful starting launch.json for me to tweak to what I need.

At this point, I make sure gdb is installed in the FDO build container, find some source code to stick some break points and hit the play button on the debug tab to start debugging and lo and behold ...

I am now visually debugging and stepping through the FDO source code! Just like Visual Studio on Windows. There was some small setup involved, but the process was mostly seamless.

VSCode is one truly amazing editor! With the right extensions, it can match any dedicated IDE in capabilities.

Now to tackle the actual show-stopper in question.