Idea feedback (pre-RFC)

[Kralidis,Tom [Burlington]]

> -----Original Message-----
> From: UMN MapServer Developers List 
> [mailto:MAPSERVER-DEV at LISTS.UMN.EDU] On Behalf Of Steve Lime
> Sent: 18 October, 2007 11:11 AM
> To: MAPSERVER-DEV at LISTS.UMN.EDU
> Subject: [UMN_MAPSERVER-DEV] Idea feedback (pre-RFC)
> 
> 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
> 

Eureka!  This will allow for easy, quick output for those with custom
templates based on profiles or non OGR supported output formats.

> 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.
> 

Depending on where this is used.  E.g. WFS Server: custom output formats
would have to be put forth in Capabilities documents, and supported on
GetFeature requests.  MIME types could be used in interface operations
(i.e. format=text/xml; subtype=geojson/0.0

What about stuff like, say WFS DescribeFeatureType?  Would we allow
templating of that output?  Or is this for pure data fetching?

> 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.
> 

Bring it on!


> Steve
>