[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[THREDDS #VLL-101822]: WCS GetCoverage Http 400 Bad Request with timeless datasets

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"; 
  <variable name="latitude">
        <attribute name="units" value="degrees_north" />
        <attribute name="standard_name" value="latitude" />
  <variable name="longitude">
        <attribute name="units" value="degrees_east" />
        <attribute name="standard_name" value="longitude" />    

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,


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

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.