ioos / registry

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

CariCOOS THREDDS catalog contains multiple opendap service URLs for each data set #34

Open dpsnowden opened 10 years ago

dpsnowden commented 10 years ago

@amilan17 sent an offline request to @jcapella which might benefit the broader group. I'm repeating the email from her below then I'll add my comments in another comment block.

Hi Jorge, As I'm digging through harvest log history in EMMA I discovered that all of the services registered are failing translation from NcML to ISO because the opendap_service element is repeated.

Here are a couple examples of the repeated element:

<attribute name="opendap_service" value="http://dm1.caricoos.org/thredds/dodsC/buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc"/>
<attribute name="opendap_service" value="http://dm1.caricoos.org/thredds/dodsC/content/nasa_oceancolor/VIIRS/V2014176171116.L2_NPP.CariCOOS_Regional.hdf"/>

I'm going to temporarily turn off harvesting for caricoos until this is resolved. Do you think that you can fix this on your end?

Also, based on the dashboard of caricoos metadata history, - it looks like this error might have started on April 3... http://www.ngdc.noaa.gov/metadata/published/NOAA/IOOS/CariCOOS/iso/

Anna

dpsnowden commented 10 years ago

@amilan17 , Can you be a little more specific about what you want @jcapella to "fix" and what it might look like when he's done?

