search

ioos / notebooks_demos

Notebook demonstrations and examples
https://ioos.github.io/notebooks_demos/
MIT License
19 stars 19 forks source link

Find IOOS models catalog #347

Closed ocefpaf closed 3 years ago

ocefpaf commented 4 years ago

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

review-notebook-app[bot] commented 4 years ago

Check out this pull request on  ReviewNB

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

ocefpaf commented 3 years ago

@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 commented 3 years ago

I wonder how many are using it.

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

mwengren commented 3 years ago

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.