For MapGuide, OpenLayers 3 is ready for prime-time.

As some of you may recall, nearly two years ago I landed in MapGuide support for OpenLayers 3.

However, this support was partial as it only targets un-tiled Map Definitions. None of the tiling mechanisms in OpenLayers 3 were compatible with the tiling scheme used by MapGuide meaning OpenLayers 3 cannot consume non-XYZ tiles from MapGuide ...

... Or so I thought.

It turns out that it is indeed possible to consume non-XYZ tiles from MapGuide, here's one such example using the just released v3.6.0 of OpenLayers.

What this means is that OpenLayers 3 is at feature parity with OpenLayers 2 in terms of MapGuide support, meaning it has the core functionality we need to build a MapGuide client mapping application out of.

Many thanks to Andreas Hocevar of Boundless for the code sample.

MapGuide tidbits: SQLite interoperability

Sometimes, your data has to escape the MapGuide/FDO ecosystem and be consumed from other geo-software. If the limitations of the omnipresent SHP file format leave a lot less to be desired, then the next best thing is SQLite databases.

The reason I say this is because:

• SQLite files (in our context) are just regular SQLite database with some special tables so mapping software know how to read features from them. You don't need FDO to peek inside the structure of a SQLite database. Any other SQLite database tool or library can get at the data as well.
• SQLite is a relational(-ish) database. So features you'd expect in an RDBMS (eg. views) are also available in SQLite. Can you say that about SHP files?
• The biggest reason. There's an OGR driver for SQLite, and it understands FDO's flavor of SQLite databases, and if your mapping software isn't using FDO, it's using GDAL/OGR!

Sure, there's a few quirks here and there, but they can be worked around or fixed.

MapGuide tidbits: Fixing SQLite data files with no coordinate systems

From the "I lost several hours discovering this so you don't have to" department

Today, I was tasked with producing some KML files. The spatial data was in SQL Server and it needed to be married with some CSV files I had, but I wanted it to get into a more portable format so I can do the bulk of the styling work in MapGuide without having to touch the SQL Server again.

Due to some quirks in this SQL Server database, the SQLite file that were produced from an FDO Toolbox bulk copy did not have any spatial contexts in them. This turns out to be a big problem because MapGuide has to know what coordinate system your data is in for rendering and various outputs to work, especially if coordinate system transformation is required. You can fix and/or flub such a coordinate system using the Coordinate System override section of the Feature Source, but this only works if MapGuide/FDO can read a spatial context from the data store for you to stick in a replacement coordinate system in.

This actually broke the KML support in MapGuide I was intending to use because it needs to know if your data is LL84 or transformable to it and since the SQLite file had none, MapGuide didn't do anything with the data when I wanted a KML export of it. Rather than waste time re-exporting this data in another format, I wanted to see if such files can be "fixed" in-place and be made usable again.

Since SQLite files are actual relational(-ish) databases, you can open them any SQLite database viewer^ (there's a lot of them) to take a look at the contents. When you open such a file, you'll see various tables representing each of your feature classes and some special tables:

• fdo_columns
• geometry_columns
• spatial_ref_sys

fdo_columns contains the FDO property metadata for each column of each table. Without this table, the SQLite FDO provider will treat all columns as strings, even if your column stores numbers, dates, etc.

geometry_columns contains the metadata for the geometry columns.

spatial_ref_sys contains coordinate system information.

In the event that MapGuide reads 0 spatial contexts from your SQLite data store, it's because:

• There are no rows in spatial_ref_sys. Each row in this table is read as a spatial context
• Any rows in geometry_columns either have an srid of -1 or an srid with no match in spatial_ref_sys

So with this knowledge, to "fix" such files so MapGuide knows what coordinate system they're in:

• Insert a new row into spatial_ref_sys
• Update the srid column of all rows in geometry_columns to the srid of the row you inserted into spatial_ref_sys

Or if none of what I just said made sense, just run the commands in this gist in your SQLite database admin tool of choice. Once done, your SQLite database will have a spatial context which you can then put an override in your Feature Source so that MapGuide knows what coordinate system to interpret your data in.

^ Though FDO Toolbox can technically be used to admin SQLite databases, I am suggesting alternative tools as I am not sure whether the SQLite FDO provider will let you "fix" something that it has an already-open connection to, nor do I know if the SQL commands the fix this will work as intended when going through the SQLite FDO provider. Better to be safe than sorry.

Announcing: MapGuide Open Source 3.0 RC1

With no real show-stopping bugs of note, I've decided to put out the first release candidate of MapGuide Open Source 3.0

RC1 rolls back a problematic change introduced in beta 2 that resulted in a feature reader from SelectFeatures query not returning all results in the reader. Other than that, this contains some minor fixes for Fusion and the SDF and SQLite FDO providers. All the details can be found the release notes below

Download

Announcing: mapguide-rest 1.0 RC2

Here's the second release candidate for mapguide-rest 1.0

The main addition in this release is support for defining a "whitelist" in config.php that will restrict feature service APIs to only the specified operations and feature sources defined in the whitelist, allowing you to reduce the attack surface of your mapguide-rest install by only controlling API access to feature sources of your choosing. You can find a commented-out whitelist example in config.php that you can adapt to your own installation.

Other changes and fixes include:

• Fix runtime map XML generation for versions of MapGuide that do not support CREATERUNTIMEMAP
• Fix XYZ routes for Tile Set Definition resources
• Support a bboxistargetcs flag that allows the bbox parameter of any feature query route to be declared in the coordinate system indicated by the transformto parameter
• Display of error response stack traces can now be toggled in config.php
• Fix invalid GETMAPIMAGE operation version in map image adapter
• When doing a search result query via the data publishing framework, if the query produces a single result, the "single" view template will be shown instead of the "many" view template
• When doing a search result query via the data publishing framework, if the query produces no results, the "none" view template will be shown instead of the "many" view template

I'm thinking there will probably be at least one more RC after this as there is still some more attack surface reduction work to do before I can confidently slap a 1.0 final label on it.

Download