Hi Mike, all,
As the person chiefly responsible/to blame for the TDS-WMS code I'll add to
Ethan's comments here:
1. Regarding the setting of the default colour scale range: yes, this is
something of an imposition, sorry. However, there seems to be no easy way for
the system to automatically configure default scale ranges without scanning
every dataset under the TDS. This isn't impossible (it's what the standalone
ncWMS does) but the THREDDS config mechanism doesn't lend itself to this. This
could possibly be done in future, but it's not a trivial modification. How
many standard names exist in your system? The quickest configuration is
currently probably to either set a sensible global default (replacing the
-50:50 range) or to set defaults per standard name. I hope the docs that Ethan
referenced explain why it's necessary to set default colour scale ranges - let
me know if not.
2. Regarding the choice of CRSs: as Ethan said, I think all the EPSG database
(many hundreds, maybe more) is supported in Geotoolkit and hence in THREDDS.
Exposing all of these CRSs in the Capabilities doc produces a doc that's very
large indeed, so we picked a few that were important to us at the time; as
Ethan says we hope to make this configurable. But the important point is that
all the projections are still "active" in the system, even if they aren't in
the Capabilities doc, so you can do a GetMap request in any of the CRSs. If
you have a need for a particular projection, just try it out in a GetMap
request and there's a good chance it'll just work (let me know if not). The
projections ought to include the "web Mercator" projection too, although I
haven't tried it.
3. Regarding the GetLegendGraphic failure - you might like to try setting:
JAVA_OPTS=-Djava.awt.headless=true
in your catalina.sh file. This stops the system for looking for an X server
(which is used by Java for some graphics operations by default, for some
reason). I don't know why you only saw this problem with GLG but not GetMap
(perhaps it's only important with certain file formats)?
I hope this was helpful. Please do let me know if you have any suggestions
about how we can improve the config system in future versions.
(Ethan, maybe we need to update the THREDDS docs on the last couple of points
at least?)
Best wishes,
Jon
------------------------------
Message: 5
Date: Wed, 24 Nov 2010 00:36:04 -0500
From: Mike Grogan <Mike.Grogan@xxxxxxxx>
To: Ethan Davis <edavis@xxxxxxxxxxxxxxxx>, thredds@xxxxxxxxxxxxxxxx
Subject: Re: [thredds] 4.2 WMS troubles
Message-ID: <4CECA444.5060308@xxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
On 11/23/2010 18:44, Ethan Davis wrote:
> Hi Mike, Phil,
>
> On 11/23/2010 2:10 PM, Mike Grogan wrote:
>
>> John and All,
>>
>> We are seeing some WMS issues moving from 4.1 to 4.2. Specifically:
>>
>> 1. A black image (no data I assume) is being returned for the entire
>> spatial domain of our datasets.
>>
>
> I'm guessing this has to do with the change in the way the WMS code
> determines the default color scale range. Basically, the default range
> for all data is -50,50 though that can be configured [1] and there are
> extensions to the standard that allow specifying a range in a request
> [2]. (There was a good discussion about the reasons for this change on
> this email list back in Sept [3].)
>
I looked for previous discussions but did not see any ... now that you
have referenced them, I have gotten 4.2 working per its new
specification by specifying the color scale range in the URL request. I
am worried, though, about the need to specify a range for each standard
variable name in a config. For our NOMADS data holdings at NCDC, that
could be a daunting task for someone ... on the order of multiple weeks
or more, perhaps. Am I still missing something that would make that
simpler?
> [1]
> http://www.resc.reading.ac.uk/trac/myocean-tools/wiki/WmsDetailedConfiguration
>
> [2] http://www.resc.rdg.ac.uk/trac/ncWMS/wiki/WmsExtensions (see the
> COLORSCALERANGE parameter)
>
> [3]
> http://www.unidata.ucar.edu/mailing_lists/archives/thredds/2010/thread.html#00293
>
>
>> 2. There are way significantly fewer available projections in
>> GetCapabilities for 4.2 versus 4.1 (as in 6 versus several hundred in 4.1)
>>
>
> Yes. In 4.1, the list basically included all the CRS available from the
> geotoolkit package. It felt like a bit of overkill. The list has been
> trimmed down and we are looking at making it configurable.
>
>
What were the criteria for choosing the surviving available
projections? Unless I am looking at the wrong coodrinate ID lookup
tables, most of the remaining projections don't seem too familiar. (No
state planes, equal area, etc.)? What about web mercator? It seems to
me that this takes away a lot of the power of a dynamic map service.
Most importantly, it takes away a lot of options for tiled basemaps in
some mapping clients. If you are using a titled/cached basemap via a
lightweight mapping API, you need to be able to have server-side
reprojection of the dynamic WMS data into the same projection as the
base map. When using some APIs, it seems like this will force us to
create tiled basemaps using a very limited and arbitrary set of
projection/coordinate systems.
>> 3. GetLegendGraphic requests yield HTTP 500 errors - Internal Server Error
>>
>
> Can you look in your threddsServlog.log files and see if you are getting
> any error message?
>
>
I will follow up on this when I am back in the office. Initially, I am
seeing "java.lang.NoClassDefFoundError: Could not initialize class
sun.awt.X11GraphicsEnvironment" when I issue the request. I want to
double check my URL parameters though and make sure I am not messing
those up.
> Hope that helps,
>
> Ethan
>
>
Yes, it does, outside the other concerns expressed.
Thanks,
Mike
>> 4. Interestingly, GetFeatureInfo requests seem to work fine ...
>> returning data for a particular point properly.
>>
>> Any thoughts on where we might have gone wrong?
>>
>> - Mike Grogan and Phil Cogbill
>>
>>
>
> _______________________________________________
> thredds mailing list
> thredds@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mailman.unidata.ucar.edu/mailing_lists/archives/thredds/attachments/20101124/ee2858cd/attachment.html>
End of thredds Digest, Vol 22, Issue 10
***************************************
