Determine feasibility of ERDDAP

[laurenwalker]

Research ERDDAP and what will be required to implement it in our system and web UI.

[csjx]

After discussing a good location for a test installation with Nick, we decided on datateam.nceas.ucsb.edu. I will work with Emily on the installation and configuration.

At first glance, the default deployment of ERDDAP seemingly doesn't look to support EML as a first class data input, but that's because the GenerateDatasetXml class (and the script that calls it) converts an EDDTableFromEML to an EDDTableFromAscii. So, the support is actually built in with the current installation, and we can experiment with 1) configuring an ERDDAP dataset specific to each of the SASAP derived datasets, then 2) configuring a Backbone.View that is able to load a specific dataset.

One thing that is apparent from the documentation is that the default ERDDAP HTML view is not embedded in the code 👍 , but rather it just calls the OpenDAP-style REST API. That will make it simple for us to build our own view. The crux, to me, is to make sure that ERDDAP has all of the entity and attribute metadata in the EML that it needs to parse the data tables fully, and that the data tables do in fact adhere to the described metadata. Bob Simons has a lot of good feedback about this in the EML adapter in the documentation.

[jeanetteclark]

I spun up a sandbox ERDDAP on my local and was able to use the GenerateDatasetXml using the EDDTableFromEML dataset class successfully, although I did have to do some hand editing of the resulting datasets XML. It seems like the ERDDAP-EML interaction worked pretty well although I think there are some nuances to figure out. Dates seem to be an especially sticky point since ERDDAP expects YYYY-MM-DD hh:mm:ss for all dateTime domains