[mapserver-dev] MS-RFC-123: Support for MapML output in MapServer

[Even Rouault]

Hi Daniel,

>   https://mapserver.org/development/rfc/ms-rfc-123.html

Regarding REQUEST=GetMapML, the RFC mentions that this is an extended request 
of the WMS service. But none of the examples/text where it is used have 
SERVICE=WMS parameter. I guess this is needed.

I was wondering if the Vendor-specific GetMapML Request was a MapServer 
specific thing of a MapML thing. According to
https://docs.ogc.org/per/17-019.html (if that doc is still current), it might 
be a more generic MapML thing. But the parameters for the request they give 
there in table 4 and 5 seem a bit different than the one you suggest.
Grepping getmapml through GeoServer code base doesn't show any occurence
https://github.com/geoserver/geoserver/search?q=getmapml
whereas looking just for mapml does. Hence my confusion.
And it seems that Cubewerx has implemented a GetMapML request as part of WMTS 
(not WMS): there's a Operation name="GetMapML" in the output of
https://demo.cubewerx.com/cubewerx/cubeserv/simple?
SERVICE=WMTS&REQUEST=GetCapabilities

Wondering if there's something in the GetCapabilities of WMS planned to 
advertize the availability of the GetMapML request ? (if that's possible to 
extend the response of GetCapabilities in a standard compliant way)
==> Answering to myself, https://docs.ogc.org/per/17-019.html mentions
"If this proposal is accepted by the MapML community as a service that 
generates MapML files, it will be necessary to consider what concrete changes 
are needed to be done in the GetCapabilities response to expose the 
possibility of having GetMapML requests"


Regarding "The text/mapml feature collection output format in response to WMS 
GetFeatureinfo and WFS GetFeature requests will be generated via a new OGR 
<mapml> output driver.", if that's the route actually followed, perhaps the 
RFC should mention clearly (in "4. Limitations / caveats", or in a 
"Requirements" paragraph) that this part will be dependent on running 
Mapserver against a GDAL version with that driver.
I guess an alternative could be to leverage the MapServer template mechanism 
to drive the generation of the <mapml> element (but I'm not an expert of this, 
although I think it can do quite powerful things)

Regarding -DWITH_MAPML=1 switch, I was wondering if making it available 
unconditionally (or at least with the same conditions of WITH_WMS / WITH_WFS) 
wouldn't make things simpler. Additional build switches increase the number of 
configurations that should potentially be tested, and we generally only test 
one in CI, and as what is not tested should be assumed to be broken unless 
otherwise proven (as was found with non-GDAL and non-PROJ build)... :-) But 
this is a minor point.

I assume msautotest will be extended to trigger the new code paths ?

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com