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-react-layout 0.14.9

Our journey needed to make a temporary detour, with another release of mapguide-react-layout.

This release has the following notable changes

Legend layer and group customization support

This release provides a new viewer init option to allow layer and group elements of the Legend component to be augmented with additional HTML content. For example, we can use this to add a download link for specific layers (how to actually implement the download link is an exercise left to you the reader)

See this comment for an example of how to customize the layer and group elements.

Reduced excessive re-rendering

In the process of implementing the above feature, we discovered that some components (the Legend component in particular) did a lot of pointless re-rendering which contributes to sluggishness in viewer performance.

For this release, great efforts were made to ensure that component re-rendering is the result of legitimate changes to component state and not from pointless re-rendering from bogus shallow state "changes"

Removed IE-specific polyfills and workarounds

Internet Explorer ceased to be a supported browser by Microsoft for some time now. This release formally removes our various IE-specific workarounds and polyfills that were only there to support this ancient browser.

Other changes

• The urlPropsIgnore setting is now considered when the viewer updates the URL state
• The viewer bundle patches OpenLayers to log a console warning and abort rendering when attempting to render a map overlay image with a width/height/scale/dpi of 0
• Fixed an issue where no map images are rendered if the browser zoom is below 100%

Download

Announcing: mapguide-react-layout 0.14.8

We've arrived at the next stop on the tour, a new release of mapguide-react-layout

This release has the following notable changes

Map Definition with XYZ tileset restriction lifted

MapGuide Open Source 4.0 removed the restriction that Map Definitions cannot link to a XYZ tileset definition. This release of mapguide-react-layout takes advantage of this removed restriction by now supporting loading of a Map Definition that links to a XYZ tileset.

Support for loading custom projections and app settings from an Application Definition

The beauty of the Extension element in an Application Definition document (and why its XML schema has not required a revision since its introduction) is that we can put any content in there.

With this release, we are taking advantage of this fact by supporting the ability to read custom projections and app settings from an Application Definition if the right elements are present in the root Extension element of the Application Definition.

By registering custom projections in the Application Definitions, we can register custom projections with the viewer without requiring an epsg.io lookup.

The next release of Maestro (the next stop on this tour) will have dedicated editors for specifying custom projections and app settings. So stay tuned to see how this feature can be used.

Modal dialog size/positioning now preserved

The redux state around modal dialogs has been reworked so that size/positioning is now preserved. This means that if you close a modal dialog and re-open it later on, it will retain the previous size/positioning it had previously, as demonstrated in this video.

MapGuide Base Layers now has its own opacity

Previously the opacity of MapGuide Base Layers was coupled to the opacity of the MapGuide Map. With this release, MapGuide Base Layers now has its own opacity setting.

Other Changes

• OpenLayers updated to 6.15.1
• Support disabling custom cursors through a new DISABLE_CURSORS app setting (1 to enable, 0 to disable)
• Fix potential stale legend state from dispatched update action
• Fix epsg.io lookup
• Support Coordinate Tracker with only one projection specified
• Un-break viewer API drawing example
• Restore selection appending while holding down SHIFT key
• Fix viewer state not pushing to url

Download

The "I haven't forgotten about you $PROJECT" tour

As I said near the end of my MGOS 4.0 Beta 1 announcement, I will be momentarily stepping away from MapGuide development/maintenance to give some of my sibling projects in the MapGuide/FDO space some long-overdue attention.

So for the next few weeks, I will be embarking on the "I haven't forgotten about you $PROJECT" tour with stopovers at the following projects:

mapguide-react-layout

Next Release: 0.14.8

Objectives: This will be the last release in the 0.14.x series and the last release to officially support Internet Explorer.

MapGuide Maestro

Next Release: 6.0m12

Primary Objective: This release will have authoring parity with MapGuide Open Source 4.0 Beta 1

Secondary Objective: Assorted fixes and minor enhancements

FDO Toolbox

Next Release: 1.5.3

