According to the ACDD Mappings, the ISO 19115-2 fileIdentifier is supposed to be computed from the combination of the netcdf attributes id and naming_authority.

Yet if we look at a dataset where both naming_authority and id are specified, we find that currently this is not working:

While the OPeNDAP Dataset Access Form specifies:

id: roms_hiog_forecast
naming_authority: org.pacioos

when we look at the ISO record we see

  <gmd:fileIdentifier>
      <gco:CharacterString>roms_hiog_forecast/ROMS_Oahu_Regional_Ocean_Model_best.ncd</gco:CharacterString>
   </gmd:fileIdentifier>

which is just the THREDDS path, with no naming authority information.

It looks like there are two problems with the UnidataDD2MI.xsl file.

1. The id first checks to see if there is a THREDDS ID, and then checks to see if there is a netcdf id attribute. It should be the other way around, because there will always be THREDDS ID (the pathname), and therefore the netcdf id, if present, will never be used. See https://github.com/Unidata/threddsIso/blob/master/src/main/resources/xsl/nciso/UnidataDD2MI.xsl#L31
2. The fileIdentifier is being constructed using the id only, without the naming_authority information. See https://github.com/Unidata/threddsIso/blob/master/src/main/resources/xsl/nciso/UnidataDD2MI.xsl#L181

See: http://cfconventions.org/cf-conventions/v1.6.0/cf-conventions.html#description-of-file-contents.

I did a search in the current version of UnidataDD2MI.xsl and couldn't find it called out in the variables section at the top.

Since this is mentioned as a critical file description variable in CF, shouldn't it be parsed and output in the ISO XML somewhere?

@lesserwhirls or @cwardgar, can you please check this wiki page I made for accuracy?https://github.com/Unidata/threddsIso/wiki/Upgrading-ncISO-on-an-existing-older-version-TDS

threddsIso fails to compile against THREDDS 5.0.0-SNAPSHOT. The biggest issue is that 5.0.0 deprecated all the classes in thredds.catalog and moved them to legacy.jar. And unfortunately, simply adding that dependency to threddsIso doesn't come close to resolving all of the breakage. I attempted to fix the remaining issues myself, but bailed because I don't understand the catalog machinery and how it was changed well enough.

Sorry for cross-posting, but the dimension type for time is defined as "temporal" in the threddsIso UnidataDD2MI.xsl:

It is actually defined as "time" in ISO 19115 and 19115-2 CodeList Dictionaries:

<codeEntry>
  <CodeDefinition gml:id="MD_DimensionNameTypeCode_time">
    <gml:description>duration</gml:description>
    <gml:identifier codeSpace="ISOTC211/19115">time</gml:identifier>
  </CodeDefinition>
</codeEntry>

Shouldn't it also be "time" instead of "temporal" in the UnidataDD2MI.xsl?
Thanks

Dear all,

we are using ncISO for extracting ISO-19115-conformal metadata from NetCDF-files on our THREDDS-Server. While most of it works like a charm, we have some trouble to define multiple entities with the same role. As an example, there are usually multiple contributors to a dataset (e.g., PI, owner, pointofcontact,co-author, etc.). But so far, all efforts in adding multiple names to the contrbutor_name-attribute simply leads to one lengthy string of names.

Here are the things that I have tried so far:

1. Separate the names with a comma and semicolon
2. Add a newline-character (similar to the NetCDF-History) between the names
3. Add the names as a Python-List with two elements.

After inspecting the contents of this repo, I've found some parameters like publishers, contributors and creators which seem to provide the desired functionality. But I have not yet managed to find the proper attribute-format....

Is this possible and, if yes, is there any kind of documentation about this feature?

Best regards and thank you very much in advance,
Christof

The ncISO code hardwires broken viewer links for some WCT beta service into the ISO records, like in this ISO record:

http://thredds.ucar.edu/thredds/iso/grib/FNMOC/WW3/Global_1p0deg/Best?catalog=http%3A%2F%2Fthredds.ucar.edu%2Fthredds%2Fcatalog%2Fgrib%2FFNMOC%2FWW3%2FGlobal_1p0deg%2Fcatalog.html&dataset=grib%2FFNMOC%2FWW3%2FGlobal_1p0deg%2FBest