I did a little digging and I see the catalog in which the dataset ( http://dm1.caricoos.org/thredds/dodsC/buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc) is at http://dm1.caricoos.org/thredds/dodsC/buoys/Historical/PR3/catalog.html?dataset=buoys/Historical/PR3/DSG_PR3.waves.accelerometer2.v1.historical.nc

Under the "Access" section I see that number 2 and 10 are identical and are both opendap services. The corresponding xml document is at http://dm1.caricoos.org/thredds/dodsC/buoys/Historical/PR3/catalog.xml?dataset=buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc and the section describing the services contains two lines that both correspond to opendap...

<service name="odap" serviceType="OPENDAP" base="/thredds/dodsC/"/> and <service name="ncdods" serviceType="OPENDAP" base="/thredds/dodsC/"/>

I have no idea which one is correct or the meaning of name="odap" and name="ncdods". @rsignell-usgs, any comments on which one to choose and what it means to have to have two identical serviceType entries?

rsignell-usgs commented 10 years ago

@dpsnowden, nice sleuthing! Indeed, this is a problem that caricoos can easily fix. I'm pretty sure that it's essentially a typo caused by cut-and-pasting services from one catalog to another. I'm pretty sure that these services are defined inside a collection of services such as:

        <service name="allServices" serviceType="Compound" base="">
            <service name="odap" serviceType="OpenDAP" base="/thredds/dodsC/"/>
            <service name="wcs" serviceType="WCS" base="/thredds/wcs/"/>
            <service name="wms" serviceType="WMS" base="/thredds/wms/"/>
            <service name="ncss" serviceType="NetcdfSubset" base="/thredds/ncss/"/>
            <service name="ncml" serviceType="NCML" base="/thredds/ncml/"/>
            <service name="uddc" serviceType="UDDC" base="/thredds/uddc/"/>
            <service name="iso" serviceType="ISO" base="/thredds/iso/"/>
        </service>

So @jrodriguez-caricoos or @jcapella, just delete the duplicate service entry from the catalogs that contain it. Which one to delete? It doesn't matter unless you refer to that service by name in the datasets that follow. But most likely you just refer to the service collection by name (e.g. allServices), in which case it would not matter which one you delete.

amilan17 commented 10 years ago

To be a little more clear: This entire element is repeated character for character:

<attribute name="opendap_service" value="
http://dm1.caricoos.org/thredds/dodsC/buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc
"/>

<attribute name="opendap_service" value="
http://dm1.caricoos.org/thredds/dodsC/buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc
"/>

>
jcapella commented 10 years ago

Been out in the field. Will look into it next week.

Thanks,

Jorge

On 6/27/2014 3:12 PM, Anna Milan wrote:

To be a little more clear: This entire element is repeated character for character:

<attribute name="opendap_service" value=" http://dm1.caricoos.org/thredds/dodsC/buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc

"/>

<attribute name="opendap_service" value=" http://dm1.caricoos.org/thredds/dodsC/buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc

"/>

Anna ~~~~~~~ Anna.Milan@noaa.gov, 303-497-5099 NOAA/NESDIS/NGDC

http://www.ngdc.noaa.gov/metadata/emma ~~~~~~~

On Fri, Jun 27, 2014 at 12:11 PM, Rich Signell notifications@github.com wrote:

@dpsnowden https://github.com/dpsnowden, nice sleuthing! Indeed, this is a problem that caricoos can easily fix. I'm pretty sure that it's essentially a typo caused by cut-and-pasting services from one catalog to another. I'm pretty sure that these services are defined inside a collection of services such as:

So @jrodriguez-caricoos https://github.com/jrodriguez-caricoos or @jcapella https://github.com/jcapella, just delete the duplicate service entry from the catalogs that contain it. Which one to delete? It doesn't matter unless you refer to that service by name in the datasets that follow. But most likely you just refer to the service collection by name (e.g. allServices), in which case it would not matter which one you delete.

— Reply to this email directly or view it on GitHub https://github.com/ioos/registry/issues/34#issuecomment-47382370.

— Reply to this email directly or view it on GitHub https://github.com/ioos/registry/issues/34#issuecomment-47389150.

rsignell-usgs commented 10 years ago

@jcapella , let me know if you have any questions on this. It should be an easy fix.

jcapella commented 10 years ago
Anna:
Just cleaned our thredds directory of several old xml test files
that were performing multiple datasetscans of the buoy directory. 
Initially thought the entry duplication might have been due to the
aggregation but we do not aggregate the accelerometer data.  The
specific data files you indicate below should only be added through
the

 <datasetScan name="CariCOOS Buoys"
  ID="buoys" path="buoys"  location="content/buoys">

in catalog.xml.  Since none of the other xml catalogs should call on
these files the service name duplication might not be the culprit
(?).
Don't know if this will fix the problem but maybe another registry
harvest is in order.  Let me know if the problem persists, meanwhile
we will keep looking at the other alternatives.
Is there a way for us to locally conduct a registry dry run?
Jorge
amilan17 commented 10 years ago

Changed status of these two services registered to 'Submitted' https://www.ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=SUBMITTED&serviceUrl=&search=List+Collection+Sources

However, I'm still seeing the same element repeated in this file: http://dm1.caricoos.org/thredds/ncml/buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc?catalog=http%3A%2F%2Fdm1.caricoos.org%2Fthredds%2Fcatalog%2Fbuoys%2FHistorical%2FPR3%2Fcatalog.html&dataset=buoys%2FHistorical%2FPR3%2FDSG_PR3.accelerometer2.historical.nc

Under the Services group in the XML. (group name="services")

jcapella commented 10 years ago
Is this the only instance of duplication or just an example?On 7/2/2014 1:57 PM, Anna Milan wrote:

  Changed status of these two services registered to 'Submitted'https://www.ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=SUBMITTED&serviceUrl=&search=List+Collection+Sources
  However, I'm still seeing the same element repeated in this
    file: http://dm1.caricoos.org/thredds/ncml/buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc?catalog=http%3A%2F%2Fdm1.caricoos.org%2Fthredds%2Fcatalog%2Fbuoys%2FHistorical%2FPR3%2Fcatalog.html&dataset=buoys%2FHistorical%2FPR3%2FDSG_PR3.accelerometer2.historical.nc
  Under the Services group in the XML. 
    (group name="services")
  —
    Reply to this email directly or view
      it on GitHub.
amilan17 commented 10 years ago

It is just an example. There are many services that have this duplication. I tried to capture this in the notes of the collectionSource table. https://ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=FAILS+TRANSLATION&serviceUrl=&search=List+Collection+Sources

Anna ~~~~~~~ Anna.Milan@noaa.gov, 303-497-5099 NOAA/NESDIS/NGDC

http://www.ngdc.noaa.gov/metadata/emma ~~~~~~~

On Thu, Jul 3, 2014 at 6:48 AM, jcapella notifications@github.com wrote:

Is this the only instance of duplication or just an example?On 7/2/2014 1:57 PM, Anna Milan wrote:

Changed status of these two services registered to 'Submitted' https://www.ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=SUBMITTED&serviceUrl=&search=List+Collection+Sources However, I'm still seeing the same element repeated in this file: http://dm1.caricoos.org/thredds/ncml/buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc?catalog=http%3A%2F%2Fdm1.caricoos.org%2Fthredds%2Fcatalog%2Fbuoys%2FHistorical%2FPR3%2Fcatalog.html&dataset=buoys%2FHistorical%2FPR3%2FDSG_PR3.accelerometer2.historical.nc Under the Services group in the XML. (group name="services")

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/ioos/registry/issues/34#issuecomment-47924901.

jcapella commented 10 years ago
Just removed the duplicate opendap ncdods service entry
  Under the "Access" section I see that number 2 and 10 are
    identical and are both opendap services. The corresponding xml
    document is at http://dm1.caricoos.org/thredds/dodsC/buoys/Historical/PR3/catalog.xml?dataset=buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc
    and the section describing the services contains two lines that
    both correspond to opendap...
  <service name="odap" serviceType="OPENDAP"
      base="/thredds/dodsC/"/>
    and<service name="ncdods" serviceType="OPENDAP"
      base="/thredds/dodsC/"/>
  I have no idea which one is correct or the meaning of name="odap"
    and name="ncdods".

Please let us know if this solves the problem.
JorgeOn 7/3/2014 11:24 AM, Anna Milan wrote:
It is just an example. There are many services that
  have this duplication.

  I tried to capture this in the notes of the collectionSource
  table.
  https://ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=FAILS+TRANSLATION&serviceUrl=&search=List+Collection+Sources

  Anna

  *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
  Anna.Milan@noaa.gov, 303-497-5099

  NOAA/NESDIS/NGDC
  http://www.ngdc.noaa.gov/metadata/emma

  *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*

  On Thu, Jul 3, 2014 at 6:48 AM, jcapella
  <notifications@github.com> wrote:

  >

  > Is this the only instance of duplication or just an
  example?On 7/2/2014

  > 1:57 PM, Anna Milan wrote:

  >

  > Changed status of these two services registered to
  'Submitted'

  >

https://www.ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=SUBMITTED&serviceUrl=&search=List+Collection+Sources

However, I'm still seeing the same element repeated in this

  > file:

  >

http://dm1.caricoos.org/thredds/ncml/buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc?catalog=http%3A%2F%2Fdm1.caricoos.org%2Fthredds%2Fcatalog%2Fbuoys%2FHistorical%2FPR3%2Fcatalog.html&dataset=buoys%2FHistorical%2FPR3%2FDSG_PR3.accelerometer2.historical.nc

Under the Services group in the XML.

  > (group name="services")

  >

  > —

  > Reply to this email directly or view

  > it on GitHub.

  >

  > —

  > Reply to this email directly or view it on GitHub

  >

https://github.com/ioos/registry/issues/34#issuecomment-47924901.

— Reply to this email directly or view it on GitHub.

amilan17 commented 10 years ago

I will test the results of this registration again tomorrow. https://ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=SUBMITTED&serviceUrl=&search=List+Collection+Sources

Anna ~~~~~~~ Anna.Milan@noaa.gov, 303-497-5099 NOAA/NESDIS/NGDC

http://www.ngdc.noaa.gov/metadata/emma ~~~~~~~

On Thu, Jul 3, 2014 at 12:12 PM, jcapella notifications@github.com wrote:

Just removed the duplicate opendap ncdods service entry

Under the "Access" section I see that number 2 and 10 are identical and are both opendap services. The corresponding xml document is at http://dm1.caricoos.org/thredds/dodsC/buoys/Historical/PR3/catalog.xml?dataset=buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc and the section describing the services contains two lines that both correspond to opendap... <service name="odap" serviceType="OPENDAP" base="/thredds/dodsC/"/> and<service name="ncdods" serviceType="OPENDAP" base="/thredds/dodsC/"/> I have no idea which one is correct or the meaning of name="odap" and name="ncdods".

Please let us know if this solves the problem.

JorgeOn 7/3/2014 11:24 AM, Anna Milan wrote: It is just an example. There are many services that have this duplication.

I tried to capture this in the notes of the collectionSource table.

https://ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=FAILS+TRANSLATION&serviceUrl=&search=List+Collection+Sources

Anna

~~~~~~~ Anna.Milan@noaa.gov, 303-497-5099

NOAA/NESDIS/NGDC http://www.ngdc.noaa.gov/metadata/emma

~~~~~~~

On Thu, Jul 3, 2014 at 6:48 AM, jcapella notifications@github.com wrote:

Is this the only instance of duplication or just an example?On 7/2/2014

1:57 PM, Anna Milan wrote:

Changed status of these two services registered to 'Submitted'

https://www.ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=SUBMITTED&serviceUrl=&search=List+Collection+Sources

However, I'm still seeing the same element repeated in this

file:

http://dm1.caricoos.org/thredds/ncml/buoys/Historical/PR3/DSG_PR3.accelerometer2.historical.nc?catalog=http%3A%2F%2Fdm1.caricoos.org%2Fthredds%2Fcatalog%2Fbuoys%2FHistorical%2FPR3%2Fcatalog.html&dataset=buoys%2FHistorical%2FPR3%2FDSG_PR3.accelerometer2.historical.nc

Under the Services group in the XML.

(group name="services")

Reply to this email directly or view

it on GitHub.

Reply to this email directly or view it on GitHub

https://github.com/ioos/registry/issues/34#issuecomment-47924901.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/ioos/registry/issues/34#issuecomment-47965180.

amilan17 commented 10 years ago

@jcapella It looks like transformation succeeded! However, EMMA only picks up 6 metadata records from http://dm2.caricoos.org/thredds/catalog.xml service. Does this catalog include all of the other services registered with CariCOOS?

Can you please review all services registered with CariCOOS to ensure that we have the list of the latest and greatest? https://ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=&serviceUrl=&search=List+Collection+Sources

Thanks, Anna

jcapella commented 10 years ago
Great!  At last.
Now that the multiple opendap service issue has been solved should
we move on to another github slot?
In the Collection Source List we see several old service entries
that are no more.  Here is the list of top level entires in our
catalog.  And yes, everything is within, or referenced, in
catalog.xml.
Following the same order as in the figure below, under Catalog
http://dm2.caricoos.org/thredds/
        catalog/buoys/catalog.html
        UMO_SOS_historical_realtime_agg_caricoos.html
        catalog/roms/catalog.html
        catalog/content/Rincon_Waverider/catalog.html
        catalog/content/swan/catalog.html
        caricoos_swan.html
        catalog/content/esa_globcolour/catalog.html
        esa_globcolour_agg.html
        catalog/content/Merged_DEM/catalog.html
        catalog/content/Mesonet/catalog.html
        catalog/content/nasa_oceancolor/catalog.html
        catalog/content/nws/catalog.html
        catalog/wrf_archive/catalog.html
The esa_globcolour were recently aggregated and we will be
aggregating roms, nasa_oceancolor, etc., however, our modelers will
still need access to the piecewise wind and wrf data collections.
Note that we set it up so that now dm1.caricoos.org and
dm2.caricoos.org BOTH point to the currently "active" TDS so this
should not be a problem in the future.  
And yes, we need to add more metadata to many of the services.
BTW, the buoy and Mesonet data are ncSOS compliant, should they
appear as such?
Thanks for all you help, and patience,
Jorge
On 7/7/2014 12:44 PM, Anna Milan wrote:

  @jcapella 
    It looks like transformation succeeded! 
    However, EMMA only picks up 6 metadata records from http://dm2.caricoos.org/thredds/catalog.xml
    service. Does this catalog include all of the other services
    registered with CariCOOS? 
  Can you please review all services registered with CariCOOS to
    ensure that we have the list of the latest and greatest? https://ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=&serviceUrl=&search=List+Collection+Sources
  Thanks, Anna
  —
    Reply to this email directly or view
      it on GitHub.
robragsdale commented 10 years ago

@jcapella I looked at the services being harvested from http://dm2.caricoos.org/thredds/catalog.xml. Only these from your list have been harvested http://dm2.caricoos.org/thredds/catalog/content/Rincon_Waverider/catalog.html http://dm2.caricoos.org/thredds/catalog/content/Merged_DEM/catalog.html http://dm2.caricoos.org/thredds/catalog/content/swan/catalog.html

I'll will check tomorrow to see if this changes. Other lower level services were submitted (updated) by Anna today that I will follow up on them tomorrow, too.

Do we have the status of all the old services listed as "for removal" so these can be cleaned out of the registry?

Thanks for your help I will follow up again tomorrow.

Rob

amilan17 commented 10 years ago

@jcapella @robragsdale Current status of registered services:

Approved https://ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=APPROVED&serviceUrl=&search=List+Collection+Sources

Fails Translation - mostly because dates need to be formatted to comply with ISO 8601 format. https://ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=FAILS+TRANSLATION&serviceUrl=&search=List+Collection+Sources

Submitted - think there should be aggregate files instead of daily files? https://ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=3573894&componentId=&serviceType=&serviceStatus=SUBMITTED&serviceUrl=&search=List+Collection+Sources

rsignell-usgs commented 10 years ago

I took a look at the catalogs listed as Fails Translation and can't see that there is any problem. The dates look fine on the OPeNDAP side, in the ncISO, and they harvest without errors into geoportal on my end.

In the NetCDF files, the time units are units: days since 1858-11-17 00:00:00 +0:00 which is CF-compliant.

In the ISO metadata generated by ncISO (e.g. http://dm2.caricoos.org/thredds/iso/buoys/Historical/PR2/DSG_PR2.diagnostics.historical.nc?catalog=http%3A%2F%2Fdm2.caricoos.org%2Fthredds%2Fcatalog%2Fbuoys%2FHistorical%2FPR2%2Fcatalog.html&dataset=buoys%2FHistorical%2FPR2%2FDSG_PR2.diagnostics.historical.nc) the bounds look okay also:

<gmd:temporalElement>
<gmd:EX_TemporalExtent id="boundingTemporalExtent">
<gmd:extent>
<gml:TimePeriod gml:id="d204915">
<gml:description>seconds</gml:description>
<gml:beginPosition>2010-07-23T15:00:00Z</gml:beginPosition>
<gml:endPosition>2014-05-01T09:59:59Z</gml:endPosition>
</gml:TimePeriod>
</gmd:extent>
</gmd:EX_TemporalExtent>

and when I tried harvesting one of the catalogs (http://dm2.caricoos.org/thredds/catalog/buoys/Historical/PR2/catalog.xml) into my geoportal server, it harvested all 5 datasets without errors. 7-18-2014 6-44-42 am

jcapella commented 10 years ago

Thanks Rich. I will be away for a few days, will check again when we get back.

On 7/18/2014 7:06 AM, Rich Signell wrote:

I took a look at the catalogs listed as Fails Translation and can't see that there is any problem. The dates look fine on the OPeNDAP side, in the ncISO, and they harvest without errors into geoportal on my end.

In the NetCDF files, the time units are |units: days since 1858-11-17 00:00:00 +0:00| which is CF-compliant.

In the ISO metadata generated by ncISO (e.g. http://dm2.caricoos.org/thredds/iso/buoys/Historical/PR2/DSG_PR2.diagnostics.historical.nc?catalog=http%3A%2F%2Fdm2.caricoos.org%2Fthredds%2Fcatalog%2Fbuoys%2FHistorical%2FPR2%2Fcatalog.html&dataset=buoys%2FHistorical%2FPR2%2FDSG_PR2.diagnostics.historical.nc) the bounds look okay also:

|gmd:temporalElement

gmd:extent gml:descriptionseconds/gml:description gml:beginPosition2010-07-23T15:00:00Z/gml:beginPosition gml:endPosition2014-05-01T09:59:59Z/gml:endPosition /gml:TimePeriod /gmd:extent /gmd:EX_TemporalExtent | and when I tried harvesting one of the catalogs (http://dm2.caricoos.org/thredds/catalog/buoys/Historical/PR2/catalog.xml) into my geoportal server, it harvested all 5 datasets without errors. 7-18-2014 6-44-42 am https://cloud.githubusercontent.com/assets/1872600/3625437/8a34c602-0e6b-11e4-98e8-0ccc2a0a14d8.png — Reply to this email directly or view it on GitHub https://github.com/ioos/registry/issues/34#issuecomment-49419473.
rsignell-usgs commented 10 years ago

@jcapella , one quick thing: all the catalogs that start with dm1.caricoos.org should now be dm2.caricoos.org, right?

amilan17 commented 10 years ago

@rsignell-usgs: the nasa_oceancolor services have dates that look like <attribute name="date_created" value="20140718T000734Z"/>

the transform is expecting the date to look like this 2014-07-18T00:07:34Z

rsignell-usgs commented 10 years ago

Ah, date_created. Well that sucks. But at least I understand the problem now. Sorry!

dpsnowden commented 10 years ago

Can the transform be adjusted? I think both are valid ISO 8601.

Sent from my iPhone

On Jul 18, 2014, at 2:07 PM, Anna Milan notifications@github.com wrote:

@rsignell-usgs https://github.com/rsignell-usgs: the nasa_oceancolor services have dates that look like

the transform is expecting the date to look like this 2014-07-18T00:07:34Z

— Reply to this email directly or view it on GitHub https://github.com/ioos/registry/issues/34#issuecomment-49462004.

rsignell-usgs commented 10 years ago

@amilan17 did this get fixed elsewhere so that these should work now?

amilan17 commented 10 years ago

dm2 service appears to be down - cannot verify.

Anna ~~~~~~~ Anna.Milan@noaa.gov, 303-497-5099 NOAA/NESDIS/NGDC

http://www.ngdc.noaa.gov/metadata/emma ~~~~~~~

On Thu, Oct 9, 2014 at 12:00 PM, Rich Signell notifications@github.com wrote:

@amilan17 https://github.com/amilan17 did this get fixed elsewhere so that these should work now?

— Reply to this email directly or view it on GitHub https://github.com/ioos/registry/issues/34#issuecomment-58550697.