[Geoserver-devel] First WMS cascading patch ready

Hi,
during the last few days I've been working on implementing
WMS cascading for GeoServer trunk.

The first patch is ready and attached to http://jira.codehaus.org/browse/GEOS-623.

I'm going to make a formal GSIP tomorrow, but in the meantime
allow me to share a few screenshots of the work and a brief
description.

Once patched the GUI allows to create a new "WMS store" by
providing a capabilities link. After that we get to the usual
layer listing, and then to the usual layer configuration
page.

The layer config page metadata are filled using the values
found in the cascaded WMS capabilities document, including
bounds, srs, descriptions, keywords and whatnot.
The only visible difference compared to a normal layer config
page is that you don't have a style chooser, since cascading
works, at this point, by simply using the default style.

The preview shows the cascaded layers with their own icon
(thanks Rollie for being prevident and preparing WMS layer
icons as well), and you can then follow and browse the
cascaded maps as if they were local.

Functionality implemented in the GetMap cascading:
- standard cascading
- reprojected cascading, trying to pass down to the remote
   server the destination SRS when possible, reprojecting
   on the client when not possible (see the EPSG:900913
   reprojection screenshot, looks nice because the srs
   was passed down)
- request merging, if n consequent layers are cascaded
   from the same server a single GetMap will be issued
- the WebMapServer instance is cached at the ResourcePool
   level making sure we don't do too many GetCapabilities
   requests (caching the WebMapServer object results in
   the caching of the GetCapabilities response)

I've also implemented GetFeatureInfo cascading for the
case in which the remote server supports GML2 output
This has been tested against GS only, could not find
a MapServer instance that actually does GML output,
often it's listed in the caps but results to the request are
consistently empty.
GetFeatureInfo cascading works also in the reprojected
case.

What's missing? Well, I guess it's enough for the first
cut (the sponsored one), though of course we can do better
a number of things:

- add support for alternate styles
- allow the admin to specify a timeout (right now it's
   hard coded)
- full support in Restconfig (we need to add new resources
   there)
- improve the GeoTools client code so that we can use
   HTTP 1.1 persistent connections and limit the number
   of parallel connections we make to a single server
   (right now GS is badly behaved from an HTTP client
    point of view).
- allow the user to choose the format used for cascading.
   Now we try png
- maybe add a pure proxy mode, if the request contains
   only cascaded layers avoid decoding the image to just
   re-encode it afterwards
- add support for WMS with access restrictions (this is
   really just a matter of configuration, the gt2 module
   does that already)
- support cascaded layers in GetMap requests that use
   &SLD and &SLD_BODY

Anyone interested in picking up from the above list? :wink:

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

(attachments)

wms_cascaded_featureinfo-nq8.png
wms_layer_preview-nq8.png
wms_layer_properties-nq8.png
wms_new_store-nq8.png
wms_reprojected-nq8.png
wms_store_list-nq8.png

Nice work.

Simone.
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

-------------------------------------------------------

On Tue, May 4, 2010 at 7:53 PM, Andrea Aime <aaime@anonymised.com> wrote:

Hi,
during the last few days I've been working on implementing
WMS cascading for GeoServer trunk.

The first patch is ready and attached to
http://jira.codehaus.org/browse/GEOS-623.

I'm going to make a formal GSIP tomorrow, but in the meantime
allow me to share a few screenshots of the work and a brief
description.

Once patched the GUI allows to create a new "WMS store" by
providing a capabilities link. After that we get to the usual
layer listing, and then to the usual layer configuration
page.

The layer config page metadata are filled using the values
found in the cascaded WMS capabilities document, including
bounds, srs, descriptions, keywords and whatnot.
The only visible difference compared to a normal layer config
page is that you don't have a style chooser, since cascading
works, at this point, by simply using the default style.

The preview shows the cascaded layers with their own icon
(thanks Rollie for being prevident and preparing WMS layer
icons as well), and you can then follow and browse the
cascaded maps as if they were local.

Functionality implemented in the GetMap cascading:
- standard cascading
- reprojected cascading, trying to pass down to the remote
server the destination SRS when possible, reprojecting
on the client when not possible (see the EPSG:900913
reprojection screenshot, looks nice because the srs
was passed down)
- request merging, if n consequent layers are cascaded
from the same server a single GetMap will be issued
- the WebMapServer instance is cached at the ResourcePool
level making sure we don't do too many GetCapabilities
requests (caching the WebMapServer object results in
the caching of the GetCapabilities response)

