NcISO is not computing the ISO fileIdentifier correctly from the id and naming_authority

[rsignell-usgs]

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 these lines
2. The fileIdentifier is being constructed using the id only, without the naming_authority information. See these lines

[ethanrd]

I believe this issue (and PR 122) should be on Unidata/threddsIso

[ethanrd]

... Or at least on both?

[rsignell-usgs]

@ethanrd, Last time we fixed Unidata/threddsIso it didn't make it into the next THREDDS version, so I figured I'd make the change here this time. It seems kind of crazy doing PRs for both, but if that's what it takes I'm willing to do that. Do you want two issues also?

[ethanrd]

@rsignell-usgs Yes, it is crazy. And it shouldn't be necessary. But until the THREDDS release engineering process is more fully automated (and lots of work has been happening around this lately) there is some level of work to get threddsIso changes into thredds. Which leaves it open for being missed. When the change is only the threddsIso XSLT files, making a PR to each repository decreases the risk of it being missed. Yes, its an ugly kludge, but its what we have at the moment.

Perhaps @cwardgar or @lesserwhirls has more thoughts on the automation of pulling threddsIso (and ncWMS) into the thredds build/release.

[lesserwhirls]

We need to have a plugin layer for TDS services which would allow us to
completely remove any ncIso or ncWms specific code from the THREDDS
codebase. This is something I'm eyeballing for THREDDS 5.0.

On Wed, Apr 15, 2015 at 10:25 AM, Ethan Davis notifications@github.com
wrote:

@rsignell-usgs https://github.com/rsignell-usgs Yes, it is crazy. And
it shouldn't be necessary. But until the THREDDS release engineering
process is more fully automated (and lots of work has been happening around
this lately) there is some level of work to get threddsIso changes into
thredds. Which leaves it open for being missed. When the change is only the
threddsIso XSLT files, making a PR to each repository decreases the risk of
it being missed. Yes, its an ugly kludge, but its what we have at the
moment.

Perhaps @cwardgar https://github.com/cwardgar or @lesserwhirls
https://github.com/lesserwhirls has more thoughts on the automation of
pulling threddsIso (and ncWMS) into the thredds build/release.

—
Reply to this email directly or view it on GitHub
#121 (comment).

[rsignell-usgs]

Fixed by #122