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

[SupportPlaza #LWJ-749499]: FW: THREDDS WCS GetCoverage Http 400 Bad Request

Hi Derrick,

What version of the TDS are you running? (The version number is displayed at 
the bottom of all the HTML catalog pages, e.g., 

Are you running Tomcat or some other servlet container? And what version?
What version of Java?

> I am having problems trying to obtain a NetCDF3 or GeoTIFF file with the
> GetCoverage request. The dataset I am testing it on is striped.nc.
> I am able to getCapabilities and describeCoverage, but when I make a
> request for GetCoverage I get the 400 Bad Request error.
> The following URLs I am hitting are:
> http://localhost:8082/thredds/wcs/galeon/striped.nc?service=WCS&version=1.0.0&request=GetCapabilities
> http://localhost:8082/thredds/wcs/galeon/striped.nc?request=DescribeCoverage&version=1.0.0&service=WCS
> http://localhost:8082/thredds/wcs/galeon/striped.nc?request=GetCoverage&version=1.0.0&service=WCS&format=NetCDF3&coverage=ta&time=2005-05-10T00:00:00Z&vertical=100.0&bbox=-134,11,-47,57

Are the GetCapabilities and DescribeCoverage requests working?

What HTTP headers and body are you getting back from the GetCoverage request? 
(Browsers generally don't show the body of a 400 response but you can look at 
it with netCDF-java ToolsUI which is available from the netCDF-java home page, 
http://www.unidata.ucar.edu/software/netcdf-java/. In ToolsUI, go to the 
"URLdump" tab, enter in the URL, and click on the "Get" button.)

> I have obtained the last url from the examples provided at
> http://www.unidata.ucar.edu/projects/THREDDS/tech/reference/WCS.html
> Below is how I have configured my catalog.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <catalog 
> xmlns="http://www.unidata.ucar.edu/namespaces/thredds/InvCatalog/v1.0";
> xmlns:xlink="http://www.w3.org/1999/xlink"; name="THREDDS-IDD WCS Data Server" 
> version="1.0.1">
> <service name="all" serviceType="Compound" base="">
> <service name="wcs" serviceType="WCS" base="/thredds/wcs/" />
> <service name="openDAP" serviceType="OPENDAP" base="/thredds/dodsC/" />
> <service name="http" serviceType="HTTPServer" base="/thredds/fileServer/" />
> </service>
> <dataset name="THREDDS-IDD WCS Data Server">
> <metadata inherited="true">
> <serviceName>all</serviceName>
> <authority>unidata.ucar.edu:</authority>
> <dataType>Grid</dataType>
> </metadata>
> <datasetScan name="GALEON Test Data" path="galeon" 
> dirLocation="content/wcsExample/testdata/" filter=".*\.nc$" />
> </dataset>
> </catalog>

I don't see an obvious problems with your configuration catalog.

> I am having problems getting THREDDS to display the errors in the logs,
> in stdout, I am getting the following error:
> log4j:ERROR LogMananger.repositorySelector was null likely due to error in 
> class reloading, using NOPLoggerRepository.
> log4j:WARN No appenders could be found for logger 
> (org.springframework.util.ClassUtils).
> log4j:WARN Please initialize the log4j system properly.
> TdsConfigContextListener.contextInitialized(): start.

Are you getting any log files in ${TOMCAT_HOME}/content/thredds/logs? We see 
the "No appenders" WARNing messages due to how we configure logging (a bit 
round about I'm afraid). I'm not sure about the ERROR message. Was this a clean 
deployment of the .war file? Or was there an upgrade to this version of the 
TDS? Sometimes if you deploy over an old version of a webapp without 
undeploying it first, you can get strange class loading issues.

If there are any log files, the threddsServlet.log file is the one of most 
interest. We may have to up the logging levels to get much information there 

Hope this helps,


> Can someone kindly assist?
> Thank you in advance.
> Derrick Wong
> Software Engineer | ASRDC (Australian Spatial Research Data Commons) Project 

Ticket Details
Ticket ID: LWJ-749499
Department: Support THREDDS
Priority: Normal
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.