Retire or update the NASA w10n Service code.

[ndp-opendap]

This issue is about retiring the w10n code in Hyrax. While w10n is a NASA thing it does not appear to have any legs. We should certainly look at our NASA logs to see if anything is hitting that service before proceeding with this proposed retirement.

The w10n protocol is interesting in that it does not really differentiate between the directory structure (aka catalog) and the structure (Groups, Structures etc) within a dataset. It provides a web access api that focuses on exposing leaves: Just the dataset variables that have values and are not "constructors" in the OPeNDAP sense. Everything else is just a path.

Here it is in Action on test.opendap.org:

• http://test.opendap.org:8080/opendap/w10n/
• http://test.opendap.org:8080/opendap/w10n/dap4/
• http://test.opendap.org:8080/opendap/w10n/dap4/StaggeredGrid.nc4
• http://test.opendap.org:8080/opendap/w10n/dap4/StaggeredGrid.nc4/time/
• http://test.opendap.org:8080/opendap/w10n/dap4/StaggeredGrid.nc4/time[]?output=json

Notice how the variable name time just becomes part of the URL path for data access.

Sadly our w10n implementation does not have dap4 support. It does not work with Groups and its failure mode is unsurprising. The DAP2 based code flattens the dataset, but that leads to incorrectly formed links.

• http://test.opendap.org:8080/opendap/w10n/dap4/SimpleGroup3.nc4.h5/

Note how all of the variable links are broken.

NASA
On our current NASA deployments there is no navigable catalog for the NGAP web-api and the w10n service is connected only to the test data tree that is installed with the rpms.

• https://opendap.earthdata.nasa.gov/w10n/

There is not currently w10n service access to the NGAP datasets at the dataset level either, but that could be accomplished by adding the w10n service id to the beginning of the path:

• OPeNDAP Dataset URL: https://opendap.earthdata.nasa.gov/collections/COLLECTION_CONCEPT_ID/granules/GRANULE_UR
• w10n Service URL: https://opendap.earthdata.nasa.gov/w10n/collections/COLLECTION_CONCEPT_ID/granules/GRANULE_UR

And then implementing the w10n stuff in the OLFS to use the NgapBesApi to do the NGAP things.
That plus support for dap4, which is pretty much what NGAP is all about so that would be necessary to have it be a meaningful update.

[jgallagher59701]

Does this work with the DMR++ code?

[ndp-opendap]

Does this work with the DMR++ code?

Sure, for w10n the dmr++ is no different than netcdf vs hdf vs css The w10n handler (and in general the entire OLFS) uses the dap to do things with the BES and knows nothing about the underlying data format.

• http://test.opendap.org:8080/opendap/w10n/dmrpp_test_files/
• http://test.opendap.org:8080/opendap/w10n/dmrpp_test_files/20210102090000-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1.2var.h5.dmrpp/
• http://test.opendap.org:8080/opendap/w10n/dmrpp_test_files/20210102090000-JPL-L4_GHRSST-SSTfnd-MUR-GLOB-v02.0-fv04.1.2var.h5.dmrpp/time/

But it only works for things that are DAP2. No DAP4 things work.