Objective: Some fixes for bugs and usability problems reported since 1.5.2

mapguide-rest

Next Release: 1.0 RC6

Yes! I am finally giving this project some very-overdue attention!

Primary Objective: Make sure it is compatible with PHP 8.1 that is bundled with MapGuide Open Source 4.0 Beta 1. Also doubles as a secondary sanity test of the new vanilla SWIG-generated PHP bindings, which is my main motivator for revisiting this project.

Secondary Objective: See if we can do this will still being able to support older PHP versions bundled with older MapGuide versions. If this is not tenable, we may need to branch codebases and make separate releases. I hope that this is not the case.

When I finish this tour, then I will be returning to get MapGuide Open Source 4.0 to the final release finish line

Announcing: mapguide-react-layout 0.14.7

This release updates OpenLayers to the latest version 6.13 and includes the following changes/fixes:

• Un-break support for Web Layout resources
• Use DOMPurify to sanitize all possible manually constructed HTML content. DOMPurify is now also the default HTML cleaning function for the selection panel if no custom HTML cleaning function is specified.

The last release was 0.14.5. What happened to 0.14.6?

The 0.14.6 release was pushed shortly before this announcement and was found to carry a vulnerable version of a package (shortid) that we no longer use. This release (0.14.7) was made shortly after to remove this dependency.

Download

Announcing: mapguide-react-layout 0.14.5

 To cap off this year, here's one last release of mapguide-react-layout that includes the following changes:

• OpenLayers updated to 6.10.0
• Fix instability on Firefox due to excessive usage of history APIs for URL state updates
• Allow appdef vector layers to opt-out of automatic hover highlighting

Download

Announcing: mapguide-react-layout 0.14.4

This release improves upon the 0.14.3 release with the following fixes and changes:

• The hover highlighting of vector layer features will now only happen if the active map tool is the select tool.
• Fix viewer init of an appdef with static image layers
• Fix support for Map Definitions using arbitrary coordinate systems whose units are not in meters.
• Fix ability to add GeoJSON layers for some WFS services
• A GeoJSON appdef layer can now source data from a browser global variable
• WFS is now supported as an appdef external layer

Download

Announcing: mapguide-react-layout 0.14.3

This release improves upon the 0.14.2 release with the following changes:

The viewer now supports static images as a subject layer in an application definition JSON document. This allows the viewer to display any arbitrary image, allowing one to display "maps" that have no real-world geographic basis. For example, you can now use the viewer to view the fictional map of Los Santos

Or if fantasy is your thing, maybe a map of Middle Earth

Because static image layers have no real-world geographic basis, it is incompatible with layers and widgets that assume your map is based on a real-world coordinate system, so things such as:

• XYZ, OSM or Bing Maps Layers
• Coordinate Tracker widget

Will not work with static image layers and will be disabled if you load in an appdef document that has a static layer and one or more of these layers/widgets specified. A viewer static image subject layer will also be operating in stateless mode, so all the caveats and limitations of stateless mode also apply.

On the same topic, the viewer now also supports MapGuide Map Definitions based on arbitrary unit coordinate systems. Map Definitions based on arbitrary coordinate systems are typically things like internal building floor plans or maps whose layers are sourced from non-georeferenced CAD drawings. Again, the same limitations as static image subject layers apply (no XYZ/OSM/Bing backdrops, etc, etc)

For this release we've also extracted the layout-template-specific CSS out to their respective stylesheets. This means that the HTML content for all the viewer template files are now 99% identical with the difference being the template stylesheet reference and the template name to init the viewer with.

The HTML is such that you could now conceivably create a server-side wrapper that can generate the viewer HTML for any template given the name of the template to use. This release includes a new optional index.php entry point that pretty much demonstrates this idea. The index.php entry point takes a template query string parameter in addition to all the other query string parameters and will render out the viewer in your chosen template.

This release also fixes the following issues:

• Init warnings now display again on startup
• Transparency is now properly applied for non-MapGuide subject layers

