Hi,
I have a custom WMS which I want to add as cascaded / remote WMS to GeoServer.
In my workflow I need to forward also custom parameters not known to WMS or GeoServer
The WMS I am talking of renders heat maps, a feature that is currently not available and describable in OGC service stack. It supports GetMap and GetCapabilites requests but requires some additional parameters which are currently swallowed by the cascaded WMS feature.
Time available and help appreciated.
Cheers,
Arne
On Fri, Sep 16, 2011 at 3:06 PM, Arne Schilling <as@anonymised.com> wrote:
Hi,
I have a custom WMS which I want to add as cascaded / remote WMS to GeoServer.
In my workflow I need to forward also custom parameters not known to WMS or GeoServer
The WMS I am talking of renders heat maps, a feature that is currently not available and describable in OGC service stack. It supports GetMap and GetCapabilites requests but requires some additional parameters which are currently swallowed by the cascaded WMS feature.
Time available and help appreciated.
Yes, all parameters that are unknown to GeoServer are ignored at the request parsing
level and are lost.
I’m also considering a case in which you are cascading multiple wms servers, just blindly
sending down all the extra params seems problematic, the same vendor param could
be have a different meaning for the two servers, or one of the might simply throw an
exception (though the WMS spec says to ignore the params that are not understood).
Cheers
Andrea
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
Hi,
thank you. Of course it should not compromise other applications.
Alternatively I could try to use an SLD, which is an optional WMS parameter.
Probably you already had the discussion. It seems that none of the optional parameters are actually forwarded to a remote WMS.
Since a GeoTools routine is used in this context (org.geotools.coverage.grid.io.AbstractGridCoverage2DReader), I am puzzled and don’t even know how to hack this, let alone a usable implementation of SLD forwarding. In the current doc I read that styling remote layers is not possible (as of yet).
Cheers,
Arne
On Fri, Sep 16, 2011 at 3:06 PM, Arne Schilling <as@anonymised.com> wrote:
Hi,
I have a custom WMS which I want to add as cascaded / remote WMS to GeoServer.
In my workflow I need to forward also custom parameters not known to WMS or GeoServer
The WMS I am talking of renders heat maps, a feature that is currently not available and describable in OGC service stack. It supports GetMap and GetCapabilites requests but requires some additional parameters which are currently swallowed by the cascaded WMS feature.
Time available and help appreciated.
Yes, all parameters that are unknown to GeoServer are ignored at the request parsing
level and are lost.
I’m also considering a case in which you are cascading multiple wms servers, just blindly
sending down all the extra params seems problematic, the same vendor param could
be have a different meaning for the two servers, or one of the might simply throw an
exception (though the WMS spec says to ignore the params that are not understood).
Cheers
Andrea
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
On Mon, Sep 19, 2011 at 2:38 PM, Arne Schilling <as@anonymised.com> wrote:
Hi,
thank you. Of course it should not compromise other applications.
Alternatively I could try to use an SLD, which is an optional WMS parameter.
Probably you already had the discussion. It seems that none of the optional
parameters are actually forwarded to a remote WMS.
Indeed none of them is. Nope, don't remember having this discussion,
WMS cascading is pretty new, relative few people used it so far
Since a GeoTools routine is used in this context
(org.geotools.coverage.grid.io.AbstractGridCoverage2DReader), I am puzzled
and don’t even know how to hack this, let alone a usable implementation of
SLD forwarding. In the current doc I read that styling remote layers is not
possible (as of yet).
Styling remote layers is going to be rather messy.
WMS has a concept of named styles, and each layer can be associated
to different named styles: that's the basic level, using these named styles.
Unfortunately a style in GeoServer is a SLD instead, so we have a mismatch
in our configuration subsytem that can be solved only by changing it, allowing
both named and SLD styles.
Then we could have cascading try to send down a SLD to the remote server.
This gets even messier, first off we don't know if the remote server accepts
SLD, and what version it accepts, SLD 1.0 or SLD 1.1
To aggravate the situation we have 3 different ways to send down the SLD,
SLD_BODY, which works only if the SLD is really small, &sld=url, which
assumes the remote WMS server can call back GeoServer on a url (which
is not something one can assume in general due to firewalls) or GetMap
POST, which only a few servers support.
Again, not easy to figure out which of the above is supported and will work.
If you are cascading more than one layer, which is something the current
code optimizes for by making a single request, the above requires all
the layers to be specified in SLD (library mode), whether we want to specify
the SLD just for one or for all.
So, cascading SLD gets really messy, really quick.
I believe that having a whiltelist of params to cascade in the wms store
configuration would be the way to go, along with code to preserve the params
(instead of ignoring them) and changes to the geotools code to accept these
vendor params is actually going to be easier.
But it will still be quite a bit of work, someone that knows his way in both
geotools and geoserver will still require a few days of work to make it working
and test it.
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------