I've also implemented GetFeatureInfo cascading for the
case in which the remote server supports GML2 output
This has been tested against GS only, could not find
a MapServer instance that actually does GML output,
often it's listed in the caps but results to the request are
consistently empty.
GetFeatureInfo cascading works also in the reprojected
case.

What's missing? Well, I guess it's enough for the first
cut (the sponsored one), though of course we can do better
a number of things:

- add support for alternate styles
- allow the admin to specify a timeout (right now it's
hard coded)
- full support in Restconfig (we need to add new resources
there)
- improve the GeoTools client code so that we can use
HTTP 1.1 persistent connections and limit the number
of parallel connections we make to a single server
(right now GS is badly behaved from an HTTP client
point of view).
- allow the user to choose the format used for cascading.
Now we try png
- maybe add a pure proxy mode, if the request contains
only cascaded layers avoid decoding the image to just
re-encode it afterwards
- add support for WMS with access restrictions (this is
really just a matter of configuration, the gt2 module
does that already)
- support cascaded layers in GetMap requests that use
&SLD and &SLD_BODY

Anyone interested in picking up from the above list? :wink:

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Very good work

2010/5/4 Simone Giannecchini <simone.giannecchini@anonymised.com>

Nice work.

Simone.

Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo


On Tue, May 4, 2010 at 7:53 PM, Andrea Aime <aaime@anonymised.com> wrote:

Hi,
during the last few days I’ve been working on implementing
WMS cascading for GeoServer trunk.

The first patch is ready and attached to
http://jira.codehaus.org/browse/GEOS-623.

I’m going to make a formal GSIP tomorrow, but in the meantime
allow me to share a few screenshots of the work and a brief
description.

Once patched the GUI allows to create a new “WMS store” by
providing a capabilities link. After that we get to the usual
layer listing, and then to the usual layer configuration
page.

The layer config page metadata are filled using the values
found in the cascaded WMS capabilities document, including
bounds, srs, descriptions, keywords and whatnot.
The only visible difference compared to a normal layer config
page is that you don’t have a style chooser, since cascading
works, at this point, by simply using the default style.

The preview shows the cascaded layers with their own icon
(thanks Rollie for being prevident and preparing WMS layer
icons as well), and you can then follow and browse the
cascaded maps as if they were local.

Functionality implemented in the GetMap cascading:

  • standard cascading
  • reprojected cascading, trying to pass down to the remote
    server the destination SRS when possible, reprojecting
    on the client when not possible (see the EPSG:900913
    reprojection screenshot, looks nice because the srs
    was passed down)
  • request merging, if n consequent layers are cascaded
    from the same server a single GetMap will be issued
  • the WebMapServer instance is cached at the ResourcePool
    level making sure we don’t do too many GetCapabilities
    requests (caching the WebMapServer object results in
    the caching of the GetCapabilities response)

I’ve also implemented GetFeatureInfo cascading for the
case in which the remote server supports GML2 output
This has been tested against GS only, could not find
a MapServer instance that actually does GML output,
often it’s listed in the caps but results to the request are
consistently empty.
GetFeatureInfo cascading works also in the reprojected
case.

What’s missing? Well, I guess it’s enough for the first
cut (the sponsored one), though of course we can do better
a number of things:

  • add support for alternate styles
  • allow the admin to specify a timeout (right now it’s
    hard coded)
  • full support in Restconfig (we need to add new resources
    there)
  • improve the GeoTools client code so that we can use
    HTTP 1.1 persistent connections and limit the number
    of parallel connections we make to a single server
    (right now GS is badly behaved from an HTTP client
    point of view).
  • allow the user to choose the format used for cascading.
    Now we try png
  • maybe add a pure proxy mode, if the request contains
    only cascaded layers avoid decoding the image to just
    re-encode it afterwards
  • add support for WMS with access restrictions (this is
    really just a matter of configuration, the gt2 module
    does that already)
  • support cascaded layers in GetMap requests that use
    &SLD and &SLD_BODY

Anyone interested in picking up from the above list? :wink:

Cheers
Andrea


Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.



Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel



Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3203126609
mail: francesco.izzi@anonymised.com
skype: neofx8080

web: http://www.geosdi.org

Nice patch! Big but very clean.