Download

Announcing: mapguide-react-layout 0.14.2

This release improves upon the 0.14 release with the following changes:

A new XYZDebug base layer type is available to view debug tiles with XYZ coordinates

To add a XYZDebug layer, add a XML fragment like the following to your application definition document.

The purpose of this layer is simply to assist in debugging/identifying XYZ tile coordinates relative to the map you're looking at. It's loaded like any other base layer, so you won't see it overlaid on top of your map. To see it you'll need to change the transparency of the main map in the Viewer Options.

The other noticeable change is that the Select tool now has a flag that toggles whether this tool can pan via mouse drag, as demonstrated in this recording below.

This allows mapguide-react-layout to behave more like the simplified web maps like Google Maps instead of GISes where selection and panning are 2 separately distinct functions.

The final change is that the Refresh Map command no longer tries to request an updated MapGuide runtime map layer/group structure when the viewer is in stateless mode.

Download

Announcing: mapguide-react-layout 0.14

And here it is! A new major release of mapguide-react-layout.

The release marks a turning point where the map viewer no longer has a hard dependency on a MapGuide Server to function allowing it to be used in more general purpose contexts that may or may not involve a running MapGuide Server.

Not to mention, a whole lot of new features that have already been covered previously.

Download

mapguide-react-layout dev diary part 26: Making the map viewer general purpose

