Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
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 ***************************************
thredds
archives: