Find IOOS models catalog

[ocefpaf]

Not ready for merging yet. Needs some tweaking to actually find data.

[review-notebook-app]

Check out this pull request on 

You'll be able to see Jupyter notebook diff and discuss changes. Powered by ReviewNB.

[ocefpaf]

@kbailey-noaa and @MathewBiddle the metadata that would make this notebook possible is coverage_content_type:

coverage_content_type: An ISO 19115-1 code to indicate the source of the data (image, thematicClassification, physicalMeasurement, auxiliaryInformation, qualityInformation, referenceInformation, modelResult, or coordinate).

Thanks @rsignell-usgs for the history lesson with all the emails all the way back to 2012!

[MathewBiddle]

I wonder how many are using it.

• ACDD highly recommends it.
• NCEI has it listed
• IOOS Metadata Profile v1.2 doesn't explicitly call it out.

It looks like only one example in the gold standard ERDDAP is using it. But nothing else.

[mwengren]

I recall a related discussion of this topic in Catalog years ago pertaining to the source attribute, which CF indicates should name the numerical model used if data was produced by a model.

Keep in mind that metadata that goes into the IOOS Catalog is first passed through ISO XML produced by ncISO (for THREDDS) or by ERDDAP directly, before it can be indexed by Catalog. So unless ncISO or ERDDAP includes source or coverage_content_type in the resulting ISO XML, Catalog won't know about it.

At one point I tried to understand how ncISO was treating the source attribute, and it turned out it wasn't reading it at all (see Unidata/threddsIso#34). Not sure how that issue was ultimately resolved if at all with the two different ncISO forks.

I haven't searched for coverage_content_type in Catalog datasets, but it looks like it is read/used in the UnidataDD2MI.xml stylesheet, so should be available if present in the dataset.

Finally, on a related note, we recently updated Catalog to read IOOS Profile 1.2 attributes directly from ERDDAP datasets, since this was easier than trying to adapt the ERDDAP ISO XML output. This could be enhanced to include either source or coverage_content_type if necessary, but it won't help much here since most model datasets will be served via the THREDDS/ncISO pathway.

Also, the client code would need to be updated to read the CKAN API via ckanapi module rather than CS-W, because the CS-W records will not include these custom ERDDAP attributes.

If we decide it would help, we can look into extending Catalog functionality to read THREDDS attributes as well.

cc @benjwadams.