Version 5 (modified by 6 years ago) ( diff ) | ,
---|
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.
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)
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