which has a WCT viewer link of:
http://www.ncdc.noaa.gov/oa/wct/wct-jnlp-beta.php?singlefile=http://thredds.ucar.edu/thredds/dodsC/grib/FNMOC/WW3/Global_1p0deg/Best
https://www.ncdc.noaa.gov/oa/wct/wct-jnlp-beta.php

which gives a 404.

Is there an updated WCT endpoint that would work?

Would it not be good to provide the godiva endpoint in the ISO as a viewer endpoint, which does work, and which actually is provided by THREDDS?

http://thredds.ucar.edu/thredds/godiva2/godiva2.html?server=http://thredds.ucar.edu/thredds/wms/grib/FNMOC/WW3/Global_1p0deg/Best

@shane-axiom - There is a connection but I'm not sure how extensive it is. Mainly, I believe, the connection is limited to the XSLT transformation files that are shared between the command-line version and this plugin for THREDDS Data Server (TDS). But I will defer to Dave (@geoneubie) as my understanding of the connection isn't particularly detailed.

@shane-axiom wrote (originally issue 4 on ethanrd/threddsIso):

This may not apply, but is there any connection between this repo and the
command line version of ncISO? The line between ncISO and threddsISO
seems to be a little hazy. TDS documentation and configuration usually
references the embedded ncISO plugin, but according to this NGDC page
and this repository name ncISO is actually a jar meant for command line
execution against a remote TDS instance, and threddsISO is the name of
the TDS embedded plugin.

In any case, the CLI ncISO version on NGDC's page is broken, and I haven't
had luck getting on their mailing list. Any traction/illumination here? A brief
README might make the relation of this repo to ncISIO apparent.

In the process of updating the threddsIsoTds5 branch of this repo to use the latest version of netCDF-Java (and the proposed public API), I noticed a few things that are still not quite right with respect to coming in-line with ncIso. Of course, the transforms being out of sync are still an issue. However, there are a few more things as well. I'd really like to bring this repo up-to-speed, but it's not exactly clear where things stand in general. The initial steps for combining the codebases of ncIso and threddsIso have been done. The next step will be to refactor the layout of this repository to become a maven multi module project, which will allow us to produce a stand-alone ncIso jar cleanly along-side the plugin for the TDS.

So, as a conversation starter - is there still interest to have the two codebases combined and managed in one location?

Is there a way to generate an ISO metadata xml file from a ncml and/or a netCDF file without access to a THREDDs server? For example, I have several hundred CF-compliant netCDF files on a HPC that I would like to publish, but the repository requires an ISO metadata file for each file.

Thank you!

I am trying to do this on my desktop with the -custom and -xls the flags:

 java -Xms1024m -Xmx1024m -jar ncISO-2.3.5.jar -ts https://geoport.usgs.esipfed.org/thredds/sand/usgs/Projects/BBLEH/run071tRX/catalog.xml -num 1 -depth 1 -iso true -custom true -xslt UnidataDD2MI_dev.xsl

but I get this error:

ERROR [main] (DatasetTreeService.java:229) - _id=1
thredds.server.metadata.exception.ThreddsUtilitiesException: Configuration problem: xsl/null TransformerConfigurationException. D:\Documents\DATA_RELEASE\ISOcompare\standalone_ISO\xsl\null (The system cannot find the file specified)
        at thredds.server.metadata.util.ThreddsTranslatorUtil.doTransform(ThreddsTranslatorUtil.java:307)
        at thredds.server.metadata.util.ThreddsTranslatorUtil.transform(ThreddsTranslatorUtil.java:199)
        at gov.noaa.eds.service.DatasetTreeService.getNodes(DatasetTreeService.java:213)
...

ncISO is trying to locate the style sheet here:

D:\Documents\DATA_RELEASE\ISOcompare\standalone_ISO\xsl\null

I tried with placing the XSL in the same folder and with/without the folder name in the command line but no luck.

This works without the flags and the custom XSL. Also ncISO-2.3.5 throws this error but ncISO-2.3.7 completely ignores the flag and uses the default style sheet therefore no errors generated...

