CenCOOS 52 north SOS geospatial bounds

[rsignell-usgs]

Gang, I was surprised when CenCOOS 52 north SOS server came back when I queried with a bounding box of New York Harbor.

Are there CenCOOS 52 north SOS geospatial bounds actually correct?

<gmd:westBoundLongitude><gco:Decimal>-176.53</gco:Decimal></gmd:westBoundLongitude>
<gmd:eastBoundLongitude><gco:Decimal>174.116666666667</gco:Decimal></gmd:eastBoundLongitude>
<gmd:southBoundLatitude><gco:Decimal>32.491</gco:Decimal></gmd:southBoundLatitude>
<gmd:northBoundLatitude><gco:Decimal>71.3213</gco:Decimal>

[amilan17]

Interesting find - I suspect this is because the following scenarios:

1. Bounding extent is stored in the ISO metadata record under srv:SV_ServiceIdentification only. This is the result of the SOS to ISO transform which only ouputs information about the service not the dataset(s).
2. Geoportal is not configured to query bounding extents in the service identification section....

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

One cannot have too much metadata. Start simple and grow from there. ~~~~~~~

On Wed, Mar 12, 2014 at 10:01 AM, Rich Signell notifications@github.comwrote:

I was surprised when CenCOOS 52 north SOS server came back when I queried with a bounding box of New York Harbor.

Are there CenCOOS 52 north SOS geospatial bounds actually correct?

gmd:westBoundLongitudegco:Decimal-176.53/gco:Decimal/gmd:westBoundLongitude gmd:eastBoundLongitudegco:Decimal174.116666666667/gco:Decimal/gmd:eastBoundLongitude gmd:southBoundLatitudegco:Decimal32.491/gco:Decimal/gmd:southBoundLatitude gmd:northBoundLatitudegco:Decimal71.3213/gco:Decimal

Reply to this email directly or view it on GitHubhttps://github.com/ioos/registry/issues/5 .

[srstsavage]

So, two things.

One, it looks like we accidentally had the AOOS SOS injector aimed at the CeNCOOS SOS for a few days in December, resulting in a bunch of Alaska stations being added to the CeNCOOS SOS. The Alaska stations are on both sides of the antimeridian, something that EPSG:4326 is ill equipped to handle (thus the global stripe seen in Rich's screenshot). I removed the Alaska stations, and now the bounds of the CeNCOOS SOS are sane:

<gml:boundedBy>
  <gml:Envelope srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
    <gml:lowerCorner>32.491 -130.474</gml:lowerCorner>
    <gml:upperCorner>44.639 -114.139444444444</gml:upperCorner>
  </gml:Envelope>
</gml:boundedBy>

So, when the registry updates the CeNCOOS SOS record, all should be well.

But two, those stations on both sides of the antimeridian are valid for AOOS, resulting in this GetCapabilities bounding box:

<gml:boundedBy>
  <gml:Envelope srsName="urn:ogc:def:crs:EPSG::4326">
    <gml:lowerCorner>42.589 -179.2833</gml:lowerCorner>
    <gml:upperCorner>71.3601 178.263</gml:upperCorner>
  </gml:Envelope>
</gml:boundedBy>

I suspect that issues in both the 52n SOS and the registry harvesting process will need to be addressed in order to handle cases of extends that cross the antimeridian.

Added i52n issue here: https://github.com/ioos/i52n-sos/issues/6

[srstsavage]

This can probably be closed?

[robragsdale]

Closing this issue. Shane removed the Alaska stations that were inadvertently added to the CeNCOOS SOS. Now, the bounds of the CeNCOOS SOS are sane:

gml:boundedBy

gml:lowerCorner32.491 -130.474/gml:lowerCorner gml:upperCorner44.639 -114.139444444444/gml:upperCorner /gml:Envelope /gml:boundedBy Stations on both sides of the antimeridian are valid for AOOS, resulting in this GetCapabilities bounding box: gml:boundedBy gml:lowerCorner42.589 -179.2833/gml:lowerCorner gml:upperCorner71.3601 178.263/gml:upperCorner /gml:Envelope /gml:boundedBy Issues in both the 52n SOS and the registry harvesting process will need to be addressed in order to handle cases of extends that cross the antimeridian. The i52n issue was added here ioos/i52n-sos#6

[rsignell-usgs]

nice work!