Changes between Version 4 and Version 5 of MapGuideRfc170

Timestamp:

05/21/19 04:20:12 (6 years ago)

Author:

jng

Comment:

--

MapGuideRfc170

@@ -45 +45 @@
 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 ===
 
@@ -202 +194 @@
 Meta-tiling has no effect for tile formats that are not image-based (eg. UTFGrid)
 
-=== HTTP caching headers ===
-
 == Implications ==