At the moment, Context just describes the "Data" for a Map display,
not the Presentation.
Mapbuilder has separated the two concepts by using Context to describe:
* A list of layers
* Bounding Box
And then a Mapbuilder Config file which lists the widgets to display:
* MapPane
* Legend
* Zoom buttons etc.
The Mapbuilder Config.xml file could be put forward as a standard, but
I see there being significant effort involved in standardizing the
less common widgets due all the possibilities, and I'm not sure it
gains enough to be worth the effort. ... Not yet anyway.
On Nov 26, 2007 2:29 PM, Jody Garnett <jgarnett@anonymised.com> wrote:
Chris Holmes wrote:
> I actually like this idea a lot, I hadn't been as convinced in the
> past, but I've heard some compelling use cases. Does a context
> document have information about scale bars and legends and the like?
Actually Chris that is why we started up the "osgeo-standards" email
list - to try and set up a venue to hack on concepts like this "across
project"; and then let the standards organizations pick up the parts
they like after the fact. So far we have gotten extensibility added at
the layer level (so we can start to add scalebars and shapefiles and
other things that are not OGC web services), we are going to just sort
things out by convention for a bit and use a wiki to track the best of
breed (much like open street maps does for their feature models).
Check back in several months and see how it works out.
> And even further, does it have anything to say about placement of
> those on a map? I know that people are going to start to want that
> kind of control, you give these users an inch and they ask for a mile
> But seriously, this starts to take us down the path of fully
> composing lay out for the output, is context document sufficient?
See above; we will make it do what we need. Initially the "mile"
requested as a cross project configuration (basically asking GeoServer
to configure itself based on one of these things). Another interesting
idea but one that can be better handled without all the view port model
over head provided in a context document.
Cheers,
Jody
>
> Chris
>
> Cameron Shorter wrote:
>> Yes Jody, I like the name "Context Portrayal Service" which is a
>> semi-regular request on the Mapbuilder list. Or rather, people ask to
>> print their maps they created in a web browser and find they run into
>> browser limitations that could be solved by a Context Portrayal Service.
>>
>> I'd suspect that a Context Portral Service could relatively easily be
>> built from geotools components and it would make sense to bundle it
>> into the Geserver functionality.
>>
>> Jody Garnett wrote:
>>> It is not really the job of GeoServer to support a context document
>>> right? That is something that a client application would use to
>>> configure itself to display the indicated scene. It may be that all
>>> the information comes from a single GeoServer install (or from
>>> several open web services); but that matter is up to the client
>>> application.
>>>
>>> Now you could make a new open web service (context portrayal
>>> service) that just makes use of geoserver to to compose the image
>>> from several sources); something similar was done for feature
>>> portrayal service in the past. I am not sure if this is a useful
>>> workflow or not ...
>>>
>>> Jody
>>>
>>>> Can Geoserver render a map image from a Web Map Context or OWS
>>>> Context document?
>>>>
>>>> This would be very useful to browser clients which have problems
>>>> with some browsers printing (to paper) more than one layer.
>>>> To support this properly, Geoserver would need to support cascading
>>>> WMS and WFS so that it can access all the layers in the Context.
>>>>
>>>> I'm guessing that UDig would have much of the functionality required?
>>>>
>>>
>>
>>
--
Cameron Shorter
Geospatial Systems Architect
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254
Think Globally, Fix Locally
Commercial Support for Geospatial Open Source Solutions
http://www.lisasoft.com/LISAsoft/SupportedProducts.html