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

Configurable TileExtentOffset

The (previously-global) TileExtentOffset server configuration property is now available as a tileset-specific parameter.

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 new Tile Set Definition infrastructure.

Firstly, we will add new RenderTile and RenderTileXYZ primitives that accept a meta-tiling factor:

class MG_MAPGUIDE_API MgRenderingService : public MgService
{
...
EXTERNAL_API:
    /////////////////////////////////////////////////////////////////
    /// \brief
    /// Returns the specified base map tile for the given map.
    ///
    /// \remarks
    /// This method only renders the given tile. No tile caching is performed
    /// by this method. To render and cache the tile, use the 
    /// \link MgTileService::GetTile GetTile \endlink method instead. However,
    /// using that method will use default tile width/height/dpi/format specified
    /// in your MapGuide Server configuration
    ///
    /// \param map
    /// Input
    /// map object containing current state of map.
    /// \param baseMapLayerGroupName
    /// Input
    /// Specifies the name of the baseMapLayerGroup for which to render the tile.
    /// \param tileColumn
    /// Input
    /// Specifies the column index of the tile to return.
    /// \param tileRow
    /// Input
    /// Specifies the row index of the tile to return.
    /// \param tileWidth
    /// Input
    /// Specifies the width of the tile to return.
    /// \param tileHeight
    /// Input
    /// Specifies the height of the tile to return.
    /// \param tileDpi
    /// Input
    /// Specifies the dpi the tile to return.
    /// \param tileImageFormat
    /// Input
    /// Specifies the image format of the tile. See \link MgImageFormats \endlink
    /// \param tileExtentOffset
    /// Input
    /// Specifies the ratio by which the tile to be rendered should be "buffered out". The tile will be rendered at the specified width
    /// multiplied by the given ratio, which will be cropped back to the original requested size after rendering. This is to improve
    /// label placement on rendered tiles by giving extra "breathing space" to label placement algorithms.
    /// \param metaTilingFactor
    /// Input
    /// The meta-tiling factor, If less than or equal to 1 no meta-tiling is done. If greater than 1, a tile m times the original requested
    /// size is rendered instead (where m is the specified factor)
    ///
    /// \return
    /// A byte reader containing the rendered tile image. If metaTilingFactor is greater than 1, then a raw image frame buffer is returned 
    /// instead. This raw image frame buffer is not intended to be used by MapGuide applications and is reserved for the rendering infrastructre
    /// to sub-divide back into tiles of the original requested size.
    ///
    /// \since 3.3
    virtual MgByteReader* RenderTile(
        MgMap* map,
        CREFSTRING baseMapLayerGroupName,
        INT32 tileColumn,
        INT32 tileRow,
        INT32 tileWidth,
        INT32 tileHeight,
        INT32 tileDpi,
        CREFSTRING tileImageFormat,
        double tileExtentOffset,
        INT32 metaTileFactor) = 0;

    /////////////////////////////////////////////////////////////////
    /// \brief
    /// Returns the specified map tile for the given map. Tile structure is
    /// based on the XYZ tiling scheme used by Google Maps, OpenStreetMap, and
    /// others
    ///
    /// \param map
    /// Input
    /// map object containing current state of map.
    /// \param baseMapLayerGroupName
    /// Input
    /// Specifies the name of the baseMapLayerGroup for which to render the tile.
    /// \param x
    /// Input
    /// Specifies the row index of the tile to return.
    /// \param y
    /// Input
    /// Specifies the column index of the tile to return.
    /// \param z
    /// Input
    /// Specifies the zoom level of the tile to return.
    /// \param dpi
    /// Input
    /// Specifies the dpi of the tile to return.
    /// \param tileImageFormat
    /// Input
    /// Specifies the image format of the tile to return.
    /// \param tileExtentOffset
    /// Input
    /// Specifies the ratio by which the tile to be rendered should be "buffered out". The tile will be rendered at the specified width
    /// multiplied by the given ratio, which will be cropped back to the original requested size after rendering. This is to improve
    /// label placement on rendered tiles by giving extra "breathing space" to label placement algorithms.
    /// \param metaTilingFactor
    /// Input
    /// The meta-tiling factor, If less than or equal to 1 no meta-tiling is done. If greater than 1, a tile m times the original requested
    /// size is rendered instead (where m is the specified factor)
    ///
    /// \return
    /// A byte reader containing the rendered tile image. If metaTilingFactor is greater than 1, then a raw image frame buffer is returned 
    /// instead. This raw image frame buffer is not intended to be used by MapGuide applications and is reserved for the rendering infrastructre
    /// to sub-divide back into tiles of the original requested size.
    ///
    /// \since 3.3
    virtual MgByteReader* RenderTileXYZ(
        MgMap* map,
        CREFSTRING baseMapLayerGroupName,
        INT32 x,
        INT32 y,
        INT32 z,
        INT32 dpi,
        CREFSTRING tileImageFormat,
        double tileExtentOffset,
        INT32 metaTilingFactor) = 0;
};

These new overloads are designated EXTERNAL_API because meta-tiles are not intended to be consumed by regular MapGuide applications. They are raw image frame buffers that the rendering infrastructure will use to sub-divide back into tiles of the original requested size. But at the same time, these overloads have to be present in the MgRenderingService contract to allow a server-based tile service to still request meta-tiles through a proxy instance (should a server-based instance not be available) hence the EXTERNAL_API designation.

If applications do take advantage of these new overloads, it is expected they will always pass a metaTilingFactor of 0 when calling these new overloads or they know how to process and sub-divide the raw image frame buffer back into tile images of the original tile size.

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

• MetaTileFactor
• LockMethod

Meta-tiling has no effect for tile formats that are not image-based (eg. UTFGrid)

HTTP caching headers

Implications

Tiles generated through meta-tiling may have subtle differences in label placement due to being "cut" from a parent tile that is x times bigger (where x = meta-tiling factor), thus affording the tile renderer more "breathing space" in determining optimal label placement for applicable features that a regular tile would not have.

Test Plan

Add unit tests to render meta-tiles and also render baseline regular tiles for comparison. With the exception of subtle differences in label placement, verify that the tiles cut from meta-tiles are visually the same as regular tiles (esp. Line/Polygon features)

Funding / Resources

Community