Pydap is a pure Python library implementing the Data Access Protocol. You can use Pydap as a client to access hundreds of scientific datasets in a transparent and efficient way through the internet; or as a server to easily distribute your data from a variety of formats.

OceanDrivers_Pydap

Pydap is both client and server application to access netcdf/grib/HDF data. You use it to read the data but also to serve it throught opendap. The server has opendap and also the ability to server the data using WMS for gridded datasets. You can get the map tabs by installing the pydap.responses.wms module; the web UI will automatically pick it up and show the map if the dataset has any variables that can be displayed.

Pydap server also provide the code to acces the data with different opendap clients. It provides the ferret/Grads/IDL and pydap output itself:

$ python
>>> from pydap.client import open_url
>>> dataset = open_url(“https://pydap.oceandrivers.com/coads.nc”)
>>> import pprint
>>> pprint.pprint( dataset.keys() )

[‘UWND’,
‘WSPD’,
‘SST’,
‘VWND’,
‘SLP’,
‘COADSX’,
‘COADSY’,
‘AIRT’,
‘SPEH’,
‘TIME’]

Check our installation to see it working. https://pydap.oceandrivers.com/coads.nc.html

We asked Roberto de Almeida about the history of PyDAP:

“About the idea, I started development in 2003 because I was using Python and wanted to download data from an OPeNDAP server — I think I wanted some NCEP reanalysis data. At that time my programming skills were bad, but managed to write a simple client called pydods (OPeNDAP was initially know as DODS) that downloaded data from the ASCII response. It was horrible, but I didn’t know that and called it version 1.0.
 
After that I kept improving the code: added better parsing, added the ability of reading the binary response, and so on. After I had a working client and some understanding of the protocol I decided to write a server, which I did.
 
One problem at the time was that the Python web ecosystem was a mess: there was no WSGI, so the first version had 3 different interfaces: one for running it as CGI, another for Twisted, and a third one that I don’t remember. Another problem was that there was no Numpy at that time. There was Numeric, the original Python array library, but it was slow with large arrays; and there was Numarray, created some time after, which was slow with small arrays. So I supported both at the time. In a sense I think this was good, because Pydap was very modular from the start. 
 
Then came WSGI, and Numpy, Setuptools. I participated in the first Google Summer of Code in 2005 with a proposal to “modernize” Pydap and it was accepted. That’s when I wrote version 2.0, which was the first good version that people started using it.
 
For the future I want to release 3.2 some time this month, I’ll probably do a sprint to finish some things. I’m splitting Pydap into two different projects, a library only and a simply file based server using Flask+Bootstrap. And I want to add support for Python 3.”

Roberto de Almeida

You can get more information in our repository PyDAP. We also added two presentations about PyDAP. They are interesting because they were presented 1 week apart for two very different different audiences: the first was at the OPeNDAP developers meeting, for people who knew OPeNDAP but not Python; and the second at PyCon for people who knew Python but not OPeNDAP. You can check them here.