Notebook demonstrating glider AZFP data with external glider data

[emiliom]

Draft notebook demonstrating glider AZFP data processed with external Platform and Environment data. Data provided by Rutgers.

Unlike other echopype-examples notebooks so far, this one relies on small data files uploaded to the repo in a new data directory. Files include AZFP .01A and .XML files, and a Slocum glider netcdf file encompassing the time period spanned by the AZFP data.

Platform data is inserted into the echodata object using the update_platform method. Calibration is performed with temperature, salinity and pressure data averaged from the data in the Slocum glider file (come to think of it, I should probably average only over the time range spanned by the AZFP data). Location and depth are added to Sv using ep.consolidate.add_location and ep.consolidate.add_depth.

@leewujung at this time please review only the code, the sequence of processing steps and the plots and print outs. I will fill in the introductory text later, will edit the notebook title, and revisit all section headers and annotation text. Also, I'm using echopype.visualize.create_echogram because I wanted to try to showcase that echogram plotting function, but I don't like that I wasn't able to find a way to display the frequency (frequency_nominal) rather than the channel ID.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[emiliom]

I've finalized the notebook and references to it in the Jupyter Book main page and table of content.

The only remaining question I have is the use of echograms using ep.visualize. @leewujung should we keep it, or replace it with more "manual" plotting steps as done in the other notebooks? See the comments I've left in that section, in the notebook.

[leewujung]

@emiliom : thanks for putting together this notebook. Below are some comments that are smaller:

• recommend changing the filename to glider_azfp_externaldata.ipynb
• most of the Platform group data variables that do not exist in the .01A file are stored as a single NaN, but latitude and longitude just do not exist at all. Could you standardize this as part of review with CDL #1043?
• would be good to mention that in updating the latitude and longitude, these values are interpolated using the external dataset
  • one thing we should think about here is whether to mention how this interpolation is done -- in a sense we are not doing it correctly since we just do linear interpolation without taking into account the geodesic

The main thing that prevent this from being merged is that the consolidate.add_depth function is not ready to do what needs to be done for gliders or similar platforms that moves in the Z (depth) dimension. If you look at the add_depth operation, it does not currently take in the true depth of the platform and then add/subtract (depending on transducer orientation) the echo_range correctly to get depth.

This is a small addition, but I won't be able to get to it anytime soon...

I will submit a PR to your branch for some wording changes.

[emiliom]

• recommend changing the filename to glider_azfp_externaldata.ipynb

I like that. Plus, I see that using underscores is more consistent with the names of the other notebooks. I'll change it.

• most of the Platform group data variables that do not exist in the .01A file are stored as a single NaN, but latitude and longitude just do not exist at all. Could you standardize this as part of review with CDL #1043?

Yeah, I noticed that early only, and I intend to do something about it. FYI I recently asked a broader question about this in the SONAR-netCDF4 repo.

• would be good to mention that in updating the latitude and longitude, these values are interpolated using the external dataset
  • one thing we should think about here is whether to mention how this interpolation is done -- in a sense we are not doing it correctly since we just do linear interpolation without taking into account the geodesic

Ok, will do.

The main thing that prevent this from being merged is that the consolidate.add_depth function is not ready to do what needs to be done for gliders or similar platforms that moves in the Z (depth) dimension. If you look at the add_depth operation, it does not currently take in the true depth of the platform and then add/subtract (depending on transducer orientation) the echo_range correctly to get depth.

This is a small addition, but I won't be able to get to it anytime soon...

Right. Maybe we can chat about this briefly tomorrow?

I will submit a PR to your branch for some wording changes.

Thanks!

[emiliom]

Resolution of the depth issue in this notebook is contingent on progress on OSOceanAcoustics/echopype#1051

[ctuguinay]

Closing this since the glider notebook will be put in with #52