Wednesday, 2 December 2015

Announcing: mapguide-rest 1.0 RC3

Here is the long awaited 3rd release candidate of mapguide-rest 1.0.

The main new feature (yeah, probably went a bit too early with that "release candidate" label) is a new set of APIs to:

  • Easily manipulate layer/group structure of a runtime map
  • Easily manipulate map selections non-spatially through a more simpler selection XML syntax
Which is demonstrated in various new sample applications included in this release.

Firstly, we have a new cesium.js sample demonstrating how to consume a mapguide-rest XYZ tile set using the new UrlTemplateImageryProvider

We also have a new example using the turf.js geometry library for slicing and dicing GeoJSON map selections client-side, which can then be saved server-side into a session-based layer and be incorporated into the map itself.

Since our sample applications use both OpenLayers 3 and cesium, we've also have an XYZ tile sample that uses both thanks to the ol3-cesium integration library.

And there's many more sample applications to try out. (NOTE: The vector tile example is broken in this release, I'm looking to fix that in the next release)

Other changes in this release include:
  • The whitelist configuration introduced in the previous release, is now extended to cover resource service APIs as well
  • Fix inability to walk nested directory structures for data publishing configuration files
  • Allow anonymous access to feature aggregate API
  • Allow custom root directory for storing XYZ tiles
  • Classify MgConnectionFailedException as a HTTP 503 error
  • The selected features route can be restricted to certain property names like the other routes that return feature data
  • XYZ tiles (not served from a Tile Set Definition) should no longer have labels/symbology anomalies at tile boundaries as mapguide-rest now renders out "buffered" XYZ tiles and crop the result to the original 256x256 size
  • GeoJSON output now covers the full set of supported geometry types
I'm certain this release will be the last one before I put the final 1.0 stamp on it. Other than documentation cleanup, and some performance testing I do not see anything of a show-stopping nature that impedes me from making the next release the 1.0 final release.