Previously, I hinted that the future of mapguide-react-layout besides having a new name (I still haven't come up with a suitable replacement on that front) is to make the map viewer general purpose so that it can be used in contexts that do not require a dependency on a running MapGuide Server.

As I am wrapping up development on the upcoming 0.14 release, I figured it's time for a new dev diary entry that details how we have reached this goal. So strap in. This is going to be a big post with images and embedded webms galore!

MapGuide Support is now optional

To make our viewer general purpose, we have to be able to load in an Application Definition where the primary Map element does not refer to a MapGuide Map Definition, but instead refers to what I like to call a "subject layer". The "subject layer" is the layer of focus for any given map and can be:

• A WMS layer
• A vector layer

To demonstrate how truly de-coupled we are from requiring a running MapGuide Server, I present to you a new generic viewer template powered by this example application definition document. All the map groups in that example refer to subject layers instead of MapGuide Map Definitions and thus does not require any dependency on a running MapGuide Server.

New "generic" viewer template

The new "generic" viewer template is a minimal and opinionated viewer template geared for use in a general purpose context (without a MapGuide Server).

The template is opinionated in the following sense:

• The commands in the vertical toolbar is pre-defined. You cannot customize the contents through the application definition. This template does offer a configurable context menu.
• The UI is intentionally kept as minimal as possible. There is no Task Pane in this template. Invoke URL commands will load content into floating modal windows. Certain toolbar commands (like the layer manger and selection panel) will load their UI content into drawers.

Although this template is geared for use in a general purpose context, it still can be used with a MapGuide Server as demonstrated below with the Sheboygan dataset

In the MapGuide context, several extra toolbar buttons are enabled. The toolbar differences are outlined below

Supercharged External Layer Manager

For the upcoming release, the External Layer Manager gets several major enhancements.

Firstly, vector layers now have fully declarative styles with editor support in the External Layer Manager UI. With declarative style support, when adding a new file-based vector layer, you have several choices regarding how the layer is to be added.

You can now choose to create a thematic layer with a pre-defined colorbrewer ramp and optional labeling.

For point-based layers, you may choose to add it as a clustered point layer

Or alternatively, as a heatmap layer

For non-heatmap vector layers, you can view and edit the styles to your liking

General-Purpose-ing various components

There are various components that were previously MapGuide-specfic and would be somewhat pointless in a general purpose context. As some of these components are permanent fixtures in some viewer templates, we have to make them somewhat useful in a non-MapGuide context if said template is fed a non-MapGuide appdef.

The Legend component now also displays the list of external layers in its own root category, essentially acting as a compact version of the layer list from the External Layer Manager UI.

The Selection Panel component will now also display attributes of selected client-side vector features.

UTFGrid support

UTFGrid layer support was introduced in the 1st preview release of MapGuide Open Source 4.0. To better advertise this new feature, the viewer supports UTFGrid layers if specified as part of a MapGroup element in an application definition like so

With this XML fragment in place, loading the appdef into the viewer will cause a UTFGrid interaction layer to be created as part of viewer initialization and will manifest as feature tooltips that display on mouse hover.

There is one caveat with UTFGrid support in mapguide-react-layout. You must pair this up with a Map Definition that is in the WGS84.PseudoMercator (aka. EPSG:3857) coordinate system.

"Stateless" mode for MapGuide maps

UTFGrid layers go nicely with another new feature of mapguide-react-layout: Support for "stateless" mode.

In stateless mode, the viewer:

• Does not create any session ids
• Consequently, it does not issue any CREATERUNTIMEMAP requests on viewer startup
• Will render maps using GETMAPIMAGE instead of GETDYNAMICMAPOVERLAYIMAGE

Because no session id is ever created, the viewer can't use commands that require a SESSION/MAPNAME pair, such as:

• Buffer
• Query
• Theme
• Redline
• Feature Info
• Quick Plot
• Select Within

Such commands if present in the application definition will be permanently disabled in any toolbars and menus where they are referenced in. The viewer will log console warnings about such unsupported commands in stateless mode (as a hint for you to trim out such commands/widgets from your application definition if authoring up a stateless appdef).

Because CREATERUNTIMEMAP requests are not sent in stateless mode, we have a less rich layer/group structure to work with.

Compare the Legend for a stateful version of the Sheboygan map

Versus the stateless version

In the stateless version, we only have the basic layer group structure (computed from the Map Definition resource we fetch on startup) to work with. As a result, we do not have information such as:

• Visible scale ranges for layers
• Style/theme icons for layers

While technically possible, it is currently impractical to fetch all the required Layer Definitions for this information (we would be spamming our MapGuide Server for layer definition requests if loading up a really heavy Map Definition).

Why would you want to use stateless mode? If the caveats listed above are not deal breakers for the type of web map you are trying to serve, stateless mode presents a much more scalable map viewing option in MapGuide as there are zero MapGuide sessions being created or managed, reducing load/memory burden on the MapGuide Server.

Stateless mode is an opt-in feature. You can opt-in to stateless mode by adding a Stateless extension property to the Application Definition like so.

The stateless mode extension property has no effect if your appdef is general-purpose (ie. It does not reference any MapGuide Map Definitions). General-purpose appdefs are implied to be stateless already.

Other notable features/changes

Client-side vector layers are now hover-able (to better hint that they're selectable)

The fusion print command/widget is now supported. You will no longer get an error placeholder in toolbars and menus where this command/widget was referenced. This command will export the current map image out to a separate ready-to-print browser tab.

The previous WMS layer selection tool has been incorporated into the regular Select tool, making it the final one-stop-shop for selecting anything, be it MapGuide layers, WMS layers or client-side vector layers. Also when the Select tool is active, you can now still pan via middle-click mouse drag.

In Closing

Expect the 0.14 release of mapguide-react-layout to come out soon. I am just finishing up documentation aspects of this release.

Announcing: mapguide-react-layout 0.13.3

Was I lying when I said I will be taking a short break from all things open source after releasing MapGuide Open Source 4.0 Preview 3?

Technically speaking, no.

This 0.13.3 release is just a few important fixes made since the 0.13.2 release that actually landed a few months ago, but I haven't "pressed the release button" until now. The fixes are:

• A fix for the initialElementVisibility mount option not working for the Aqua template
• A very important fix for inconsistent layer/group state if refreshing the legend after doing some server-side layer/group changes

This release is browser bundle (viewer.zip) only. There is no npm module release for this. 

Now back to my self-imposed break.

Download

Announcing: mapguide-react-layout 0.13.2

This bugfix release un-breaks MapGuide tiled map support as a result of upgrading OpenLayers, which changed the internal tile coordinate format with the 6.0.0 release.

Download

Announcing: mapguide-react-layout 0.13

Here it is. The last release of mapguide-react-layout in its current form. There will be bugfix releases as required but from this release onwards, mapguide-react-layout will be re-branded as something else, and when I figure out what that will be called, you will find out here first!

Here's the highlights of what's new and changed in this release.

Revamped External Layer Manager

Already showcased in previous dev diary entries, the 0.13 release features a revamped external layer manager allowing you to add external layers from file-based or remote WFS/WMS data sources.

The External Layer Manager also has the following new changes since my dev diary posts.

We've tweaked the WMS select tool to now also display the feature in our client-side selection overlay if the WMS GetFeatureInfo response contains geometry data.

You'll also notice that the WMS feature tooltip is styled differently (to distinguish it from the regular feature tooltip) and is also now also close-able (indicated by the clickable [x])

This WMS Query tool is a separate widget, which you can add to your application by including the following widget definition in your Application Definintion and referencing that widget from a toolbar or menu.

1 2 3 4 5 6 7 8 9 10 11 12

<Widget xsi:type="UiWidgetType"> <Name>WmsQuery</Name> <Type>WmsQuery</Type> <Location /> <Extension /> <ImageUrl>images/icons.png</ImageUrl> <ImageClass>select</ImageClass> <Label>WMS Query</Label> <Tooltip>Click to query for features in WMS layers at the point you click</Tooltip> <StatusText /> <Disabled>false</Disabled> </Widget>

Also for vector layers, you can now style points with image icons through the style editor.

Storybook-based demo

This release is the first one to be showcased in storybook.

Legend Search Filtering

The legend now includes a search box to easily drill down big layer/group structures if you need to rapidly locate a specific layer for toggling. Useful for maps with very large layer/group structures.

Template Changes - Aqua

Thanks to the use of react-rnd, we now finally have resizable dialogs in the Aqua Template!

Template Changes - Other

For all templates, making a map selection will now automatically give focus to the selection panel.

The only exception to this behavior is the sidebar template in mobile view, where rather than automatically flying out a full screen selection panel, we just flash a red indicator over the selection panel toggle to let you know there are selected features to look at.

Removed "Invalid Task Pane" warning

If you work with multi-map configurations, you may have noticed this warning on Task Pane content when switching between maps.

This warning is shown when the passed MAPNAME and SESSION parameters for any loaded URL in the Task Pane does not match the mapname/session of the map you're currently looking at.

Upon further reflection, this warning is overzealous as any Task Pane content that needs to know the actual map name and session id can simply request this information from the viewer APIs in javascript. So this warning has been removed in this release.

SVG icon replacements

Some of the image based icons used by the viewer have been replaced with SVG icon equivalents from the blueprint icon set. This is to enable the possibility of scalable versions of these user interfaces in future releases.

 

Other Changes

There is a whole load of other fixes and minor improvements which you can find in the full 0.13 release notes in the download link below.

Download

mapguide-react-layout dev diary part 25: There is a general purpose map viewer in there.

As I am tidying up the remaining loose ends for the upcoming 0.13 release, I am going to be giving the project a slight re-branding and revised mission statement after this release.

Because although I've touted the mapguide-react-layout project as a "modern map viewer for MapGuide", the fact of the matter is that only a small portion of the viewer codebase concerns integration with the services provided by MapGuide. The rest of the codebase builds on top of the already solid foundations provided OpenLayers, React and TypeScript that can also work with other web mapping servers and services.

I haven't come up with the specifics yet, but my current thoughts so far are:

• This project will be renamed to something else (name TBD)
• The npm package will have a different name. The mapguide-react-layout packages up to 0.13 will still remain on npm, but when the time is right I'll put a deprecation warning on mapguide-react-layout to let you all know about the new package and that you should migrate over to it.
• MapGuide-specific functionality and features of the viewer will be extracted and separated out. How this separation will be done TBD.

With this move, there is potential for some nice cross-pollination:

• I could pivot the vscode-map-preview extension to be based on this viewer (and its kitchen sink of built-in functionality) instead of raw OpenLayers strung together with other libraries and re-creating functionality I already take for granted in mapguide-react-layout.
• I'm parking my static map publishing idea for Maestro because the prospect of having a mapguide-react-layout viewer that need not necessarily have MapGuide Server dependencies is a more attractive proposition to build this idea on top of.
• There's opportunities for adoption of this viewer in other projects where the hard MapGuide Server dependency would've nixed such opportunities.

So when 0.13 finally drops, that will be the end of mapguide-react-layout in its current form. Not because I'm done with the project, but because it's time for this project to evolve.

mapguide-react-layout dev diary part 24: Adding *even* more than just WMS layers

Since I introduced the revamped external layer manager, the creativity floodgates have opened as I have realised that there are many other things that we could implement on top. So for this post, I'm going to cover even more cool things you can do with the revamped external layer manager.

Revised file-loading process

The UI for loading file-based layers has been tweaked a bit. This means that the first step is picking your file as usual. Note that we've changed the "uploader" UI back to a plain blueprint-styled file input due to bundle size budget constraints that required us to drop react-dropzone

After picking the file, we now give you the ability to specify the projection of this file you just picked, which is now a number picker instead of a dropdown. If you enter an EPSG code not known to the viewer, it will now do an epsg.io lookup and register the found projection on-the-fly before adding the vector layer. The design that drives this UI has been refactored to be more modular and flexible, meaning we now can identify the "type" of the file based on the first successful driver to properly parse the file content.

This refactored design also finally allows us to add ...

CSV Support!

When looking at what types of files to support for external vector layers, CSV seemed like a no-brainer to support. Point data is after-all, commonly defined in CSV files.

The problem with CSV files is that there is no established standard as to how point coordinates are defined. The ideal solution would involve having to attempt peek and introspect the file and build the UI to allow picking the correct point coordinate columns. But this UI would complicate our 2-step UI for file-based layers. How would we know the file we're about to add is indeed a CSV file to then be able to present a UI for the user to pick the columns for point coordinate data?

In the interest of pragmatism and avoid having to answer that hard question altogether, our approach is to look for the most common column labels for point coordinates on the first line of the file we encounter:

• X/Y
• Lon/Lat
• Lng/Lat
• Longitude/Latitude
• Easting/Northing

If the file you add has a CSV header and it contains one of the above pairs of columns and the row data referenced by these columns checks out as numbers, it will be accepted as a CSV file.

Added Layers UI Changes

The UI for added layers has been compressed to maximize screen real estate

The opacity slider took up a lot of space (relatively speaking) and toggles a setting I deem to be non-essential to overall functionality, so that slider is now hidden behind a layer options panel (toggled by the new cog icon)

Finally for WMS layers, we now register their source load events so they can contribute to the viewer busy state, meaning that we can properly communicate busy loading state for any added WMS layers.

WMS UI changes

After loading the WMS capabilities URL, for each layer we find you now have the ability to add the WMS layer in as a single-tile or tiled WMS layer.

WFS Support

It seems strange that this external layer manager supports WMS services but does not support the other major W*S service. This was a glaring omission the viewer now addresses. WFS is available as a new layer type:

Added WFS layers are vector layers and assumes the UI of added file-based layers.

Due to viewer bundle size budget constraints the WFS layer UI will only care about layers in the loaded capabilities document that offer GeoJSON output. We could add support for GML2 and GML3 (the formats commonly associated with WFS), but it is not worth blowing up our bundle size to add format drivers for such an esoteric and verbose format.

Select tool support for external layers

So now our revamped external layer manager can add data from a whole assortment of file formats and remote WFS/WMS services. But these data sources are not just for show. They generally have intelligence attached in the form of attribute data for vector data or in the case of WMS layers, APIs to get at such data (WMS GetFeatureInfo), so to put the cherry on top of this revamped external layer manager, the viewer should provide some means of interacting with these layers after adding them.

To this end, our default select tool can now select vector features from external layers and display their attributes in an overlay tooltip.

Vector features take precedence over MapGuide layers. That is to say, the select tool will now try to select vector features first (and display its attributes if found). Only when no vector feature are selected does the viewer proceed with the normal MapGuide layer selection logic.

For WMS layers, we introduce a new active tool dedicated for sending GetFeatureInfo requests against any WMS layers on the current map. The effect is still the same, click on a WMS layer and if we get data back from a WMS GetFeatureInfo response, we'll show the data in a overlay tooltip.

The choice to do WMS "selection" is done through a separate active tool instead of adding on to the default select tool behavior was because adding WMS layer selection logic to the existing select tool would complicate the control flow significantly given that WMS GetFeatureInfo requests are asynchronous and it is hard to maintain a selection priority when dealing with a map that has vector, WMS and MapGuide layers together.

In Closing

The revamped external layer manager is the last major feature for the upcoming 0.13 release. Remaining work before release will primarily be knocking off any remaining bugs and loose ends and also tidying up documentation.

mapguide-react-layout dev diary part 23: Adding more than just WMS layers

In the tail end of part 21, I did say that the next release (0.13) will have some actual new features besides some important under-the-hood updates and for this post we'll be talking about one such feature.

Way back in the 0.11 release, a new component was introduced to allow adding external WMS layers to your current map.

I knew at that point in time that this component had much more room for improvement as the wide array of formats that OpenLayers can support means we can add more than just WMS layers.

For the upcoming 0.13 release we've re-designed and re-built this component to allow adding a wider array of external layers to your map. When you bring up the external layer manager, you are now greeted with a choice of what kind of layer to add:

1. A local file-based layer
2. A remote URL-based layer

With a local file-based layer, simply drag a supported file type into the specified drop-zone or click the drop-zone itself to be prompted for a file to load. Once loaded, specify the projection of the data source (default will be EPSG:4326) and the layer will be added to the map.

Several things to note with local file-based layers.

Firstly, the files you pick are not uploaded to any server. The "upload" UI is merely a means to obtain a HTML5 FileReader so we can load the vector features client-side into the map directly.

Secondly, the following file formats are supported in this mode:

• GeoJSON/TopoJSON
• KML
• GPX
• IGC

Finally, the available projection list in the following dropdown:

Are built-in projections provided by the proj4js library we're using along with any additional projections registered while discovering map definitions or projections registered up-front.

The other mode is remote URL-based layers, which is how you add WMS and WFS layers through this re-designed UI.

UI for adding WFS layers is near identical, so it is not shown here.

Loaded layers can be viewed and managed through the Manage Layers tab, which itself has been re-designed as well.

Every layer in this list:

• Can have their visibility toggled via the switch
• Can have their opacity changed via the slider
• Can have their draw-order (relative to the MapGuide map) changed through the up/down arrow buttons
• Can be removed later on via the button with the trash icon

For WMS layers that support the LegendURL sub-capability, you can click the info button to show the WMS legend inline.

For added vector layers, you can zoom to the extents of that layer.

And for vector layers that aren't KML files, you can edit the style for these features. For KML files, the style is intrinsically part of the file itself, so the style is effectively "locked in" for such layers and is not editable as a result.

So in closing, the revised external layer manager now supports adding the following external data sources to your current map:

• Local files: GeoJSON/TopoJSON, KML, GPX, IGC
• Remote sources: WMS, WFS

We could actually add many more formats, but this revised external layer manager took a significant toll on our production bundle size and adding more formats would've blown up the bundle size to unacceptable levels. This list of formats I have determined to be a "good enough" list given our bundle size constraints.

Thanks to the storybook support, you can also see a live demo of this external layer manager here.