The GeoServer MapML extension is implemented as a custom Spring MVC controller that implements two main methods at one URL end point. The MVC controller end point is currently found at:
Where the /mapml step represents the controller base and the /topp:states represents the layer name and /osmtile denotes the MapML (custom) TCRS.
The first method, expected to be executed by default when the above URL end point is accessed by a Web browser, returns a text/html media type as its response (because the browser negotiates for this format). This method serializes a default MapML client Web page that embeds the custom element, JavaScript, and CSS resources required to initiate a mapping application on the browser. When the HTML response is loaded by the browser, the embedded custom mapping element code will request the exact same URL from the GeoServer MapML API, but the custom application will negotiate that the URL response be returned with the text/mapml content / media type. This request is mapped to the second method in the controller, one which is coded to return the MapML document representing a single layer or layer group. Detailed custom logic is embedded in this method, and it is this logic that is to be refactored and repurposed in the form of standard GetMap-based WMS operation with the format=text/mapml parameter.
Requirement
Migrate the MapML MVC controller functionality to GetMap-based service access. Upgrade dependencies as required. Refactor the implementations of Spring MVC Controller methods as GetMap-based access. Define a (new) “application/mapml” WMS format parameter value, like the existing “application/openlayers” WMS format parameter value (which responds with "text/html; subtype=openlayers"), that is used by the GeoServer GetMap layer/layergroup “OpenLayers” preview link today. Replace the “MapML” Layer Preview screen link that is displayed by the MapML extension, with a link to a GetMap request with the “application/mapml” format parameter value, which will return an HTML page with a MapML JavaScript client application built-in (again, like how the “OpenLayers” preview link works with a Content-type: text/html response header). Define “text/mapml” as a standard response content type available for GetMap and GetFeatureInfo requests (the latter already exists).
For GetMap requests that refer to a single layer or layer group, the existing REST controller methods provide good exemplars of the logic required to serialize MapML for single layer requests. Tests exist which validate that the content of the MapML document as serialized reflects expectations (although they don’t “validate” the document according to an XML schema). It is a requirement that these tests be refactored to support equivalent single layer/layer group GetMap requests.
Additionally, since standard GetMap supports a comma-separated list of layers/layer groups and a parallel comma-separated list of styles to apply to those layers, GeoServer should be extended by this requirement to support MapML format responses for multi-layer, multi-style requests. A global GeoServer MapML Publishing panel option in GeoServer's WMS Settings page should allow the administrator to select how layers or layer groups should be represented in a multi-layer request. There should be two options available: 1) as a single element in which the template value contains comma-separated lists of layers/layer groups and styles (the default, unchecked value), respectively, or 2) as multiple, independent elements, one per layer or layer group in the request list.
Background
The GeoServer MapML extension is implemented as a custom Spring MVC controller that implements two main methods at one URL end point. The MVC controller end point is currently found at:
https://example.org/geoserver/mapml/topp:states/osmtile/
Where the /mapml step represents the controller base and the /topp:states represents the layer name and /osmtile denotes the MapML (custom) TCRS.
The first method, expected to be executed by default when the above URL end point is accessed by a Web browser, returns a
text/htmlmedia type as its response (because the browser negotiates for this format). This method serializes a default MapML client Web page that embeds the custom element, JavaScript, and CSS resources required to initiate a mapping application on the browser. When the HTML response is loaded by the browser, the embedded custom mapping element code will request the exact same URL from the GeoServer MapML API, but the custom application will negotiate that the URL response be returned with thetext/mapmlcontent / media type. This request is mapped to the second method in the controller, one which is coded to return the MapML document representing a single layer or layer group. Detailed custom logic is embedded in this method, and it is this logic that is to be refactored and repurposed in the form of standard GetMap-based WMS operation with the format=text/mapml parameter.Requirement
Migrate the MapML MVC controller functionality to GetMap-based service access. Upgrade dependencies as required. Refactor the implementations of Spring MVC Controller methods as GetMap-based access. Define a (new) “application/mapml” WMS format parameter value, like the existing “application/openlayers” WMS format parameter value (which responds with "text/html; subtype=openlayers"), that is used by the GeoServer GetMap layer/layergroup “OpenLayers” preview link today. Replace the “MapML” Layer Preview screen link that is displayed by the MapML extension, with a link to a GetMap request with the “application/mapml” format parameter value, which will return an HTML page with a MapML JavaScript client application built-in (again, like how the “OpenLayers” preview link works with a Content-type: text/html response header). Define “text/mapml” as a standard response content type available for GetMap and GetFeatureInfo requests (the latter already exists).
For GetMap requests that refer to a single layer or layer group, the existing REST controller methods provide good exemplars of the logic required to serialize MapML for single layer requests. Tests exist which validate that the content of the MapML document as serialized reflects expectations (although they don’t “validate” the document according to an XML schema). It is a requirement that these tests be refactored to support equivalent single layer/layer group GetMap requests.
Additionally, since standard GetMap supports a comma-separated list of layers/layer groups and a parallel comma-separated list of styles to apply to those layers, GeoServer should be extended by this requirement to support MapML format responses for multi-layer, multi-style requests. A global GeoServer MapML Publishing panel option in GeoServer's WMS Settings page should allow the administrator to select how layers or layer groups should be represented in a multi-layer request. There should be two options available: 1) as a single element in which the template value contains comma-separated lists of layers/layer groups and styles (the default, unchecked value), respectively, or 2) as multiple, independent elements, one per layer or layer group in the request list.