search

ioos / registry

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

Add NANOOS/SWFRC ERDDAP datasets #51

Closed emiliom closed 9 years ago

emiliom commented 9 years ago

NANOOS would like to add 4 datasets to the IOOS registry. They are an Aqua-MODIS remote sensing product for monthly climatologies (2002-2013) and anomalies (2002- Jun 2014) of SST and Sea-surface Chlorophyll a produced by @crisien at OSU (Craig is part of the NANOOS DMAC team). But there's a tricky aspect, that hopefully won't be a problem. For wider dissemination, these datasets are being distributed via the NOAA SWRC/Coastwatch ERDDAP instance. Ideally we'd like to keep them there (among the gazillion other datasets hosted there), but associate them with NANOOS on the IOOS registry/catalog/geoportal.

Service URL's (or "Accepted Registry Services"?):

Service Point of Contact: Well, is it @crisien, Roy Mendelsohn/Bob Simons, or a combination? Craig is definitely the dataset Point of Contact.

Service Organization: Ditto. We definitely want to associate these datasets with NANOOS, but the service endpoints are hosted by SWRC.

We are open to extracting the ISO XML's and hosting them on a NANOOS WAF (with manual tweaks if required), if that makes the process easier. But for the foreseeable future we'd like to keep the datasets and services where they are.

Is there a precedent for this arrangement on the IOOS Catalog? We hope so!

scross015 commented 9 years ago

I think this is analogous to our situation with OceanNOMADS, and represents a concern that we should look into. Like Roy, we are serving out datasets (via THREDDS/ERDDAP) that originate elsewhere. In our case it is ocean model data from Navy. We are clearly the POC when it comes to the data services-- Navy would not be able to answer even the first question about the services-- while Navy is clearly the data content POC. There needs to be a way to include both contacts and distinguish their respective roles.

rsignell-usgs commented 9 years ago

In the NetCDF ACDD attributes, you can have creator_name, publisher_name, and also contributor_name (where you should specify the contributor_role) see: http://wiki.esipfed.org/index.php/Attribute_Convention_for_Data_Discovery_1-1 for more details, and to see how to specify this directly in ISO, if that is your preference.

emiliom commented 9 years ago

Thanks, @scross015 . For reference, I assume this OceanNOMADS dataset is the same one mentioned on issue #49? Is the dataset (and service) on the ioos catalog? If so, can you provide a URL? It sounds like your concern hasn't been fully addressed yet.

@rsignell-usgs , thanks for the pointers to ACDD attributes. We can certainly edit those as needed.

