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 [email protected], 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 [email protected].