The only minor suggestion/note i have is that WMSLayerINfoImpl.getWMSLayer() does a lot of work inline. The other ResourceInfoImpl classes delegate out to ResourcePool for all resource loading operations. It would be nice to follow that same pattern. Especially if the proposal to make the catalog classes pure java beans ever comes to light.

-Justin

On 5/4/10 11:53 AM, Andrea Aime wrote:

Hi,
during the last few days I've been working on implementing
WMS cascading for GeoServer trunk.

The first patch is ready and attached to
http://jira.codehaus.org/browse/GEOS-623.

I'm going to make a formal GSIP tomorrow, but in the meantime
allow me to share a few screenshots of the work and a brief
description.

Once patched the GUI allows to create a new "WMS store" by
providing a capabilities link. After that we get to the usual
layer listing, and then to the usual layer configuration
page.

The layer config page metadata are filled using the values
found in the cascaded WMS capabilities document, including
bounds, srs, descriptions, keywords and whatnot.
The only visible difference compared to a normal layer config
page is that you don't have a style chooser, since cascading
works, at this point, by simply using the default style.

The preview shows the cascaded layers with their own icon
(thanks Rollie for being prevident and preparing WMS layer
icons as well), and you can then follow and browse the
cascaded maps as if they were local.

Functionality implemented in the GetMap cascading:
- standard cascading
- reprojected cascading, trying to pass down to the remote
server the destination SRS when possible, reprojecting
on the client when not possible (see the EPSG:900913
reprojection screenshot, looks nice because the srs
was passed down)
- request merging, if n consequent layers are cascaded
from the same server a single GetMap will be issued
- the WebMapServer instance is cached at the ResourcePool
level making sure we don't do too many GetCapabilities
requests (caching the WebMapServer object results in
the caching of the GetCapabilities response)

I've also implemented GetFeatureInfo cascading for the
case in which the remote server supports GML2 output
This has been tested against GS only, could not find
a MapServer instance that actually does GML output,
often it's listed in the caps but results to the request are
consistently empty.
GetFeatureInfo cascading works also in the reprojected
case.

What's missing? Well, I guess it's enough for the first
cut (the sponsored one), though of course we can do better
a number of things:

- add support for alternate styles
- allow the admin to specify a timeout (right now it's
hard coded)
- full support in Restconfig (we need to add new resources
there)
- improve the GeoTools client code so that we can use
HTTP 1.1 persistent connections and limit the number
of parallel connections we make to a single server
(right now GS is badly behaved from an HTTP client
point of view).
- allow the user to choose the format used for cascading.
Now we try png
- maybe add a pure proxy mode, if the request contains
only cascaded layers avoid decoding the image to just
re-encode it afterwards
- add support for WMS with access restrictions (this is
really just a matter of configuration, the gt2 module
does that already)
- support cascaded layers in GetMap requests that use
&SLD and &SLD_BODY

Anyone interested in picking up from the above list? :wink:

Cheers
Andrea

------------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin Deoliveira ha scritto:

Nice patch! Big but very clean.

The only minor suggestion/note i have is that WMSLayerINfoImpl.getWMSLayer() does a lot of work inline. The other ResourceInfoImpl classes delegate out to ResourcePool for all resource loading operations. It would be nice to follow that same pattern. Especially if the proposal to make the catalog classes pure java beans ever comes to light.

Oh, ok. I thought ResourcePool was to be involved only when pooling
resoures was required.
But sure, an easy-peasy change

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

As we discussed I should be able to get some time in about 2 weeks. The most interesting aspects for here are:

  • add support for alternate styles

  • improve the GeoTools client code so that we can use HTTP 1.1 persistent connections and limit the number of parallel connections we make to a single server (mainly because I know I can do this :stuck_out_tongue: )

  • maybe add a pure proxy mode, if the request contains only cascaded layers avoid decoding the image to just re-encode it afterwards.

I will see what I have time to get done.

Jesse

Jesse Eichar ha scritto:

As we discussed I should be able to get some time in about 2 weeks. The most interesting aspects for here are:

- add support for alternate styles

Cool! This will require some bits of GUI and a decision on where
to put the styles.
With cascaded layers whether styles are to be stored in the resource
or in the layer it's hard to tell, but in a previous thread we agreed
it's simpler to do that in the resource (so that we don't have to
touch GeoServer own StyleInfo class).

