search

ioos / registry

Getting data services registered in the IOOS Service Registry
http://ioos.github.io/registry/
2 stars 7 forks source link

Is the stand-alone NcISO that NGDC uses up to date? #88

Open rsignell-usgs opened 8 years ago

rsignell-usgs commented 8 years ago

When THREDDS endpoints are harvested for metadata, it's my understanding that NCDC uses a stand-alone nciso and accesses data and attributes via the OPeNDAP link.

@amilan17, assuming this is correct, does the stand-alone version of nciso that NGDC is using contain the improvement that allows time extents to be calculated when the name of the time coordinate variable has standard_name='time', as described in this PR?

amilan17 commented 8 years ago

I merged the most recent update from github to our local copy, but it only entailed a change from last summer by Tom Kralidis.

I don't think the standard_name="time" PR update has been introduced to either our version or the github version of the ncISO XSL.

rsignell-usgs commented 8 years ago

@amilan17 , so where is the github version of the ncISO XSL?

amilan17 commented 8 years ago

https://github.com/Unidata/threddsIso/tree/master/src/main/resources/xsl/nciso

rsignell-usgs commented 8 years ago

That repo has the needed fix, supplied here: https://github.com/Unidata/threddsIso/pull/12

emiliom commented 8 years ago

@amilan17, based on what @rsignell-usgs said in his last comment, it sounds like your local copy has the time fix? But based on the NANOOS THREDDS OSU ROMS record as currently harvested, it doesn't look like the fix is there; I'm checking for a gml:beginPosition element, and don't see one. So, what is the status of the NGDC stand-alone ncISO with respect to this issue? If the fix is not in the operational version, do you have a rough estimate of when you might be able to update it? Thanks!

FYI, this is related to what we've been discussing at https://github.com/ocefpaf/sscsw/issues/3