Call for comments - RFC 36

Steve Lime Steve.Lime at DNR.STATE.MN.US
Mon Nov 5 14:05:08 EST 2007

Comments inline... Steve

>>> On 11/2/2007 at 2:14 PM, in message
<AC5C8D744B56174DB5AE2F3D1A18623F015292C7 at>, "Doyon,
Jean-Francois" <jdoyon at NRCAN.GC.CA> wrote:
> Am I understanding correctly that associating a template with a layer
> would no longer happen, but instead the template would be associated
> with a given outputformat?  Does this force the idea of a single
> template per map per format?

Actually you could do either. If the user requests a format (via QUERYFORMAT) that
references an OUTPUTFORMAT then the template (if DRIVER equals TEMPLATE) associated
with that format is used. It's possible that the format has a non-templated output producer
(like GML2/3 or soon KML) too. If the QUERYFORMAT doesn't reference a format object
then we'd fall back to the current setup.

> We have thousands of query templates (a common head and footer, and one
> per queryable layer, with many layers per map, and hundreds of maps, and
> 2 languages), so I'm defintiely interested in this topic :P
> This would be nice because it'd help consolidate query templates into
> fewer files, and more logically per map, as well as allowing multiple
> output formats.
> Have there been any thoughts of adding a cgi parameter to control query
> output format? Or would I use the map_web_queryformat notation? Just a
> thought.

I've thought about it, but figured at this point we'd just expose configuration via
the notation you mention.

> Also, is QUERYFORMAT completely new? It's in webObj, but not mentionned
> in the mapfile reference.

It's 4.8 I think? Another documentation bug, I'll file...

> For me the importance would be to try and minimize the impact on the
> exiting templates and language.  If I can just take existing templates
> and merge them into one with a few extra tokens like [resultset] wrapped
> around, then that's not too bad, not fun, but it's all in the name of
> progress :)

You wouldn't have to merge 'em but it sounds like that would make your life
easier in the long run.

> Also, I don't think I'm seeing anything here that precludes keeping both
> HEADER/LAYER/FOOTER).  Might be good to have a bit of overlap where both
> mechanisms exist for a while and then the old way is phased out later?

Overlap was already planned for...

> J.F.
> -----Original Message-----
> From: UMN MapServer Developers List [mailto:MAPSERVER-DEV at LISTS.UMN.EDU] 
> On Behalf Of Steve Lime
> Sent: November 1, 2007 15:09
> Subject: [UMN_MAPSERVER-DEV] Call for comments - RFC 36
> Hi all: I (with the help of Tom K.) put together an RFC outlining better
> template support for queries via the CGI interface.  Please take a look
> at:
> Steve

More information about the mapserver-dev mailing list