As @scross015 said, I think this raises a couple of broader issues (so I'm pinging @dpsnowden ):

So, it looks to me like there's no way to do what we want: keep these datasets where they are (served via SWFSC ERDDAP services), but register them with IOOS in such a way that they are clearly associated with NANOOS in the IOOS Catalog. Is that correct?

dpsnowden commented 9 years ago

@emiliom the short answer is no, it is not correct that you cannot register a dataset from the SWFSC ERDDAP as a NANOOS asset. The association of a service to a provider is done at the time of registration (new gh issue here, and/or email to ioos.catalog@noaa.gov) as you have done. The metadata is harvested into a WAF named for the provider, in your case NANOOS. The WAF structure is mirrored as Geoportal collections which you can see when you browse the NGDC Geoportal. The WAF structure is replicated on the Catalog during the harvesting process so the association should hold. There will undoubtedly be problems that we will address as we can.

There is currently no concept of the a data set provider in the catalog UI. Perhaps there should be and the ACDD attributes are a good first guess as a location to retrieve that info. Would you submit an issue on the catalog repo requesting that enhancement? I will cc the catalog developer team but it would be great if users such as yourself felt comfortable requesting new features using the issues. It is the best way that we can prioritize the work. @kknee @lukecambell, FYI.

@scross015 the Navy models we're referring to were registered as Navy data sets. I'm certainly open to revisiting that. We did that early on when we were figuring this whole thing out and it seemed to make sense at the time. I understand your logic and I wish we had a better solution for representing the service/data provider equally. We can discuss it in a different issue now or we can revisit if/when we implement separate data and service provider functionality in the Catalog.

This issue was originally intended as a registration notification. I've assigned it to @robragsdale and he'll see it through the process. Let's move a conversation of specific enhancements to another issue or better yet to the github.com/ioos/catalog. I hope that increasingly the Service Registry function will fall into the background and we can concentrate on evolving the catalog based on user input. The service registry then just evolves to support it. For me, it's confusing to try to keep the mental map of "when the registry does this the catalog does that". Hopefully we can get there soon.

@emiliom at the risk of carrying on tangential conversations here, I'm generally not too concerned with duplication now. It doesn't seem like a problem yet and as long as the metadata is clear and accurate, I don't care if there are two records, at this point. That will change I'm sure but we couldn't address everything at once and it's been tough training ourselves to register at all. I chose to focus on that first. If you have a case where duplication is actually damaging, as opposed to a little annoying, I'd love to discuss it elsewhere.

scross015 commented 9 years ago

@emiliom- Yes, the services we have registered can be found at http://catalog.ioos.us/services/filter/NAVY/DAP.

@dpsnowden- if I understand you correctly, implementing separate data/service provider functionality in the Catalog should allow data consumers to correctly identify the right POC to address their particular concern. Assuming that's the case, I'm all for it.

dpsnowden commented 9 years ago

Since nothing has been implemented yet, we could conceivably do anything. But, it sounds like that is functionality that we want to have.

FWIW, this capability does partly exist. The catalog is partly visualization, and partly a program management tool and partly a discover tool. It isn't a place to actually download data. Data consumers will always access data from the source, i.e. your THREDDS. If you use ACDD correctly, a data consumer can theoretically already identify the data provider when they access the data from your server. Assuming they read of course. I admit that the UI on the IOOS catalog could be more clear.

robragsdale commented 9 years ago

@emiliom to bring this back to your request to register these four services, I recommend that the Bob Simons be the 'data service provider' ('component') because as you stated at the top these data sets are being distributed from the NOAA SWRC/Coastwatch ERDDAP instance. NANOOS will be listed as the 'dataset/content provider' ('record set'). Are these the correct associations for these services? I think this is best that we can do with the registry now. I created a new issue #155 that addresses the enhancements that you have brought up.

http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/osuSstClimate_iso19115.xml http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/osuChlaClimate_iso19115.xml http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/osuSstAnom_iso19115.xml http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/osuChlaAnom_iso19115.xml

emiliom commented 9 years ago

Thanks @robragsdale ! First, a small correction: I incorrectly wrote "NOAA SWFRC", but it's "NOAA SWFSC". It really does seem like SWFSC needs to be the "service provider".

As for NANOOS being listed as 'dataset/content provider' ('record set'), that seems appropriate, but I don't entirely know what that translates into, in practice, on the IOOS Catalog (http://catalog.ioos.us/). What we'd like to see is these datasets being discoverable on the IOOS Catalog when one navigates to NANOOS, specially under these two listings: http://catalog.ioos.us/providers/NANOOS http://catalog.ioos.us/datasets/filter/NANOOS/null It's still not clear to me if that will happen.

Those URL's are the correct links to the ISO metadata auto-generated by ERDDAP. But given recent traffic about some issues with service description in ERDDAP-generated ISO (I tried locating the github issue, but couldn't), if it makes a big difference we can download these XML's, tweak them, and upload to a NANOOS WAF. Let me know.

