Thanks for starting this repo, @abirger.

I'm "opening" this issue only as a reference to the relevant, generic discussions we had in January about the BBOX query specification, at the i52n-sos repo.

Feel free to close it w/o any additional comments. I thought it'd be useful to have this reference, even as a closed issue.

A crosswalk between netCDF and SOS is published here. It is supposed to facilitate the mapping of netCDF attributes onto ncSOS output, as well as i52N output in netCDF format.

The rules will be updated in coordination with the revision of the IOOS Convention for Asset Identification suggested by @kwilcox (here), and discussed in issue #4

The IOOS SOS v1.0 SML DescribeSensor-Network Template requires that sml:location is used to indicate the coordinates of each network member:

              <!-- ===================================================== -->
              <!-- LOCATION                                                        -->
              <!-- Station geographic location (lat & lon only, no z)              -->
              <!-- Always use epsg 4326.                                           -->
              <!-- For moving platforms use <gml:LineString>                       -->
              <!-- ===================================================== -->
              <sml:location>
                <gml:Point srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
                  <gml:pos>34.7 -72.73</gml:pos>
                </gml:Point>
              </sml:location>

It works perfectly well for i52N describing a network of discrete stations as there position can be described by a simple coordinate tuple; however, for ncSOS, which usually deals with gridded data, the point-type coordinates do not make sense. The best way to describe the network location in that case would be a bounding box but <sml:location> does not allow the use of it.

As usual, the problem can be solved in several ways:

1. Ignore it, and use <gml:boundedBy> instead <gml:Point> anyway. That is how ncSOS currently deals with that. It contradicts the IOOS SOS Template and there will be a schema validation error but we can always turn a blind eye on both issues.

2. Do not indicate any location values at all leaving instead an empty <sml:location/> element. It does not violate the Template, and would not trigger any schema validation error; however, it makes the ncSOS output somewhat inconsistent. It is kind of a stretcher but not a far-fetched one, and it is a very simple solution that does not generally change the template.

3. Use <gml:LineString> instead of <gml:Point>. It is allowed by both the schema and IOOS template, and it can indicate multiple coordinate tuples to describe a bounding box:

   <sml:location>
      <gml:LineString>
           <gml:name>bounding_box</gml:name>
           <gml:posList srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
                    17.0 -68.0 19.5 -64.0
            </gml:posList>
      </gml:LineString>
   </sml:location>
   

   It looks kind of strange but formally it complies with all the requirements. It is also a relatively simple solution that does not break the template, although it is a stretch to use LineString that way.

4. The most radical solution would be to get rid of <sml:System> in the description of components, and use <sml:Component> instead as <sml:Component> allows bounding box as well as point-type coordinates:

             <sml:components>
                 <sml:ComponentList>
                     <sml:component name="Grid0">
                         <sml:Component>
                             <gml:boundedBy>
                                 <gml:Envelope>
                                     <gml:lowerCorner></gml:lowerCorner>
                                     <gml:upperCorner></gml:upperCorner>
                                 </gml:Envelope>
                             </gml:boundedBy>
   

   That seems to be the most rigorous solution but it significantly changes the Templates, and therefore requires a thorough discussion.

The URN modification was suggested by @kwilcox at IOOS DMAC Meeting 2016.
It was tentatively agreed on with some reservations (@emiliom warned about need to identify a deployment variety - perhaps, [version] field should not be deprecated after all?); when fully adopted, the IOOS Convention for Asset Identification will be updated accordingly.

This is just a reference/link to the ongoing discussion/issue on the i52n-sos repo, which has involved comparisons to the ncSOS implementations as well as pyoos client implementation. There's still some pyoos fixes and testing I intend to do later this month, plus a release with the i52N SOS fixes hasn't been done yet.

@abirger, if you don't think this belongs here, just go ahead and close it.