This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Jonathan, There are two problems causing problems for the testnotime.nc file. First, the latitude and longitude variables don't have any attributes so they aren't being recognized as geographic coordinates. Which means the variables aren't recognized as geo-gridded variables which is required for them to be served by WCS or WMS. The latitude and longitude variables in test.nc had the correct attributes. I added them to testnotime.nc with the following NcML: <?xml version="1.0" encoding="UTF-8"?> <netcdf xmlns="http://www.unidata.ucar.edu/namespaces/netcdf/ncml-2.2" location="testnotime.nc"> <variable name="latitude"> <attribute name="units" value="degrees_north" /> <attribute name="standard_name" value="latitude" /> </variable> <variable name="longitude"> <attribute name="units" value="degrees_east" /> <attribute name="standard_name" value="longitude" /> </variable> </netcdf> Once that was fixed, the URLs you gave still did not work. Turns out the values of latitude and longitude are different as well. For test.nc latitude goes from 45.7 to 50.8 and longitude goes from -7 to -0.3. On the other hand, for testnotime.nc, latitude goes from 0 to 47 while longitude goes from 0 to 43. When I adjusted the bounding box to fall into the area given by latitude and longitude, the requests worked. Something that might be useful in the future ... the ToolsUI application (found on the netCDF-Java home page: http://www.unidata.ucar.edu/software/netcdf-java/) is very useful for debugging this kind of problem. There are a few ways to look at netCDF files. The "Viewer" tab displays the basic structure of the netCDF. The "CoordSys" tab shows the coordinate systems that where found. The "Feature Types" - "Grids" tab shows which variables are recognized as gridded data and their associated coordinate system. Hope that helps, Ethan Jonathan Wilkins wrote: > Hi Ethan, > > Thanks for your reply. > > In the logs, nothing else other than what I mentionned before; nothing > in catalina.out/localhost-*.log, and a "Request Completed - 400" in > threddsServlet.log ... > > I've attached an archive containing the catalog and the two test netcdf files. > > In my test case, the catalog is the placed as the root catalog and the > requests are as below: > > 1) Requesting the test.nc: > > wget --server-response -O tmp-test.nc > "http://localhost:8080/thredds/wcs/test/test.nc?request=GetCoverage&version=1.0.0&service=WCS&format=NetCDF3&coverage=sst&bbox=-6,47,-3,50&time=2010-01-01T00:00:00Z" > > This request works fine, the time selection too. > > 2) Requesting the testnotime.nc which as its name let guess, has no > time dimension and so variables have only latitude and longitude > dimensions: > > # wget --server-response -O tmp-testnotime.nc > "http://localhost:8080/thredds/wcs/test/testnotime.nc?request=GetCoverage&version=1.0.0&service=WCS&format=NetCDF3&coverage=sst&bbox=-7,46,-2,50&time=2010-01-01T00:00:00Z" > > or > > # wget --server-response -O tmp-testnotime.nc > "http://localhost:8080/thredds/wcs/test/testnotime.nc?request=GetCoverage&version=1.0.0&service=WCS&format=NetCDF3&coverage=sst&bbox=-7,46,-2,50" > > These two requests fail with a "400: Bad Request" code > > > I hope you will be able to reproduce this. > > Regards, > > Jonathan Ticket Details =================== Ticket ID: VLL-101822 Department: Support THREDDS Priority: Critical Status: Open