Hi!
Thanks for the quick and thorough response and for giving us some alternatives to look into!
We will ponder your comments and if we decide to look further in to the case of modifying geoserver, we will likely return with more specific questions. Now we at least have some more info to base our decision on which road to take.
Regards,
Björn
______________________________
Björn Lindell
Riksantikvarieämbetet
IT-enheten
Tel: 08-51 91 80 46
E-post: bjorn.lindell@anonymised.com
Andrea Aime <aaime@anonymised.com> 02/20/07 10:36 AM >>>
Björn Lindell ha scritto:
Hello!
(I apologize if I choose the wrong mailing list, but I deemed this a
code-related question more than a user-related one)We at The National Heritage Board of Sweden (Riksantikvarieämbetet, RAÄ)
have a strong commitment to open source solutions and are currently starting
a project to give mapping functionality to our public and internal
databases.The solution is rather standard (as far as we can see), where we have an
external provider from which we have licensed background maps and we want to
join these with our own geographical features provided from an Oracle
Spatial database.We have looked at Geoserver and everything seems to point in its favour
(features, performance, technical platform). All but the fact that there is
no support for cascading WMS.Since we most likely will be retrieving our background maps (raster format)
through WMS, it seems that cascading WMS would be a requirement on part of
our local map server solution.
This is http://jira.codehaus.org/browse/GEOS-623
The basic building blocks are already there:
* renderer can handle grid coverages
* geotools provides a WMS client, used successfully in uDig, that allows
you to build a BufferedImage out of a WMS request.
What is missing, is the bridge connecting them. At the moment
the renderer can handle feature sources, plain GridCoverage objects, or
AbstractGridCoverage2DReader instances.
The road seems to be, implement a wrapping layer that makes the WMS
look like a coverage set, and configure each layer you want to cascade
as a separate grid coverage.
There are issues thougth:
* a WMS layer is not a real grid coverage, in that it does not have a
"native" resolution and a real set of bands (it does not even have a
real data format), and it's not intended to be served along with WCS.
I guess that for the sake of cascading, you could just set some fake
native parameters and be done with it.
* at the moment coverage store maps one to one to a single grid
coverage, whilst the WMS case is 1:n, and I have the feeling current
classes are not really set up to manage this case.
If the 1:1 relation I see is hard to remove, you could provide
your "coverage store" an url like http://url.to.capabilities?layerName
to make it serve a single layer... quite an ugly solution thought.
That said, making WMS look like plain coverages would allow you to
re-use the configuration objects and pages already available in Geoserver.
Another possibility, would be to have WMS treat cascaded WMS layers
separately (not as a coverage, nor as feature, but as something new)
and have WMS gather the image as a BufferedImage, wrap it into a
GridCoverage, and add the GridCoverage as a layer in the MapContext.
This would mean you have to build another set of configuration pages
and object to handle the WMS as a special case. You could do that
as cut and paste from coverages or data stores, but I warn you,
that code is really ugly 
Maybe Simone or Alessio may want to chime in an comment the first
hypothesis, that is, make WMS look like a coverage set.
Cheers
Andrea