Basically the code
just attempted to get a coverage returned from the server. If
multiple coverages were available, the first was requsted. Likewise,
if multiple times were available, the initial time was requested.
Where problems arose, the notes below show either the error message
returned in the output file or the error message from the python
interpreter. Apologies to those who don't use python, but perhaps
the message will be useful anyway.

Update: Code Now Attached

Attached are two sample files which show how these tests were done.

wcsThreddsExample.py

serverTests.py

wcsThreddsExample.py is an illustration of how to contact the Unidata Thredds WCS using the python OWSLib client. This can be adapted to test other clients.serverTests.py is the test script used in these exercises to test multiple servers. This code is published with the caveat that it was very much thrown together quickly to see how many servers a coverage could be retrieved from.

No problems from the
following servers:

This simply means
the server APPEARS to have returned a valid coverage. But no check
was made to see if the coverage indeed made any sense.

The tests directory contains some doctests which serve as examples and should help you get started with the client. I have also asked Ben to post some sample code on the GALEON wiki.

Further Discussion:

On Tuesday 29 July 2008 16:20:09 Roy Mendelssohn wrote:
> I only have internet off and on. If you get a chance, some of our
> datasets are clearly global (labeled so) and some clearly are not.
> Could you do a quick test to see if it the global ones that are
> failing? Perhaps it is that it goes form 0,360 rather than 0,359 is
> what is fouling things up.
>

I am happy with the python client code from Dominic Lowe. This helps us
improving the service. I have tested the wcs client and I get the same
errors as you do.
The problem is that I am not sure whether we should support default CRS
and Width/Height parameters...

Dominic Lowe Comments:

This server requires Width and Height parameters.

Adding "width=600, height=400" to the parameters returns a different error
possibly suggesting some type of file access problem on the server side ?

Maarten, In terms of CRS, resX, resY, width, height I think you should
be able to just pass these args through the client (or indeed any other
args). The "cvg.supportedCRS" attribute should list the available CRSs
for a coverage (cvg). Let me know if you have problems with this.

NSIDC discussion:

Error message from
ouput file from:

http://nsidc.org/cgi-bin/atlas_south

POST body is shortContent-type: text/html<h1>Software
error:</h1><pre>Bad file
descriptor at /WEB/INTERNET/cgi-bin/atlas_south line 104</pre><p>For help, please send mail
to the webmaster (<a
href="mailto:www@nsidc.org">www@nsidc.org</a>),
giving this error message and the time and date of
the error.</p>

John Maurer of NSIDC suggested:

Thanks for your reply. I see in your e-mail that no crs (coordinate
reference system) is specified. This is a required parameter for a
GetCoverage request (at least in WCS 1.0--I didn't check later
versions). This would explain why you are not getting any results.
Another requirement is that you must specify either WIDTH/HEIGHT or
RESX/RESY parameters. For more details on the WCS spec, see the OGC
site at:

Here are two GetCoverage requests that would successfully download the
GeoTIFF you listed; the first is in a polar projection (EPSG:3031) and
the second is in the latlong projection (EPSG:4326) you were apparently
testing for (since your bounding box was in degrees); note that the
layer you picked is not that interesting in this case (not much snow in
the Southern Hemisphere) but that's beside the point:

Hope this helps! Let me know if I can be of further assistance.
Cheers,
John

Dominic Lowe added:

It turns out this problem was actually to do with the way I was encoding the
request URL in python. I've changed this now in the code.

I hadn't encountered this problem before - it's only through exposure to
various servers that these issues come to light, so thanks for the feedback.

Ben Domenico comments:

I got the latest owslib via subversion and, sure enough, the error message disappeared and the client successfully acquired
the geoTIFF from the NSIDC server when I included the crs, height, and
width parameters. I have to think through what the implications of
those parameters are for our THREDDS Data Server WCS interface.

Dominic Lowe Comments:

I have fixed a couple of bugs in the client code and can now access the
server.
However I get a 'Content not allowed in prolog' error when trying to unpack
the Multipart Mime response from a getCoverage request.

I think that there may be some headers missing from the multipart mime
response.

i.e. I suspect there should be something like this:
Content-Type: multipart/mixed; boundary="===============

But, I am by no means very familiar with MIME so I may easily have
misinterpreted something. If anybody knows which (if either) is the correct
way to deliver multipart MIMEs that would be most helpful.

Paolo Mazzetti comments:

Concerning your test with our WCS 1.1.0 server we (Mattia Santoro
and I) analyzed our server responses.
Actually they look correct, but the response "content not allowed in
prolog" during XML parsing usually comes from some encoding problem.
Thus we are examining our code to verify if an encoding mismatch
occurs somewhere between xml prolog, http header declaration and
actual data encoding.

By the way comparing our and your servers responses we found the
following differences and problems:

1) Your response includes the "MIME-Version" header field in each
body part while ours does not. We do not think that this should be a
problem, but if your client expects it an error could be raised.
Please note that the specifications (RFC 2045) state that "the
MIME-Version header field is required at the top level of a
message. It is not required for each body part of a multipart
entity. It is required for the embedded headers of a body of type
"message/rfc822" or "message/partial" if and only if the
embeddedmessage is itself claimed to be MIME-conformant."

2) We found a small error in our response: a double ";" before the
"charset" attribute in the HTTP header. This is sintactically
correct but depending on the http client library behaviour, it could
be one of the reasons for the possible character encoding error
previously described.

Generally speaking we are currently revising the multipart response.
In particular we are considering the following modifications:

a) The message should be multipart/related instead of
multipart/mixed since the semantics of multipart/related better fits our case.
b) The Content-ID should be world-unique.

We still have not implemented this modifications in our server, but
I am going to better detail them in a paragraph of the document "WCS
extensions for CF-NetCDF 3" that Stefano is preparing.

Weather.aero (WCS
1.1.1) discussion:

Error message from the
python interpreter for

http://weather.aero/wcs/soap',
version='1.1.1'

Initializing the WCS
objectFind out general
information about the WCS-----------------------------------------------Traceback (most recent
call last):File
"C:/Python25/Scripts/wcsExamplesBens.py", line 76, in
<module>%wcs.identification.titleAttributeError: 'NoneType'
object has no attribute 'identification'>>>

Aaron Braeckel Comments:

the weather.aero
(Experimental ADDS/NNEW) servers are implemented on top of SOAP. Based
on the error I see listed, it seems as if either we are not properly
implementing KVP-based getCapabilities or SOAP requests and responses
are the issue.