Idea feedback (pre-RFC)

[Steve Lime]

I wanted to add to this reply that the limitation I mention isn't a limitation
at all. It can be done now using the webObj BROWSEFORMAT option to
set the appropriate mime-type.

So, Jan's feature request is already doable...

Steve

>>> On 10/19/2007 at 11:51 AM, in message
<47189A520200008F000106E3 at co5.dnr.state.mn.us>, Steve Lime
<Steve.Lime at DNR.STATE.MN.US> wrote:
> Different problem but it should be possible to handle now since browse 
> templates
> are only one document anyway. There's no reason you can't construct a JSON 
> or
> XML template. I've been doing that for a long time. With clients that manage 
> size
> and extents it's not as useful as it once was but it can be done. Just use 
> mode=browse
> instead of mode=map. The only limitation is that you can't set the browse 
> mode
> mime-type (default is text/html) but that minor in most cases and we could 
> work 
> around it.
> 
> Steve
> 
>>>> Jan Hartmann <j.l.h.hartmann at uva.nl> 10/18/07 10:37 AM >>>
> Not sure if this is the same problem, but could this also include a way 
> to return al MAP-parameters as XML or JSON? Currently, things like 
> mapsize and mapextent are returned via templates, which need an extra 
> template file. I could imagine to get them back directly as XML or JSON. 
> Again, I'm not sure if this is the same as what Steve means, but it 
> would be a nice thing nice to have.
> 
> Jan
> 
> Steve Lime wrote:
>> Hi all: I wanted to float an idea that I been thinking about since the 
> conference and talking about KML related to CGI templates and accessing 
> drivers such as GML and KML (when implemented) when processing query results.
>> 
>> Problem: 1) Currently a driver like GML isn't available to the CGI as a 
> means of presenting query results. 2) The templating scheme 
> (HEADER/TEMPLATE/FOOTER) for queries isn't user friendly nor is it ammenable 
> to multple presentation formats. That is, one layer => one template set.
>> 
>> Solution:
>> 
>> 1) Use output format objects to define formats that can be used to output 
> query results in addition to drawing images. 
>> 
>> E.g. 
>> 
>> OUTPUTFORMAT
>>   NAME 'gml3'
>>   DRIVER GML3
>>   MIMETYPE 'text/xml'
>> END
>> 
>> Might need to extend that object to discriminate between map rendering and 
> query formatters but that can happen in mapdraw.c and mapserv.c too. That is, 
> drivers are explicitly referenced in those places so if someone tries to draw 
> a map with a GML3 driver it would throw an error.
>> 
>> 2) Use the webObj QUERYFORMAT property to reference formats: 'QUERYFORMAT 
> gml3'. Right now that property carries a mime-type but it could be used to 
> reference a format too.
>> 
>> 3) Define a TEMPLATE driver. Basically this would just invoke the normal 
> query templating scheme.
>> 
>> E.g.
>> 
>> OUTPUTFORMAT
>>   NAME 'kml'
>>   DRIVER TEMPLATE
>>   MIMETYPE '...'
>>   FILE 'myTemplate.kml'
>> END
>> 
>> OUTPUTFORMAT
>>   NAME 'geojson'
>>   DRIVER TEMPLATE
>>   MIMETYPE 'text/plain'
>>   FILE 'myTemplate.js'
>> END
>> 
>> 4) Note that in the above examples we reference a file, so I'm thinking of 
> supporing a single template system for queries in addition to the current 
> mechanism. To do this I'd propose 2 new template tags: [layer] and [feature]. 
> These would be blocks. An example might be:
>> 
>> ...old web HEADER content goes here...
>> [layer name=lakes]
>>   ... old layer HEADER stuff goes here, if a layer has no results this block 
> disappears...
>>   [feature]
>>     ...repeat this block for each feature in the result set...
>>   [/feature]
>>   ...old layer FOOTER stuff goes here...
>> [/layer]
>> [layer name=streams]
>>   ... old layer HEADER stuff goes here, if a layer has no results this block 
> disappears...
>>   [feature]
>>     ...repeat this block for each feature in the result set...
>>   [/feature]
>>   ...old layer FOOTER stuff goes here...
>> [/layer]
>> ...old web FOOTER content goes here...
>> 
>> This would allow for relatively complex text files of any sort to be built 
> from multiple layers. All the normal template tags would still be supported 
> but those normally available for query results would only be valid inside a 
> [feature]...[/feature]. These tags would work with existing system too but 
> just wouldn't be as useful as with the 1 template idea.
>> 
>> One gotcha is that by moving the template to the output formatting object we 
> loose our mechanism to mark a layer as queryable, but we've wanted to provide 
> an alternative to that anyway. 
>> 
>> Anyway, I see this as being much more flexible. One could define templates 
> or just access drivers for GeoJSON, KML, Metacarta text files, or whatever 
> with one layer defn and multiple output formats. We could add a parameter to 
> the CGI to change formats easier (as opposed to map.web.queryformat).
>> 
>> Thoughts? If positive I'll write up a detailed RFC.
>> 
>> Steve
>>