Is it possible to limit the available SRS returned from GeoServer WMS?
GetCapabilities returns an enormeous list (3900+), of which most of
them make absolutely no sense at all, considering the data we're
serving.
David
David E. Reksten ha scritto:
Is it possible to limit the available SRS returned from GeoServer WMS?
GetCapabilities returns an enormeous list (3900+), of which most of
them make absolutely no sense at all, considering the data we're
serving.
Unfortunately we have no easy way to do so. There is one workaround
you may try:
* grab all the wkt definitions of the srs you care about from
the srs List and copy them into $geoserver_data_dir/user_projections/epsg.properties (each on a single line)
* remove epsg-hsql-xxx.jar from your geoserver install (it's in
geoserver/web-inf/lib
* restart
This should make GeoServer see and understand only the codes
you've put into that epsg.properties file. Unfortunately this workaround
is not tested by the developers, so I cannot guarantee it'll work.
Let us know if it works for you.
Cheers
Andrea
On 14/01/2008, Andrea Aime <aaime@anonymised.com> wrote:
David E. Reksten ha scritto:
> Is it possible to limit the available SRS returned from GeoServer WMS?
>
> GetCapabilities returns an enormeous list (3900+), of which most of
> them make absolutely no sense at all, considering the data we're
> serving.Unfortunately we have no easy way to do so. There is one workaround
you may try:
* grab all the wkt definitions of the srs you care about from
the srs List and copy them into
$geoserver_data_dir/user_projections/epsg.properties (each on a single line)
* remove epsg-hsql-xxx.jar from your geoserver install (it's in
geoserver/web-inf/lib
* restartThis should make GeoServer see and understand only the codes
you've put into that epsg.properties file. Unfortunately this workaround
is not tested by the developers, so I cannot guarantee it'll work.
Let us know if it works for you.
Thanks. I've modified epsg.properties to just include lat/long and
some utm zones (lines truncated for readability):
4326=GEOGCS["GCS_WGS_1984",...
32632=PROJCS["WGS_1984_UTM_Zone_31N",...
32632=PROJCS["WGS_1984_UTM_Zone_32N",...
32633=PROJCS["WGS_1984_UTM_Zone_33N",...
32634=PROJCS["WGS_1984_UTM_Zone_34N",...
32635=PROJCS["WGS_1984_UTM_Zone_35N",...
32636=PROJCS["WGS_1984_UTM_Zone_36N",...
but after removing gt2-epsg-hsql-2.4-SNAPSHOT.jar and restarting
Geoserver, calls to GetCapabilities returns:
HTTP ERROR: 503
SERVICE_UNAVAILABLE
The reason I'm experimenting with this, is that ArcMap 9.2sp4 takes
several minutes to display the available WMS layers from our Geoserver
(while maxing the local cpu), and I'm wondering if the enormeous SRS
list from Geoserver is causing this. We have about 60 layers in total,
which I don't think is an unreasonable amount, so I'm not sure where
the problem lies. ArcMap does not seem to have this problem with any
other WMS that I've tried.
Any hints or ideas are much appreciated.
Regards,
David
David E. Reksten ha scritto:
On 14/01/2008, Andrea Aime <aaime@anonymised.com> wrote:
Thanks. I've modified epsg.properties to just include lat/long and
some utm zones (lines truncated for readability):
4326=GEOGCS["GCS_WGS_1984",...
32632=PROJCS["WGS_1984_UTM_Zone_31N",...
32632=PROJCS["WGS_1984_UTM_Zone_32N",...
32633=PROJCS["WGS_1984_UTM_Zone_33N",...
32634=PROJCS["WGS_1984_UTM_Zone_34N",...
32635=PROJCS["WGS_1984_UTM_Zone_35N",...
32636=PROJCS["WGS_1984_UTM_Zone_36N",...but after removing gt2-epsg-hsql-2.4-SNAPSHOT.jar and restarting
Geoserver, calls to GetCapabilities returns:
HTTP ERROR: 503
SERVICE_UNAVAILABLE
Hmm... yeah, tried this myself and it does not work either...
The reason I'm experimenting with this, is that ArcMap 9.2sp4 takes
several minutes to display the available WMS layers from our Geoserver
(while maxing the local cpu), and I'm wondering if the enormeous SRS
list from Geoserver is causing this.
Yet it is. ArcMap is dull enough to try and load each srs code even
if it has no immediate use for them.
We have about 60 layers in total,
which I don't think is an unreasonable amount, so I'm not sure where
the problem lies. ArcMap does not seem to have this problem with any
other WMS that I've tried.
We would need to alter the geoserver configuration to allow for a
limited list of srs to be published, but this is quite long to
do with our current config subsystem. We are going to replace it
quite soon, but for the moment I have not better answers...
Others not very nice workarounds could be:
* save the capabilities response, modify it, point the clients at
that static file. Cons, not dynamic, you have to redo it each time
you add/remove a layer
* make the capabilities response go thru an xslt transform
that purges all unneeded srs
I was about to ask Saul from MassGIS how they managed to deal
with it, but apparently they did not, and are waiting
for arcgis 9.3 to fix the problem:
http://lyceum.massgis.state.ma.us/wiki/doku.php?id=wms:simple_clients:arcgis_explorer
If this is very important to you and you need another
solution we can either try to band aid it for you as a consulting
(paid) job or help you setup a developer enviroment so that you can
modify geoserver to suit your needs (this would be free, mail + irc).
Cheers
Andrea
David E. Reksten ha scritto:
On 14/01/2008, Andrea Aime <aaime@anonymised.com> wrote:
David E. Reksten ha scritto:
Is it possible to limit the available SRS returned from GeoServer WMS?
GetCapabilities returns an enormeous list (3900+), of which most of
them make absolutely no sense at all, considering the data we're
serving.Unfortunately we have no easy way to do so. There is one workaround
you may try:
* grab all the wkt definitions of the srs you care about from
the srs List and copy them into
$geoserver_data_dir/user_projections/epsg.properties (each on a single line)
* remove epsg-hsql-xxx.jar from your geoserver install (it's in
geoserver/web-inf/lib
* restartThis should make GeoServer see and understand only the codes
you've put into that epsg.properties file. Unfortunately this workaround
is not tested by the developers, so I cannot guarantee it'll work.
Let us know if it works for you.Thanks. I've modified epsg.properties to just include lat/long and
some utm zones (lines truncated for readability):
4326=GEOGCS["GCS_WGS_1984",...
32632=PROJCS["WGS_1984_UTM_Zone_31N",...
32632=PROJCS["WGS_1984_UTM_Zone_32N",...
32633=PROJCS["WGS_1984_UTM_Zone_33N",...
32634=PROJCS["WGS_1984_UTM_Zone_34N",...
32635=PROJCS["WGS_1984_UTM_Zone_35N",...
32636=PROJCS["WGS_1984_UTM_Zone_36N",...but after removing gt2-epsg-hsql-2.4-SNAPSHOT.jar and restarting
Geoserver, calls to GetCapabilities returns:
HTTP ERROR: 503
SERVICE_UNAVAILABLE
Ah, there is another way... try the following:
* remove all coverage demo layers from geoserver (both coverages
and coverage stores)
* make sure all the srs used by your remaining layers are in
the epsg.properties file
* try again
This might work better (found an old thead about the same issue here:
http://www.nabble.com/Two-Questions%3A-Geoserver-Performance-with-ArcGIS-9.2%2C-Querying-Raster-Layers--to11656726.html#a11659229)
Cheers
Andrea