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

[Stephen Woodbridge]

Hi Daniel,

I'm not familiar with how the OGC working groups function, but would it 
make sense to contact them directly to give/receive feedback on these 
questions, if you have not already done so. As you and Even point out 
there is definitely a lack of completeness if not clarity on some of 
these points resulting in some divergence on how various groups are 
interpreting /implementing this based on same?

-Steve W

On 3/12/2020 11:20 AM, Daniel Morissette wrote:
> 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
>>
>
>