Determine proper CRS for glider data

[dpsnowden]

In the current draft of the glider template there is a variable attribute for the depth variable called:

depth:reference_datum

and the current value is sea-surface.

Is this the correct variable attribute name as currently specified by the IOOS SOS templates? Is the value correct or is there a more precise value, potentially with an EPSG reference?

[graybeal]

I don't know if there is a specific vocabulary being expected by this template, but I'd recommend using EPSG. In this case, the equivalent of sea-surface is this: EPSG::5113, http://www.opengis.net/def/datum/EPSG/0/5113.

There are some minor issues to straighten out in the background for this code, but I'd go with one of the above.

[dpsnowden]

Hi David (cc to Nan, John K, John G, and Kyle)

I doubt you've had any time to focus on this so I wanted to follow up and describe the problem better in hopes that you actually know the answer off the top of your head. The thread below is related to my problem but is not the thing I'm directly concerned with now.

We're creating a netcdf template for glider data submitted to the DAC in real time. The current draft of the template is here. But, if you make any changes please make them to the python script we've written to generate the shell template. See line 265 and the corresponding github issue to see what I'm talking about. We're trying to provide the right reference to a coordinate reference system and/or datum for the depth coordinate. I don't think the variable attribute we're currently using is correct but I'm not sure of the best solution. I think the options are:

1. Follow OceanSITES which seems to be starting with DEPTH:coordinate_reference_frame="urn:ogc:crs:EPSG::5113"

The email thread indicates that is not correct but I don't know what they've settled on. Two related questions. a) What is the best CF recommended solution for using variable attributes (what is the name of the attribute?). b) What is the correct crs to reference.

1. Keep ours 'reference_datum' : 'sea-surface', which seems wrong because we should be using a coordinate reference system and not a datum as is explained in the email.
2. Go with the NODC recommendation which is to include a separate container variable which acts to consolidate several pieces of information. First it uses a variable attribute for each geophysical variable that refers to the container variable

temperature:grid_mapping = "crs" ;

The crs variable is then defined as int crs ; crs:grid_mapping_name = "latitude_longitude" ; crs:longitude_of_prime_meridian = 0. ; crs:semi_major_axis = 6378137. ; crs:inverse_flattening = 298.257223563 ; crs:epsg_code = "EPSG:4326" ;

I think that a modification of 3 has the most potential. It is a more elegant solution but it needs to be augmented to include vertical referencing. I think your solution for the SOS templates could be adapted to this problem.

If you know off the top of your head and can shoot me a quick response I'd really appreciate it. But, if you know you can't get to this today or tomorrow then let me know that too and I'll figure something else out.

Best, Derrick

[dpsnowden]

Adding a response from David Steube

Hi Derrick

I don't have an answer – I don't think an authoritative answer exists, but I will try to provide some constraints that might help us create one.

The Vertical CRS the we ended up using in the SOS templates is http://www.opengis.net/def/crs/EPSG/0/5829 It is not yet available on opengis (minor detail) but I think one of our team (Alex?) is working on getting it added. We ended up adopting the compound CRS notation described in the attached OGC Document. The OGC CRS specification is explicitly 3D + Time which conflicts/duplicates some of our existing conventions for CF.

Appendix F of cf-conventions.pdf specifies grid mappings – similar to what you describe from NODC in option 3. It appears to be limited to 2D CRS specification using explicit parameters rather than a reference to defined CRS like EPSG 4269.

I would recommend using the OGC CRS spec (attached) as guidance to add an explicit vertical CRS container variable to the NetCDF file in the same style as the existing convention. To be usable both the vertical and horizontal CRS must be allowed to reference EPSG defined reference frames rather than specify all the guts of the semi_major_axis etc. I would hope that providing only 'crs:epsg_code' is sufficient and the other attributes are optional but I am not sure.

Good luck and let me know if I can help further.