MapGuide RFC 170 - Tile Service Enhancements (Part 2)

This page contains a change request (RFC) for the MapGuide Open Source project. More MapGuide RFCs can be found on the RFCs page.

Status

RFC Template Version	(1.0)
Submission Date
Last Modified	16 Apr 2019
Author	Jackie Ng
RFC Status	draft
Implementation Status	sandbox in progress
Proposed Milestone	3.3
Assigned PSC guide(s)	(when determined)
Voting History	(vote date)
+1
+0
-0
-1
no vote

Overview

This RFC proposes to build on top of the Tile Service Enhancements introduced in MapGuide Open Source 3.0 with RFC 140

Motivation

RFC 140 introduced the concept of a tile set as a resource (TileSetDefinition) and support for XYZ tile sets.

While the RFC laid down a lot of groundwork, there are some feature gaps, loose ends and cases not considered in the initial implementation that did not make it in the 3.0 release cycle.

This RFC will tie up such loose ends

Proposed Solution

This RFC will tie up the following loose ends:

Ability to create MgMap instances from Map Definitions linked to XYZ tile sets

The initial implementation did not allow an MgMap instance to be created from a Map Definition that links to a TileSetDefinition that uses the XYZ tile provider.

The reason for this was at the time, we didn't know what finite scale list to assign to such a MgMap which is required to properly determine the correct scale index parameter when requesting tiles. A tile set using the Default tile provider would provide this information, yet the XYZ one does not.

In actuality, the finite scale list for an XYZ tile set is actually hard-coded and already known. It is the same scale list generated by Maestro/Infr. Studio for a WGS84.PseudoMercator Map Definition so that it would line up with Google/Bing/OSM layers when viewed within a Fusion Flexible Layout. So by providing this same scale list to the MgMap, we can allow MgMap instances to be created from Map Definitions that link to XYZ tile sets.

Expose tile provider type in CREATERUNTIMEMAP/DESCRIBERUNTIMEMAP

The v3.0.0 CREATERUNTIMEMAP and DESCRIBERUNTIMEMAP schemas did not specify the underlying tile provider name when invoked on a Map Definition that links to a Tile Set Definition. Thus if CREATERUNTIMEMAP was invoked on such a Map Definition, the client does not know what type of tile provider is being used. If a Map Definition links to an XYZ tile set (which will now be a legal scenario as a result of this RFC) we need to communicate this fact back to the client so that it can properly use XYZ tile access semantics instead of normal MapGuide tile access to properly consume tiles from these base layer groups.

We'll introduce a v3.3.0 RuntimeMap schema to include this information.

In the Fusion viewer, if it is known that the XYZ tile provider is being used in the CREATERUNTIMEMAP response, it will create an OpenLayers.Layer.XYZ instance to read such tiles instead of the tiled version of OpenLayers.Layer.MapGuide

Meta-tiling

RFC90 introduced an implementation of meta-tiling. Meta-tiling is the process of rendering a bigger tile and slicing it down into sub-tiles of the original requested size, generally improving tile generation throughput as a result.

However, this implementation has not yet been integrated back into trunk so as a result, it has not surfaced as a feature in any release of MapGuide since the RFC was implemented.

For this RFC, we will take the RFC90 implementation of meta-tiling and retro-fit it into the Tile Set Definition infrastructure.

Meta-tiling support will be surfaced via new tile set parameters:

• MetaTileFactor
• LockMethod

HTTP caching headers

Configurable TileExtentOffset

In addition to meta-tiling parameters, the (previously-global) TileExtentOffset server configuration property is now available as a tileset-specific parameter.

Implications

Test Plan

Funding / Resources

Community