[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"; 
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