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

Daniel Morissette dmorissette at mapgears.com
Thu Mar 12 08:20:11 PDT 2020


Hi Even,

Thank you very much (really) for your thorough review. I was not aware 
of the OGC ER at https://docs.ogc.org/per/17-019.html and based on a 
quick browse it discusses several questions to which I had found no 
answer in the more abstract spec documents from the W3C working group on 
which my work was based so far. One of those questions was exactly about 
the handling of a GetMapML request which is discussed in the document 
you sent but is not discussed AFAIK in the W3C documents. (And in the 
GeoServer case I believe they use the HTTP Accept headers to fetch the 
<mapml> response which is not something that MapServer currently does.)

I will review this OGC document and update the RFC to address your 
questions/feedback.

Thanks

Daniel


On 2020-03-12 09:12, Even Rouault wrote:
> 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
> 


-- 
Daniel Morissette
Mapgears Inc
T: +1 418-696-5056 #201


More information about the mapserver-dev mailing list