I found some problems when testing with QGIS.
- it cannot handle the get legend graphics we generate
- when opening up the propertie dialog with a WMS Layer backed by geoserver the application will hang for about a minuet; when it comes back it appears that the metdata tab has discovered the valid SRS codes
I found some problems when testing with QGIS.
- it cannot handle the get legend graphics we generate
Funny, how so? Just crashes?
- when opening up the propertie dialog with a WMS Layer backed by geoserver the application will hang for about a minuet; when it comes back it appears that the metdata tab has discovered the valid SRS codes
Sigh, it's the massive SRS list we're sporting that's hitting again.
Various clients do really parse each SRS into a memory representation.
They are doing the equivalent of CRS.decode(xxx) for every code we advertise, and there is no real good way to limit the list at the moment.
wonder if any of these two issues is a geoserver problem or not...
I'd love to say both our legend graphics are ok (respect the spec) and the
list of CRS in GetCapabilities being large means nothing but that we support
a lot of them and its up to client code to optimize...
so, is any of them related to a problem we should solve?
- we could limit the list of CRS as an administrator configuration option (not
until we have a new ui?)
- we'll need to fix any problem with getlegendgraphic if its not
behaving "correctly". I know its perhaps the most ambiguous operation on the
whole ogc spec stack....
cheers,
gabriel
On Tuesday 11 September 2007 08:49:53 Andrea Aime wrote:
Jody Garnett ha scritto:
> I found some problems when testing with QGIS.
> - it cannot handle the get legend graphics we generate
Funny, how so? Just crashes?
> - when opening up the propertie dialog with a WMS Layer backed by
> geoserver the application will hang for about a minuet; when it comes
> back it appears that the metdata tab has discovered the valid SRS codes
Sigh, it's the massive SRS list we're sporting that's hitting again.
Various clients do really parse each SRS into a memory representation.
They are doing the equivalent of CRS.decode(xxx) for every code we
advertise, and there is no real good way to limit the list at the moment.
wonder if any of these two issues is a geoserver problem or not...
I'd love to say both our legend graphics are ok (respect the spec) and the list of CRS in GetCapabilities being large means nothing but that we support a lot of them and its up to client code to optimize...
Unfortunately this is a widespread issue, so we should start thinking about handling it, yes.
so, is any of them related to a problem we should solve?
- we could limit the list of CRS as an administrator configuration option (not until we have a new ui?)
New ui and new config, yes. Unless we just place a new text file in
the user_projections directory with a comma separated list of CRS the user wants to limit himself to. This would be a band aid solution, but
could in fact work.
- we'll need to fix any problem with getlegendgraphic if its not behaving "correctly". I know its perhaps the most ambiguous operation on the whole ogc spec stack....
Well, we would need more info about how strange our response is...
Cheers
Andrea
I found some problems when testing with QGIS.
- it cannot handle the get legend graphics we generate
Funny, how so? Just crashes?
It pops up a dialog for each geoserver layer I imported going "Eeeek" (or some kind of I cannot handle this graphics format message).
- when opening up the propertie dialog with a WMS Layer backed by geoserver the application will hang for about a minuet; when it comes back it appears that the metdata tab has discovered the valid SRS codes
Sigh, it's the massive SRS list we're sporting that's hitting again.
Various clients do really parse each SRS into a memory representation.
They are doing the equivalent of CRS.decode(xxx) for every code we advertise, and there is no real good way to limit the list at the moment.