(Listing Craig Risien @crisien here to keep him in the loop, since he's the actual contact person and creator for this dataset)

dpsnowden commented 9 years ago

We need to loop in the catalog folks. I don't know how the "dataset/content provider" element in EMMA is related to a field in the CSW interface to Geoportal. As I recall, there are certain elements in the EMMA interface that aren't actually recorded in the ISO document that is indexed into the Geoportal. The CSW is THE interface between the catalog and the registry. If information doesn't find it's way into the CSW response it isn't in the catalog.

@amilan17 and @lukecampbell or @daf are really the only folks who can definitively answer both sides of this question.

Logically it makes sense that SWFSC be acknowledged but we don't want to lose sight of the goal of having NANOOS be associated with the data sets in any inventory we compile.

emiliom commented 9 years ago

@dpsnowden thank so much for your helpful responses and follow-up actions. That's great. I've added comments and a new issue on the catalog, to follow up on the tangential conversations.

robragsdale commented 9 years ago

@emiliom I've registered the NANOOS datasets served through ERDDAP https://www.ngdc.noaa.gov/docucomp/collectionSource/list?max=10&serviceStatus=&recordSetId=&search=List+Collection+Sources&layout=fluid&serviceType=ERDDAP&offset=0&serviceUrl=&componentId=

I'll track these through the harvesting process. The issues with the catalog harvesting ERDDAP services is addressed in https://github.com/ioos/catalog/issues/35.

emiliom commented 9 years ago

@robragsdale thank you for both registering the datasets and pointing me to the ERDDAP services catalog issue.

dpsnowden commented 9 years ago

What needs to happen before this issue is closed? Also, did anyone actually ask @BobSimons if he would like to be the point of contact for these data sets? I don't want us to get in the habit of assigning people responsibilities without their consent.

emiliom commented 9 years ago

Thanks for including @BobSimons ; I didn't know his github handle, and figure @robragsdale had contacted him already.

As for closing the issue, what's the standard practice? I'm assuming it gets closed when the service & datasets are in the catalog (catalog.ioos.us, not just the NGDC IOOS GeoPortal) and have no first-order issues? By the end of the week, hopefully? That's your and Rob's call.

dpsnowden commented 9 years ago

Let's wait for resolution of #52 before closing this.

robragsdale commented 9 years ago

@BobSimons I was asked to register four data sets produced by @emiliom NANOOS (the content is from @crisien at OSU), but served through ERDDAP. The IOOS registration process is such that we assign a point of contact for the service and point of contact for the content. I listed you as the point of contact for the service before asking you if you were ok with this or even the right person at SWFSC. I am sorry for that.
Would you be ok with being the POC or is there another person at SWFSC that I can list? Their should not be much in the way of added workload. The POC for the service should be available to let us know if the service URL changes, what the new url is, or goes down so that we can update as appropriate in the registry/catalog. For your information the services that we registered for NANOOS are: http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/osuSstClimate_iso19115.xml http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/osuChlaClimate_iso19115.xml http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/osuSstAnom_iso19115.xml http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/osuChlaAnom_iso19115.xml If you have any concerns about serving as the POC for these urls, would like to offer another person to be the POC or have any questions please feel free to let me know.

emiliom commented 9 years ago

Thank you, @robragsdale . Just as a bit of clarification, to minimize head-scratching, I've had no role at all (other than giving opinions) with these particular datasets or their distribution via the SWFSC ERDDAP. It's all been between @crisien and SWFSC (I can't remember if that was Roy or @BobSimons). Here, I'm just serving as a middleman to facilitate the registration of the datasets with IOOS.

crisien commented 9 years ago

@robragsdale, @emiliom, and @BobSimons, I worked with Roy Mendelssohn to migrate these four data products to SWFSC.

amilan17 commented 9 years ago

On Mon, Sep 22, 2014 at 1:53 PM, robragsdale notifications@github.com wrote:

I've registered the NANOOS datasets served through ERDDAP https://www.ngdc.noaa.gov/docucomp/collectionSource/list?max=10&serviceStatus=&recordSetId=&search=List+Collection+Sources&layout=fluid&serviceType=ERDDAP&offset=0&serviceUrl=&componentId=

Hi All, The registry does not "know" how to harvest individual ISO metadata files. As @emiliom suggested, I recommend that NANOOS obtain the ERDDAP records and publish them to a local WAF.

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

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

BobSimons commented 9 years ago

On 2014-09-23 10:02 AM, robragsdale wrote:

@BobSimons https://github.com/BobSimons I was asked to register four data sets produced by @emiliom https://github.com/emiliom NANOOS (the content is from @crisien https://github.com/crisien at OSU), but served through ERDDAP. The IOOS registration process is such that we assign a point of contact for the service and point of contact for the content. I listed you as the point of contact for the service before asking you if you were ok with this or even the right person at SWFSC. I am sorry for that.

Would you be ok with being the POC or is there another person at SWFSC that I can list? Their should not be much in the way of added workload. The POC for the service should be available to let us know if the service URL changes, what the new url is, or goes down so that we can update as appropriate in the registry/catalog. For your information the services that we registered for NANOOS are: http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/osuSstClimate_iso19115.xml http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/osuChlaClimate_iso19115.xml http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/osuSstAnom_iso19115.xml http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/osuChlaAnom_iso19115.xml <http%0A%20://coast%0A%20watch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/osuChlaAnom_iso19115.xml> If you have any concerns about serving as the POC for these urls, would like to offer another person to be the POC or have any questions please feel free to let me know.

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

Yes, I am the appropriate person to be listed as the POC for these and other datasets which are made available via the SWFSC/ERD ERDDAP. If you or others have any questions about these services, please let me know.

[Several of the other emails for this ticket incorrectly refer to "SWRC". It is correct to refer to SWFSC/ERD.]

Thanks.

Sincerely,

Bob Simons IT Specialist Environmental Research Division NOAA Southwest Fisheries Science Center 1352 Lighthouse Ave Pacific Grove, CA 93950-2079 Phone: (831)333-9878 (Changed 2014-08-20) Fax: (831)648-8440 Email: bob.simons@noaa.gov

The contents of this message are mine personally and do not necessarily reflect any position of the Government or the National Oceanic and Atmospheric Administration. <>< <>< <>< <>< <>< <>< <>< <>< <>< <><

BobSimons commented 9 years ago

On 2014-09-23 10:35 AM, Craig Risien wrote:

@robragsdale https://github.com/robragsdale, @emiliom https://github.com/emiliom, and @BobSimons https://github.com/BobSimons, I worked with Roy Mendelssohn to migrate these four data products to SWFSC.

Yes. And if IOOS registers the SWFSC/ERD THREDDS services for these datasets, Roy should be listed as the POC for those services. http://oceanwatch.pfeg.noaa.gov/thredds/Satellite/OSU/blooms/catalog.html http://oceanwatch.pfeg.noaa.gov/thredds/Satellite/OSU/blooms/catalog.html

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

Sincerely,

Bob Simons IT Specialist Environmental Research Division NOAA Southwest Fisheries Science Center 1352 Lighthouse Ave Pacific Grove, CA 93950-2079 Phone: (831)333-9878 (Changed 2014-08-20) Fax: (831)648-8440 Email: bob.simons@noaa.gov

The contents of this message are mine personally and do not necessarily reflect any position of the Government or the National Oceanic and Atmospheric Administration. <>< <>< <>< <>< <>< <>< <>< <>< <>< <><

crisien commented 9 years ago

As far as I know the OSU blooms data product was not developed by NANOOS and shouldn't be registered by IOOS as a NANOOS service/data product.

emiliom commented 9 years ago

@amilan17 : so, with ERDDAP services, the options for the registry are to harvest either all metadata records from ERDDAP (eg, http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/), or a subset on a custom WAF. Right?

@crisien, thanks for the clarifications.

@BobSimons, thanks for the confirmation about being the POC, and for pointing out that these records come from a SWFSC/ERD THREDDS server (Craig had mentioned this, but I keep forgetting). BTW, the screwed-up "SWFRC" was my fault; I opened this issue using that wrong acronym, and didn't realize the mistake until later.

In re-checking all these links, I just noticed a new kink: 3 of the 4 datasets have disappeared from the SWFSC/ERD ERDDAP. These are the Chlorophyll climatology and the two anomalies. This ERDDAP search link used to correctly return the 4 datasets, and now it returns only the SST climatology. @crisien and @BobSimons, is anything being changed right now? The records are all still present on the SWFSC/ERD THREDDS: http://oceanwatch.pfeg.noaa.gov/thredds/Satellite/OSU/chlaAnom/catalog.html http://oceanwatch.pfeg.noaa.gov/thredds/Satellite/OSU/sstAnom/catalog.html Though I ran into errors when trying to view them via THREDDS/Godiva2

@robragsdale and @amilan17 , assuming the datasets were all working on both ERDDAP and THREDDS, do you have a preference for which service we should register from? If we go with THREDDS, the registry can pull in the metadata directly from ncISO, right?

amilan17 commented 9 years ago

On Tue, Sep 23, 2014 at 2:03 PM, Emilio Mayorga notifications@github.com wrote:

@amilan17 https://github.com/amilan17 : so, with ERDDAP services, the options for the registry are to harvest either all metadata records from ERDDAP (eg, http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/), or a subset on a custom WAF. Right?

Correct.

@robragsdale https://github.com/robragsdale and @amilan17 https://github.com/amilan17 , assuming the datasets were all working on both ERDDAP and THREDDS, do you have a preference for which service we should register from? If we go with THREDDS, the registry can pull in the metadata directly from ncISO, right?

I think ERDDAP metadata might result in more complete ISO than THREDDS... But I haven't formally tested it (yet).

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

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

BobSimons commented 9 years ago

On 2014-09-23 1:03 PM, Emilio Mayorga wrote:

@amilan17 https://github.com/amilan17 : so, with ERDDAP services, the options for the registry are to harvest either all metadata records from ERDDAP (eg, http://coastwatch.pfeg.noaa.gov/erddap/metadata/iso19115/xml/), or a subset on a custom WAF. Right?

@crisien https://github.com/crisien, thanks for the clarifications.

@BobSimons https://github.com/BobSimons, thanks for the confirmation about being the POC, and for pointing out that these records come from a SWFSC/ERD THREDDS server (Craig had mentioned this, but I keep forgetting). BTW, the screwed-up "SWFRC" was my fault; I opened this issue using that wrong acronym, and didn't realize the mistake until later.

In re-checking all these links, I just noticed a new kink: 3 of the 4 datasets have disappeared from the SWFSC/ERD ERDDAP. These are the Chlorophyll climatology and the two anomalies. This ERDDAP search link used to correctly return the 4 datasets, and now it returns only the SST climatology http://coastwatch.pfeg.noaa.gov/erddap/search/index.html?searchFor=OSU%20MODIS%20Climatology. @crisien https://github.com/crisien and @BobSimons https://github.com/BobSimons, is anything being changed right now? The records are all still present on the SWFSC/ERD THREDDS: http://oceanwatch.pfeg.noaa.gov/thredds/Satellite/OSU/chlaAnom/catalog.html http://oceanwatch.pfeg.noaa.gov/thredds/Satellite/OSU/sstAnom/catalog.html Though I ran into errors when trying to view them via THREDDS/Godiva2

We're having problems with one of our RAIDs. Many datasets, including the OSU datasets, are temporarily unavailable from THREDDS and from ERDDAP. They will return.

@robragsdale https://github.com/robragsdale and @amilan17 https://github.com/amilan17 , assuming the datasets were all working on both ERDDAP and THREDDS, do you have a preference for which service we should register from? If we go with THREDDS, the registry can pull in the metadata directly from ncISO, right?

ERDDAP and THREDDS are different ways to access the same data. Both offer ISO 19115 metadata, but generated by different software, so will be slightly different (e.g., have a slightly different set of keywords, offer different service endpoints).

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

Sincerely,

Bob Simons IT Specialist Environmental Research Division NOAA Southwest Fisheries Science Center 1352 Lighthouse Ave Pacific Grove, CA 93950-2079 Phone: (831)333-9878 (Changed 2014-08-20) Fax: (831)648-8440 Email: bob.simons@noaa.gov

The contents of this message are mine personally and do not necessarily reflect any position of the Government or the National Oceanic and Atmospheric Administration. <>< <>< <>< <>< <>< <>< <>< <>< <>< <><

emiliom commented 9 years ago

@robragsdale and @amilan17 , we've now uploaded the 4 iso xml's from COASTWATCH ERD ERDDAP to a NANOS WAF: http://data.nanoos.org/metadata/coastwatcherded/osuclm

@robragsdale , please change the EMMA entry to this new location, instead of the 4 individual URL's from COASTWATCH ERD ERDDAP.

We haven't made any changes to these iso files. I'd be happy to make the manual service description edits mentioned in catalog issue 35 if that will we make the GeoPortal harvesting much more robust. Let me know if I should. I know that's not the long-term solution, but I don't have a problem making this temporary hack on my end, since it's only 4 xml's.

@BobSimons , thanks for your input earlier this week. Looks like your hardware problems have been resolved.

BobSimons commented 9 years ago

1) I just changed ERDDAP to produce the new gml:protocol values in the ISO 19115 documents. If you harvested the ISO 19115's from ERDDAP in the last 90 minutes, please do it again. But...

2) Didn't Craig Risien (the data creator) say: _crisien https://github.com/crisien_commented2 days ago https://github.com/ioos/registry/issues/51#issuecomment-56561952

