This page is part of the MapGuide Future section, where ideas are proposed and refined before being turned into RFCs (or discarded). Visit the Future page to view more!

Overview

This page is a living proposal for improving the scalability of the Tile Service.
Mapguide supports tiled maps via both WMS and it's own Tile Service using GETTILETIMAGE.

Recently support was added in Openlayers & Fusion to access the Tile Service via an API.
​OpenLayers. Layer. MapGuide
​#995 (add support for MapGuide OS layer type) - OpenLayers - Trac

API Ideas

SETTILEIMAGE would allow the tile cache to seeded without needing to have remote access to the server file system.

GETTILEPARAMS would return a list of scale ranges, tile sizes and bounds for a given tile cache.

GETTILECACHE would return a 'map' of the tile cache, listing which tiles exist and which ones haven't yet been created

HAVETILEIMAGE would enable a server to poll another server(s) in the cluster,
returning status codes of 200 ok or 404 Not Found respectively. This allows the server to
check the tile cache without triggering a tile render on the polled server.

These would enable more extensive API based management of a cluster of Mapguide servers, via accurate seeding
and management of the tile caches.

Cacheability by HTTP

MapGuideRfc11 added support for a Stateless Http GETTILEIMAGE request, however, these tiles are served
without any cache headers which means they can only be proxied using a custom 'aggressive' proxy service.

Add proper cache headers & file date to GETTILEIMAGE response.

One of the the issues to be resolved is how long to set the cache headers to cache the tiles before checking back
to the Mapguide Server. This could done with a serverconfig.ini default and then an overriding parameter in the
ResourceHeader.

API additions to MgTileService

To support HTTP cacheability we need to be able to do the following via the MgTileService:

a) Get timestamp information about a generated tile (to be able to apply expiry dates)

b) "Peek" at the timestamp for a tile that may or may not be generated (to be able to compare against dates from if-modified-since headers)

An API addition to MgTileService like the one below should be able to support the above scenarios.

class MG_MAPGUIDE_API MgTileService : MgService
{
PUBLISHED_API:
   /// Returns the timestamp of when the tile for the specified map/group/row/col was generated. Returns NULL if no such tile exists
   ///
   MgDateTime* GetTileCreationDate(MgMap* map, CREFSTRING baseMapLayerGroupName, INT32 tileColumn, INT32 tileRow);

   /// Returns the timestamp of when the tile for the specified map/group/row/col/scale was generated. Returns NULL if no such tile exists
   ///
   MgDateTime* GetTileCreationDate(MgResourceIdentifier* mapDefinition, CREFSTRING baseMapLayerGroupName, INT32 tileColumn, INT32 tileRow, INT32 scaleIndex);

   /// Returns the specified base map tile for the given map.  If a cached tile
   /// image exists it will return it, otherwise the tile is rendered and added
   /// to the cache.
   MgTile* GetTile(MgMap* map, CREFSTRING baseMapLayerGroupName, INT32 tileColumn, INT32 tileRow);

   /// Returns the specified base map tile for the given map.  If a cached tile
   /// image exists it will return it, otherwise the tile is rendered and added
   /// to the cache.
   ///
   MgTile* GetTile(MgResourceIdentifier* mapDefinition, CREFSTRING baseMapLayerGroupName, INT32 tileColumn, INT32 tileRow, INT32 scaleIndex);
};

MgTile is defined like so.

class MG_MAPGUIDE_API MgTile : public MgSerializable
{
PUBLISHED_API:
    /// Returns the tile image
    ///
    MgByteReader* GetImage();

    /// Returns the date this tile was created
    ///
    MgDateTime* GetCreationDate();
};

MapAgent modifications

These API changes do not really affect the mapagent interface. From a calling client's perspective, they should still be able to send v1.2.0 GETTILEIMAGE requests with the same parameters and take advantage of HTTP caching behind the scenes. Behind the scenes the GETTILEIMAGE operation handler simply needs to check for the existence of a "If-Modified-Since" request header to take on a new code path.

A rough pseudocode overview of this process would be

if (ifModifiedSince header exists) {
    extract date from header
    call GetTileCreationDate
    if (tileCreationDate != NULL) {
        if (tileCreationDate is newer than header date) {
            call new GetTile
            write image from MgTile into result
            write date from MgTile into last modified response header
            write expires date a long period from that date (6 months? 1 year?)
        } else {
            set status code of 304. Write nothing into the result. Outer CGI/Apache/ISAPI handler is expected to handle this and write out the appropriate responses (see below)
        }        
    } else {
        call new GetTile
        write image from MgTile into result
        write date from MgTile into last modified response header
        write expires date a long period from that date (6 months? 1 year?)
    }
} else {
    call new GetTile
    write image from MgTile into result
    write date from MgTile into last modified response header
    write expires date a long period from that date (6 months? 1 year?)    
}

In our applicable CGI/Apache/ISAPI handlers, their additional responsibilities are to:

• Pack any HTTP request headers into the request metadata of the MgHttpRequest before executing it. In the case of this API, look for if-modified-since
• Handle the 304 internal status and write out any applicable response headers from the MgHttpResult that operations supporting HTTP cacheability (ie. The GETTILEIMAGE) should provide.

MgHttpRequestMetadata and MgHttpHeader classes are not currently used in any of the existing CGI/Apache/ISAPI handlers. We should use them for this purpose.

WMS

WMS Cache headers - see above.

Publish MapDefinitions via WMS Currently only layers are exposed via WMS, maps could be as well.

The WMS service doesn't currently use the tile cache, which means every WMS request is rendered.

Linking the WMS service up to utilize the tile cache would dramatically improve the performance
and capacity of WMS with Mapguide.

TMS

TMS