Ticket #136 (feature request)

I have created a WCS extension for OWSLib that supports WCS 1.0.0 and to a certain extent 1.1.0 versions of WCS services.

This is still very much alpha code but I am attaching it here for initial review by Sean.

example usage:

from owslib.wcs import WebCoverageService
wcs=WebCoverageService('http://ndgbeta.badc.rl.ac.uk/wcs/badc.nerc.ac.uk__NDG-A0__AWQX8gTc', version='1.0.0')
wcs.serviceInfo.providerName
wcs.serviceInfo.accessConstraints
wcs.serviceInfo.fees
wcs.listCoverages()
cvg=wcs.getCvgByIdentifier('DHYcfjtk')
cvg.wgs84bbox
cvg.timeLimits
cvg.supportedFormats
wcs.getData(directory='myoutput', identifier='DHYcfjtk',timeSequence=['2024-01-15T00:00:00.0'],bbox=(-160,-75,160,75), format='cf-netcdf')

Implementation Notes

The key thing to note is that WCS 1.0.0 and WCS 1.1.0 are very different! It is also likely that WCS 1.2.0 will be different again... so I didn't want to bundle support for multiple WCS versions into the same set of classes.

So, I have essentially implemented two interfaces to each WCS type... which was a lot more work, but I think will make it more maintainable for the future. There is a 'lossy' version-independent interface that can make simple requests to any version of WCS (currently 1.0.0 and 1.1.0, but aims to be extendable), and then each version has it's own version-specific interface that can look up every little detail of the get capabilities document, and make more complex version-specific requests (in principle, not all of the more complex stuff has been implemented yet in 1.1.0)

I hope that most users will be satisfied with the common interface that can call both 1.0.0 and 1.1.0 (and 1.x.x) servers, but I didn't want to structure the code in such a way that would exclude version-specific improvements in the future. So this is a compromise - it means more code (supporting separate APIs for each version), but I think it makes the whole arrangement more futureproof.

So the module structure looks like this:

wcs.py (entry point)

wcslib (module)

wcsBase (base class) wcs100 (1.0.0 class) wcs110 (1.1.0 class) wcsDecoder (handles output - see below)

The wcs.py module is still the way into the API, in keeping with the WMS/WFS libraries. Depending on the version of WCS you request you then get returned either a wcs100 (1.0.0) or a wcs110 (1.1.0) object. As stated above these objects share a common interface, so they can be talked to in the same way. But, if you want to talk to them in a version specific way which enables a richer dialogue you can do that.

If you look at the code in either wcs100 or wcs110, you can see that they build up a wcs capabilities structure (as you did for the wms code), but they also build another structure with things like 'genericCoverages' and 'genericServiceInfo'. It is these generic objects that are used to create the cross version interface.

The wcsDecoder class is there to help in decoding the results of a WCS1.1.0 request - This can be a Multipart MIME or an XML document, and both of these need decoding in someway to get to the coverage data. I think there are some refinements could be made to this class, but the basic operations are there.

Note that this sample code above calls a beta WCS at: http://ndgbeta.badc.rl.ac.uk/wcs/badc.nerc.ac.uk__NDG-A0__AWQX8gTc This server supports both 1.0.0 and 1.1.0 requests (up to a point! hence the "ndgbeta").

Finally, this whole wcs module is still definitely in alpha/beta. I haven't tested it on a huge variety of WCS servers yet, but I think it's good to expose it more widely now anyway. Whether or not you want it more complete before integrating into OWSLib is your call of course.