[Geoserver-devel] Ability to limit the list of SRS elements in WMS capabilities

Gabriel_Roldan2 · March 28, 2008, 6:34pm

Hey all,

as per <http://jira.codehaus.org/browse/GEOS-1830>, now its possible to
configure the list of SRS elements sent with a WMS capabilities document.

This may be quite useful for ArcGIS and JavScript clients, since those use to
get bloated by the 3900+ SRS we support.

To do so, one has to go to the contents WMS config page, where there's a text
area called "Limited Capabilities CRS List".
On it you can write a comma separated list of CRS identifiers. You can even
ignore the EPSG: prefix for them.
When submitting the form, geoserver will pick up only the valid ones from the
list and those will be the only ones stated in the WMS getcaps once the
config is applied. Config persistence is implemented too at the WMS service
section in services.xml.

It would be nice if those interested could give it a try before we release
next week.

Cheers,

Gabriel

Chris_Holmes1 · March 28, 2008, 7:24pm

Just a thought, though it may be a bit late, if people do set the limited srs codes, I wonder if we also might then put them in the WFS 1.1 caps? I think right now we just don't report there that we do any extra epsg codes, because there's no global list, only per featureType, so our caps docs would be way, way too long.

C

Gabriel Roldán wrote:

Hey all,

as per <http://jira.codehaus.org/browse/GEOS-1830>, now its possible to configure the list of SRS elements sent with a WMS capabilities document.

This may be quite useful for ArcGIS and JavScript clients, since those use to get bloated by the 3900+ SRS we support.

To do so, one has to go to the contents WMS config page, where there's a text area called "Limited Capabilities CRS List".
On it you can write a comma separated list of CRS identifiers. You can even ignore the EPSG: prefix for them.
When submitting the form, geoserver will pick up only the valid ones from the list and those will be the only ones stated in the WMS getcaps once the config is applied. Config persistence is implemented too at the WMS service section in services.xml.

It would be nice if those interested could give it a try before we release next week.

Cheers,

Gabriel

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4005,47ed39ea3401015089218!

Justin_Deoliveira · March 28, 2008, 9:02pm

Good idea, I believe at the moment all we do is set the "DefaultSRS", which i think is just hardcoded to EPSG:4326. It would be nice to provide the filtered list as "OtherSRS" elements.

Chris Holmes wrote:

Just a thought, though it may be a bit late, if people do set the limited srs codes, I wonder if we also might then put them in the WFS 1.1 caps? I think right now we just don't report there that we do any extra epsg codes, because there's no global list, only per featureType, so our caps docs would be way, way too long.

C

Gabriel Roldán wrote:

Hey all,

as per <http://jira.codehaus.org/browse/GEOS-1830>, now its possible to configure the list of SRS elements sent with a WMS capabilities document.

This may be quite useful for ArcGIS and JavScript clients, since those use to get bloated by the 3900+ SRS we support.

To do so, one has to go to the contents WMS config page, where there's a text area called "Limited Capabilities CRS List".
On it you can write a comma separated list of CRS identifiers. You can even ignore the EPSG: prefix for them.
When submitting the form, geoserver will pick up only the valid ones from the list and those will be the only ones stated in the WMS getcaps once the config is applied. Config persistence is implemented too at the WMS service section in services.xml.

It would be nice if those interested could give it a try before we release next week.

Cheers,

Gabriel

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

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

!DSPAM:4007,47ed461d26452090977483!

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

!DSPAM:4007,47ed461d26452090977483!

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

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

!DSPAM:4007,47ed461d26452090977483!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

Andrea_Aime3 · March 29, 2008, 9:34am

Justin Deoliveira ha scritto:

Good idea, I believe at the moment all we do is set the "DefaultSRS", which i think is just hardcoded to EPSG:4326. It would be nice to provide the filtered list as "OtherSRS" elements.

Quick check on geo:
http://geo.openplans.org:8080/geoserver/wfs?service=WFS&request=GetCapabilities
http://geo.openplans.org:8080/geoserver/wfs?service=WFS&request=GetCapabilities&version=1.0.0

Same layer, archsites, declares:
WFS 1.0: <SRS>EPSG:26713</SRS>
WFS 1.1: <DefaultSRS>urn:x-ogc:def:crs:EPSG:6.11.2:26713</DefaultSRS>

Looking at the schema, WFS 1.0 does not have a place to declare extra SRS, you can declare the BBOX in multiple SRS, but I guess it's not the same (plus, bbox reprojection could cause transformation failures... maybe it's better to stay away?)

WFS 1.1 has indeed the OtherSRS element that could be used to declare
the extra SRS.
Pros: the client knows that we're capable of reprojecting the layer
       in other srs
