Thank you all for digging into this topic! If you all agree that the 
`sea_water_x_velocity` is the velocity component in the direction indicated by 
the `axis = X` attribute, and if that attribute can be used on an auxiliary 
coordinate variable (typically 2D for a curvilinear structured mesh or 1D for 
an unstructured mesh) then that is more or less in line with what we were 
hoping for. In that case, I would appreciate some guidance on -- as 
@JimBiardCics suggested -- how to best propose to change the language as it 
links to both the CF conventions document (related to the axis attribute on 
auxiliary coordinate variables) and the standard names table.

@davidhassell You asked whether the component directions in my case are defined 
as unrotated east and north? The original vector component in the numerical 
model are staggered and directed along the `m` and `n` dimensions of the 
curvilinear C-grid. The postprocessing routine transforms these vector 
components to co-located components along the x and y directions of the model 
domain which may be unrotated lat/lon (in which case we indeed write 
`eastward_` and `northward_sea_water_velocity`) but usually are "arbitrary" 
Cartesian x/y for which we can't guarantee x to be eastward and y to be 
northward. However, since people usually select a standardized regional CRS, in 
_most_ cases x will align with eastward and y with northward. So, then the 
question becomes ... Do I assume the alignment (and write eastward and 
northward components) and accept that the metadata in the NetCDF file may be 
incorrect when the assumption is not valid, or do I go for always correct 
metadata and merely indicate that the vector components are in the regional 
Cartesian x/y directions ... We made the latter choice, which triggers this 
discussion.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/cf-convention/cf-conventions/issues/252#issuecomment-603833407
This list forwards relevant notifications from Github.  It is distinct from 
cf-metad...@cgd.ucar.edu, although if you do nothing, a subscription to the 
UCAR list will result in a subscription to this list.
To unsubscribe from this list only, send a message to 
cf-metadata-unsubscribe-requ...@listserv.llnl.gov.

Reply via email to