- improve the GeoTools client code so that we can use HTTP 1.1 persistent connections and limit the number of parallel connections we make to a single server (mainly because I know I can do this :stuck_out_tongue: )

That would be great. The framework classes are in gt-main, I was wondering, wouldn't it be better to move them to a separate module
once we add the commons-http dependecy?

- maybe add a pure proxy mode, if the request contains only cascaded layers avoid decoding the image to just re-encode it afterwards.

Nice!

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Very cool Andrea.

A few comments inline.

What's missing? Well, I guess it's enough for the first
cut (the sponsored one), though of course we can do better
a number of things:
- add support for alternate styles

Are you just thinking named styles here; or SLD?

- allow the admin to specify a timeout (right now it's hard coded)

Cannot remember if the client code allows for this one. We had considered switching to commons http client in order to have better control.

- full support in Restconfig (we need to add new resources there)
- improve the GeoTools client code so that we can use
HTTP 1.1 persistent connections and limit the number
of parallel connections we make to a single server
(right now GS is badly behaved from an HTTP client
  point of view).
- allow the user to choose the format used for cascading.
Now we try png
- maybe add a pure proxy mode, if the request contains
only cascaded layers avoid decoding the image to just
re-encode it afterwards
- add support for WMS with access restrictions (this is
really just a matter of configuration, the gt2 module
does that already)
- support cascaded layers in GetMap requests that use
&SLD and &SLD_BODY

This is the tough one in that the client code does not currently handle get map post.

Anyone interested in picking up from the above list? :wink:

I will help as it happens; Jody

Jody Garnett ha scritto:

Very cool Andrea.

A few comments inline.

What's missing? Well, I guess it's enough for the first
cut (the sponsored one), though of course we can do better
a number of things:
- add support for alternate styles

Are you just thinking named styles here; or SLD?

Named styles. SLD can be used if the remote server can do
dynamic SLD requests, I consider this lower priority,
seems kind of a specialized need.

- allow the admin to specify a timeout (right now it's hard coded)

Cannot remember if the client code allows for this one. We had considered switching to commons http client in order to have better control.

Yes, it does. By hard coded I mean hard coded on the GeoServer side,
we just need to expose a parameter.
However by not using http client we're missing quite a bit of
extra funcionality that would make GS a well behaved (and more
efficient) WMS client (see the notes about HTTP 1.1 persistent
connection and connection count limit).

- full support in Restconfig (we need to add new resources there)
- improve the GeoTools client code so that we can use
HTTP 1.1 persistent connections and limit the number
of parallel connections we make to a single server
(right now GS is badly behaved from an HTTP client
  point of view).
- allow the user to choose the format used for cascading.
Now we try png
- maybe add a pure proxy mode, if the request contains
only cascaded layers avoid decoding the image to just
re-encode it afterwards
- add support for WMS with access restrictions (this is
really just a matter of configuration, the gt2 module
does that already)
- support cascaded layers in GetMap requests that use
&SLD and &SLD_BODY

This is the tough one in that the client code does not currently handle get map post.

Yeah, we'll cross that bridge when someone has a real use
case and resources to back it

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea Aime ha scritto:

What's missing? Well, I guess it's enough for the first
cut (the sponsored one), though of course we can do better
a number of things:

- add support for alternate styles

One thing that I forgot about is vendor parameters.
It would be nice if people could specify for each layer
what extra parameters they want to append to the request
(e.g., CQL queries, time/elevation, and whatnot).

It could be as easy as a string or something more detailed
like a table with key/value pairs (the latter would be
probably better actually, fits better the WMS client
request model)

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin Deoliveira ha scritto:

Nice patch! Big but very clean.

The only minor suggestion/note i have is that WMSLayerINfoImpl.getWMSLayer() does a lot of work inline. The other ResourceInfoImpl classes delegate out to ResourcePool for all resource loading operations. It would be nice to follow that same pattern. Especially if the proposal to make the catalog classes pure java beans ever comes to light.

I've updated the patch as you described, and also added in full
support for REST Config mimicking (well, actually blatantly copying and
adapting) the behavior of data stores and feature types. I also added
the same level of testing as the rest of the rest code to the new
resource.

That made the patch grow quite a bit to a whopping 259k, but... oh
well, at this point it's pretty much complete.

The only thing that's actually missing is documentation, but I think
I'll wait for the dust to settle before tacking that.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.