Should LatLonDatum be in glob_att instead of instrument config files?

[dnowacki-usgs]

This seems like something applicable to the mooring, not individual instruments. @emontgomery-usgs any thoughts on this?

[emontgomery-usgs]

Yes, this sounds like a reasonable proposal. Adding the position Datum is new, so we're not spun up on how best to add it yet.

[dnowacki-usgs]

Cool. Is the formatting of LatLonDatum finalized? As opposed to lat_lon_datum or something else? glob_att attributes generally seem to be in all caps, but it doesn't seem to be 100% consistent. Attributes in the .nc files seem to be mostly lowercase and separated by underscores. There doesn't seem to be a lot of CamelCase, however. Thoughts?

[emontgomery-usgs]

FYI, the use of ALLCAPS reflects attributes that are part of the EPIC convention. Ones we've added are lc_with_underscore or CamelCase. No consistency is attempted, since we often take exactly what the manufacturer outputs as settings parameters, and put them in the global atts. Capitalization is not consistent among/between manufacturers. Our Sandwich data is probably the only one currently making use of datums, and the CF version has these as global atts, but nothing in the lat and lon variable atts, which is probably more important. position_datum: NAD83(2011) elevation_datum: NAVD88 see: http://geoport.whoi.edu/thredds/dodsC/silt/usgs/Projects/stellwagen/CF-1.6/SANDWICH2017/10831dw-a.nc.html Note in the EPIC version of the file, there are 'datum' attributes for lat, lon and depth variables, but it doesn't get carried over to the CF version. The position_datum and elevation_datum start here, and are carried into the CF version. https://stellwagen.er.usgs.gov/thredds/dodsC/TSdata/SANDWICH2017/10831dw-a.nc.html The "datum" attribute is also present in lat, lon and depth vars for YSI data from Chincoteague (EPIC), so it appears that part is our "standard". I didn't find position_ or elevation_datum in the global atts, but think we should probably use those instead of LatLonDatum. If you don't have the 'datum' attribute in lat, lon and depth, please add it. If you find a CF name for what to call the datums in the global atts, if they're even recommended as global atts, I'd OK using that instead. Thanks!

…

On Mon, Apr 30, 2018 at 9:55 AM, Dan Nowacki ***@***.***> wrote: Cool. Is the formatting of LatLonDatum finalized? As opposed to lat_lon_datum or something else? glob_att attributes generally seem to be in all caps, but it doesn't seem to be 100% consistent. Attributes in the .nc files seem to be mostly lowercase and separated by underscores. There doesn't seem to be a lot of CamelCase, however. Thoughts? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABsHnkKu3rqTTVqYcvaET8tYqi6M2CKgks5ttxfagaJpZM4Tj_FQ> .

-- Ellyn Montgomery, Oceanographer and Data Manager U.S. Geological Survey Woods Hole Coastal and Marine Science Center 384 Woods Hole Rd., Woods Hole, MA, 02543-1598 (508) 548-8700 x2356 https://stellwagen.er.usgs.gov; https://woodshole.er.usgs.gov/operations/stg/

[dnowacki-usgs]

OK, great. I think this can be implemented as follows:

1. Add position_datum and elevation_datum as optional fields in global atts; add these to the examples in the docs. LatLonDatum will be deprecated in favor of position_datum.
2. Assign datum attributes for lat, lon dimensions if position_datum exists.
3. I'm not sure about elevation_datum being added to depth. Often (Grand Bay, at least) the instruments weren't surveyed in, so datum is local bed elevation. Also, I think with the variable being named "Depth" implies water-column depth and not water-surface elevation.. but you're the expert :). If you think adding elevation_datum as an attribute to depth (if it exists) is the right thing to do, I can implement that.
4. I looked at the CF conventions, and they mostly deal with CRS values, which I suppose is more appropriate, but it's also another can of worms to deal with. They specify another variable, crs, with additional attributes that describe it. @rsignell-usgs thoughts on this?

Upon further review, I think that link really applies to grid mapping, which is something different. The coordinates don't really have datum information it would seem.