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

[Rushforth, Peter (NRCan/RNCan)]

> > (not WMS): there's a Operation name="GetMapML" in the output of
> > https://demo.cubewerx.com/cubewerx/cubeserv/simple?
> > SERVICE=WMTS&REQUEST=GetCapabilities

In GeoServer, we didn't implement a GetMapML extension, we just added access to MapML documents at a set of URLs (one per 'projection' available), and provide a link in the admin interface to one of them.  The MapML document refers to tiles (GetTile URLs) or images (GetMap URLs) depending on whether the administrator has checked the "Use Tiles" MapML option and also on if the administrator has configured GeoWebCache tile caching for the layer/ layer group.

A "GetMapML" response could be similar to one of the GeoServer MapML urls.

I would say that a GetMapML extension might be the right W*S way of providing MapML, but I / we didn't (want to) get into what parameters would be required, so that's probably something the OGC might be interested in discussing and adding.  If there's an existing extension mechanism for all that, maybe that's the right thing to use?  

In GeoServer, we do list "text/mapml" as an available info format, both in the WMS and WMTS capabilities response.  You just have to "know" what the URL to get the MapML from is, so we provide a "MapML" link in the Layer Preview grid to one of the projections supported, and in that document the alternate projection links are listed, so the client can pick the one that works for the map that is being displayed, if any.  For WFS, in GeoServer, it's not consistent with the WMS and WMTS capabilities, because we only list "MAPML" as an outputFormat value, which means nothing really. i.e. GeoServer's WFS capabilities needs some attention from the MapML module.


Thanks,
Peter


Peter Rushforth

Technology Advisor
Canada Centre for Mapping and Earth Observation 
Natural Resources Canada / Government of Canada
peter.rushforth at canada.ca / Tel: 613-759-7915

Conseiller technique
Centre canadien de cartographie et d’observation de la Terre 
Ressources naturelles Canada / Gouvernement du Canada
peter.rushforth at canada.ca / Tél: 613-759-7915


> -----Original Message-----
> From: mapserver-dev <mapserver-dev-bounces at lists.osgeo.org> On Behalf Of
> Daniel Morissette
> Sent: March 12, 2020 11:20 AM
> To: mapserver-dev at lists.osgeo.org
> Subject: Re: [mapserver-dev] MS-RFC-123: Support for MapML output in
> MapServer
> 
> 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
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-dev