[Geoserver-devel] Rendering a Context document from Geoserver?

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

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?

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

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 see; so something like ... set up a community/cps module, make it available as an optional download for geoserver, have people install the optional download, and then from mapbuild send the CPS the context document representing the current screen and ask for it to be rendered as a high quality PDF.

That could work; it is not a bad story. Note you could probably fake this as a WPS since that specification is so generic.

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.

Try and keep it at arms length, as a community module. The definition of new services using GeoServer as a scaffolding is to be encouraged :slight_smile:

I should note that I am generally uncomfortable with the whole genre of WPS where we expect GeoServer to on the fly connect to services it has never seen before (as an example inline GML, and inline wfs layers defined in an SLD document give me the same hesitations).

Best of luck,
Jody

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?

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? 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 :wink: But seriously, this starts to take us down the path of fully composing lay out for the output, is context document sufficient?

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?

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 :wink: 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?

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
> :wink: 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

As quoted from Chris Holmes <cholmes@anonymised.com>:

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?

No, those are separate (in MapBuilder they are widgets in the config).
There is nothing in either the WMC or the current OWSContext specs that
does that kind of thing as far as I'm aware. Neither for e.g. overview
maps overlaid on top of the main map.

And even further, does it have anything to say about placement of
those on a map?

No.

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 :wink:

Oh sure, users will start to want a printout that looks exactly like
what they have on their screen.

But seriously, this starts to take us down the path of fully composing
lay out for the output, is context document sufficient?

Not currently.

Regards,
--
-- Gertjan van Oosten, gertjan@anonymised.com, West Consulting B.V., +31 15 2191 600