Hi,

See src/main/resources/xsl/nciso/UnidataDD2MI.xsl.

From the history of this file, it appears a change was made by Rich Signell from XSL version 1.1 to 1.0 on April 18, 2015. This causes the XSL to be invalid. Switching back to version 1.1 seems to fix the problem.

What was the reason to revert from XSL version 1.1 to 1.0? Can this be switched back to version 1.1?

Cordially,
Aaron

The master branch has been renamed to 2.2.x and contains, essentially, the TDS threddsISO plugin for TDS versions 4.6.x.

The threddsIsoTds5 branch has been renamed to main and now contains the combine the code bases of the command line utility and the TDS threddsISO plugin for TDS versions >5.x.

Finally, the default branch of the repository has been switched over to the new main branch.

I opened the file in Oxygen and it reports 111 errors, also the file doesn't compile as is...?

On line 1568 of UnidataDD2MI.xsl, a fake URL for a units vocabulary is inserted into the ISO metadata record:

1565 <xsl:if test="$variableUnits">
1566   <gmd:units>
1567     <xsl:attribute name="xlink:href">
1568       <xsl:value-of select="'http://example.org/someUnitsDictionary.xml#'"/>
1569       <xsl:value-of select="encode-for-uri($variableUnits)"/>
1570     </xsl:attribute>
1571   </gmd:units>
1572 </xsl:if>

When applied to an example netCDF (ncML) file for a variable having units of 'm', this results in a broken xlink:

<gmd:units xlink:href="http://example.org/someUnitsDictionary.xml#m"/>

Try simply updating threddsIso/src/main/resources/xsl/nciso/UnidataDDCount-HTML.xsl with transforms/UnidataDDCount-HTML.xsl from @noaaroland

Some time ago the UDDC conventions were deprecated in favor of the ACDD conventions. The updated documentation was published on the ESIPFed Wiki but the original docs on the Unidata site remain. This is probably fine because the Unidata site refers the user to the correct page at ESIP. However, the XSL and the Rubric page generated by threddsISO still refer to the outdated Unidata page and use the UDDC acronym rather than the ACDD acronym. See this catalog for an example (notice the UDDC under access methods).

The title of the rubric includes ACDD but the access methods are labeled UDDC. Also, the links in the rendered html page are also outdated.

1. This stylesheet link yields 404 error.
2. This convention description link should move from the NOAA EDM wiki to the correct ACDD page (@tedhabermann what's the correct link?)
3. All of the definitions for the attributes still refer to the Unidata page e.g. summary
4. "Rubric Version" at the bottom of the page is 2.0 but no link to where the rubric is hosted (github hopefully)
5. More Information should be moved to the ACDD page at ESIP. Probably should be either the category landing page or the latest version page.

I spent quite a few hours trying to figure out why this dataset doesn't have a "boundingTemporalExtent" in the ISO metadata:

http://comt.sura.org/thredds/comt_1_archive_summary.html?dataset=estuarine_hypoxia.WHOI_ChesROMS-1term.1991-2005_1termDO

The time values load just fine in Matlab, Python and in the TOOLS-UI gui. So why doesn't the time extent show up in the ISO metadata here?
http://comt.sura.org/thredds/iso/data/comt_1_archive/estuarine_hypoxia/WHOI_ChesROMS-1term/1991-2005_1termDO?catalog=http%3A%2F%2Fcomt.sura.org%2Fthredds%2Fcomt_1_archive_summary.html&dataset=estuarine_hypoxia.WHOI_ChesROMS-1term.1991-2005_1termDO

From the discussion on the ncisometadata google group with @geoneubie it turns out that ncISO is checking to see the coordinate variable time is named time, and since in this dataset the coordinate variable happens to be named "ocean_time", no "boundingTemporalExtent" is calculated. The offending line of code is:

The check is being made to distinguish the "time" coordinate from the "forecast_reference_time" or other time coordinates. But this should be determined by standard_name=time, not from the name of the netcdf variable, right?

@geoneubie comments?
@kwilcox, this problem currently affects all ROMS aggregations. 😿