search

ioos / service-monitor

A web based catalog of IOOS services and datasets
http://catalog.ioos.us
6 stars 13 forks source link

Incorrect usage of version on GetCapabilities requests in catalog results #445

Closed srstsavage closed 8 years ago

srstsavage commented 8 years ago

Not sure if this is a catalog problem or not, but I see a lot of incorrect usage of the version parameter on GetCapabilities requests in the catalog results:

http://catalog.ioos.us/services/filter/none/SOS/json

http://catalog.ioos.us/services/filter/none/WMS/json

GetCapabilities take an acceptVersions parameter, as in acceptVersions=1.0.0, and not a version parameter. Are RA staff providing these URLs, or are they generated somewhere?

lukecampbell commented 8 years ago

These are all coming from the providers

http://www.ngdc.noaa.gov/geoportal/rest/document?id=%7BF68E5494-5B10-4BA4-9AEB-75E839D87D73%7D

I personally wasn't aware that SOS doesn't have a version parameter but WMS does: http://docs.geoserver.org/2.8.x/en/user/services/wms/reference.html#getcapabilities

srstsavage commented 8 years ago

Ah, you're right, my mistake. Looks like OWS 1.0 (05-008) dictating the acceptVersions parameter was published on 2005-11-22, much after WMS 1.1.1 (2002-01-16) and likely too late for inclusion into WMS 1.3.0 (2006-03-15).

WFS 1.1.0 (2005-05-03) actually does use the acceptVersions parameter and not version, and appears to follow a 0.3 version of the OWS standard (which I can't find anywhere). WFS 2.0 follows OWS 1.1 and the acceptVersions parameter.

WCS 1.0 (2005-10-14) doesn't conform to OWS 1.0 but WCS 1.1.0 (2006-10-17) does.

As you noted, SOS 1.0.0 and 2.0.0 follow OWS 1.1 and the acceptVersions parameter.

Interesting that no new WMS version has been published in 10 years while it doesn't follow the best practices suggested by OGC.

Anyway, I'll close this since it's not a catalog problem. The potential problem I see is that SOS servers supporting both SOS 1.0.0 and 2.0.0 will default to 2.0.0 if acceptVersions=1.0.0 isn't specified, but that can be solved once it starts happening.

lukecampbell commented 8 years ago

So, a lot of these catalog entries are dynamically generated, not too many people (I would wager 0) are capable of generating an ISO-19115-2 compliant ISO-19139 XML document by hand. NcISO or NcSOS may be generating the invalid URL parameters. Probably NcSOS since NcISO is probably agnostic to services defined in thredds.

As for the ISOs that are generated for 52n instances, I have no clue where they come from. But if I were responsible for generating one, I would probably copy a good one from somewhere and then use a script to fill in some templated values.

emiliom commented 8 years ago

ISO's for SOS are generated automatically by NGDC via an XSL transformation from the GetCapabilities. On Apr 19, 2016 6:58 AM, "Luke Campbell" notifications@github.com wrote:

So, a lot of these catalog entries are dynamically generated, not too many people (I would wager 0) are capable of generating an ISO-19115-2 compliant ISO-19139 XML document by hand. NcISO or NcSOS may be generating the invalid URL parameters. Probably NcSOS since NcISO is probably agnostic to services defined in thredds.

As for the ISOs that are generated for 52n instances, I have no clue where they come from. But if I were responsible for generating one, I would probably copy a good one from somewhere and then use a script to fill in some templated values.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/ioos/catalog/issues/445#issuecomment-211932642

lukecampbell commented 8 years ago

That must have been a nightmare to author... wow, hats off to who wrote that.