Cons: - we have to move the srs list up to GeoServer config
       - the srs list may be short or long. If long and we have many many
         layers (say, hundreds?) boom, the cap doc becomes quite long.
         E.g., picture this baby: http://giswebservices.massgis.state.ma.us/geoserver/wfs?request=GetCapabilities
         with 10 extra rows for each feature type (it's true that we
         already have quite a bit of rows for the output formats).

Opinions?
Cheers
Andrea

Gabriel_Roldan2 · March 31, 2008, 6:26pm

Hi,

I've been thinking about that, yet I can't get a fully satisfying answer
myself.

I mean, both the WMS SRS list and the WFS OtherSRS elements serve quite the
same purpose, yet, one is global and the other per feature type...
I'm not sure using the same list at both sides would fit all (users) needs,
and moving the list of filtered crs's to GeoServer config seems odd to me.
What I'm not sure about is if that list would have any role in the WCS
capabilities too?
Besides that, what I think would really make more sense is to:
- Have a list of "favorite" crs's, but does not directly maps to the WMS SRS
list nor all the WFS FeatureTypes
- Have an option in WMS config to inherit its SRS list from the global
favorite list. But also being able to add/remove more srs's
- Have a per feature type (at the data FeatureType edit page) option to set
the available CRS's for each feature type. This would be empty by default and
have the possibility to either inherit the ones from the global favorite list
and add/remove crs's. Or rather for the sake of simplicity, just the ability
to select which ones from the favorite list to list for each specific ft,
like in the case of additional styles.

Still less than optimal, but doable. And we already have a mix of wms and wfs
options in the featuretype editor page...

opinions?

Gabriel

On Saturday 29 March 2008 10:34:07 am Andrea Aime wrote:

Justin Deoliveira ha scritto:
> Good idea, I believe at the moment all we do is set the "DefaultSRS",
> which i think is just hardcoded to EPSG:4326. It would be nice to
> provide the filtered list as "OtherSRS" elements.

Quick check on geo:
http://geo.openplans.org:8080/geoserver/wfs?service=WFS&request=GetCapabili
ties
http://geo.openplans.org:8080/geoserver/wfs?service=WFS&request=GetCapabili
ties&version=1.0.0

Same layer, archsites, declares:
WFS 1.0: <SRS>EPSG:26713</SRS>
WFS 1.1: <DefaultSRS>urn:x-ogc:def:crs:EPSG:6.11.2:26713</DefaultSRS>

Looking at the schema, WFS 1.0 does not have a place to declare extra
SRS, you can declare the BBOX in multiple SRS, but I guess it's not the
same (plus, bbox reprojection could cause transformation failures...
maybe it's better to stay away?)

WFS 1.1 has indeed the OtherSRS element that could be used to declare
the extra SRS.
Pros: the client knows that we're capable of reprojecting the layer
       in other srs
Cons: - we have to move the srs list up to GeoServer config
       - the srs list may be short or long. If long and we have many many
         layers (say, hundreds?) boom, the cap doc becomes quite long.
         E.g., picture this baby:
http://giswebservices.massgis.state.ma.us/geoserver/wfs?request=GetCapabili
ties with 10 extra rows for each feature type (it's true that we already
have quite a bit of rows for the output formats).

Opinions?
Cheers
Andrea

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplac
e _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:4045,47ee0d2b277821849620573!

Andrea_Aime3 · April 2, 2008, 4:04pm

Gabriel Roldán ha scritto:

Hi,

I've been thinking about that, yet I can't get a fully satisfying answer myself.

I mean, both the WMS SRS list and the WFS OtherSRS elements serve quite the same purpose, yet, one is global and the other per feature type...
I'm not sure using the same list at both sides would fit all (users) needs, and moving the list of filtered crs's to GeoServer config seems odd to me.
What I'm not sure about is if that list would have any role in the WCS capabilities too?
Besides that, what I think would really make more sense is to:
- Have a list of "favorite" crs's, but does not directly maps to the WMS SRS list nor all the WFS FeatureTypes
- Have an option in WMS config to inherit its SRS list from the global favorite list. But also being able to add/remove more srs's
- Have a per feature type (at the data FeatureType edit page) option to set the available CRS's for each feature type. This would be empty by default and have the possibility to either inherit the ones from the global favorite list and add/remove crs's. Or rather for the sake of simplicity, just the ability to select which ones from the favorite list to list for each specific ft, like in the case of additional styles.

Still less than optimal, but doable. And we already have a mix of wms and wfs options in the featuretype editor page...

The ideal would be to have a per feature type list like we already have for WCS. The global settings would be used as defaults, since it's in
fact quite tedious to configure them for each feature type.
Yet, I'm not sure we want to do this more extensive changes with the current config system. Using it is just as funny as... "waxing on and off". I prefer katana's and nunchucks

Cheers
Andrea