Idea feedback (pre-RFC)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Idea feedback (pre-RFC)

Steve Lime
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
Reply | Threaded
Open this post in threaded view
|

Re: Idea feedback (pre-RFC)

Kralidis,Tom [Ontario]
 

> -----Original Message-----
> From: UMN MapServer Developers List
> [mailto:[hidden email]] On Behalf Of Steve Lime
> Sent: 18 October, 2007 11:11 AM
> To: [hidden email]
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: Idea feedback (pre-RFC)

Jan Hartmann
In reply to this post by Steve Lime
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
>
Reply | Threaded
Open this post in threaded view
|

Re: Idea feedback (pre-RFC)

Steve Lime
In reply to this post by Steve Lime
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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: 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
<[hidden email]>, Steve Lime
<[hidden email]> 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 <[hidden email]> 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
>>