As far as I know the OSU blooms data product was not developed by NANOOS

and shouldn't be registered by IOOS as a NANOOS service/data product.

So is it appropriate of NANOOS to "associate them with NANOOS"? Which metadata entries are you going to change? Is Craig okay with this? (I think it's his decision.)

On 2014-09-25 12:45 PM, Emilio Mayorga wrote:

@robragsdale https://github.com/robragsdale and @amilan17 https://github.com/amilan17 , we've now uploaded the 4 iso xml's from COASTWATCH ERD ERDDAP to a NANOS WAF: http://data.nanoos.org/metadata/coastwatcherded/osuclm

@robragsdale https://github.com/robragsdale , please change the EMMA entry to this new location, instead of the 4 individual URL's from COASTWATCH ERD ERDDAP.

We haven't made any changes to these iso files. I'd be happy to make the manual service description edits mentioned in catalog issue 35 https://github.com/ioos/catalog/issues/35 if that will we make the GeoPortal harvesting much more robust. Let me know if I should. I know that's not the long-term solution, but I don't have a problem making this temporary hack on my end, since it's only 4 xml's.

@BobSimons https://github.com/BobSimons , thanks for your input earlier this week. Looks like your hardware problems have been resolved.

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

Sincerely,

Bob Simons IT Specialist Environmental Research Division NOAA Southwest Fisheries Science Center 1352 Lighthouse Ave Pacific Grove, CA 93950-2079 Phone: (831)333-9878 (Changed 2014-08-20) Fax: (831)648-8440 Email: bob.simons@noaa.gov

The contents of this message are mine personally and do not necessarily reflect any position of the Government or the National Oceanic and Atmospheric Administration. <>< <>< <>< <>< <>< <>< <>< <>< <>< <><

crisien commented 9 years ago

I believe the four ISO XML files @emiliom mentioned are the four associated with the MODIS SST and CHLA climatology and anomaly fields not the OSU blooms data product. Correct @emiliom?

robragsdale commented 9 years ago

@emiliom I get a 403 Forbidden/nginx/1.1.19 from the URL http://data.nanoos.org/metadata/coastwatcherded/osuclm.

emiliom commented 9 years ago

@BobSimons , what @crisien says is correct: these 4 dataset are not the OSU bloom products, but Craig's Chl & SST climatologies and monthly anomalies. Craig and I are in close contact every step of the way, so no worries there.

@BobSimons , great to hear about your upgrade to gml:protocol. That's awesome!

@robragsdale , the WAF directory itself (http://data.nanoos.org/metadata/coastwatcherded/osuclm) doesn't allow browsing, as a general safe web practice. You can get to the individual file URL's within the directory, like this one: http://data.nanoos.org/metadata/coastwatcherded/osuclm/osuChlaAnom_iso19115.xml But maybe I didn't realize that browsing must be enabled in order for the directory to be a bona fide "WAF"? I guess I see the logic in that. I'll try to change our settings soon.

emiliom commented 9 years ago

@robragsdale, http://data.nanoos.org/metadata/coastwatcherded/osuclm is now browseable. I've also updated the iso xml's just now (redownloaded them from ERDDAP).

robragsdale commented 9 years ago

@emiliom I have submitted the updated WAF link to the Registry (https://www.ngdc.noaa.gov/docucomp/collectionSource/list?recordSetId=2604647&componentId=&serviceType=ISOWAF&serviceStatus=&serviceUrl=&search=List+Collection+Sources). I'll follow it through the harvesting process.

emiliom commented 9 years ago

Thanks, @robragsdale

emiliom commented 9 years ago

@robragsdale and @amilan17, can you give us an update on the status of these records? I see them on this NGDC registry listing, but not downstream, including NGDC Geoportal. Thanks.

robragsdale commented 9 years ago

@emiliom the services are in Geoportal (http://www.ngdc.noaa.gov/geoportal/catalog/search/browse/browse.page) now. You will see them if you browse on NANOOS. They have not reached the Catalog yet.

emiliom commented 9 years ago

Thanks, @robragsdale . That's great. I assume they'll be harvested into the Catalog overnight?

robragsdale commented 9 years ago

@emiliom It should be harvested by the catalog tonight if all goes well.

emiliom commented 9 years ago

The records (4 datasets + 8 services) are now on the IOOS Catalog. Thanks to everyone who helped! I'm closing the issue.