[CF-metadata] axis attribute - curvilinear cartesian coordinates case

[Bert Jagers]

Dear John, Jonathan and others,

Thank you for your comments.

Jonathan Gregory wrote:
>> So, why do we need to have an additional attribute axis = "X" in the 1D 
>> case
> My suggestion is that axis="X" and "Y" are useful to point out which are
> the horizontal coordinates among the various dimensions of the data 
> variable.

 John Caron wrote:
> I agree we dont need an axis attribute, the standard name is sufficient.

I agree with John that the standard name is sufficient. The axis attribute 
is only useful for applications that do not support standard names and 
backward compatibility.

Jonathan Gregory wrote:
>> determined from the order of names in the coordinate attributes (CF 
>> convention).
> No, because that order is not significant.

 John Caron wrote:
> CF does not require ordered dimensions, so one could not infer from that.
> I dont think theres an order of names  in coordinate attributes.

CF does not require a particular order of dimensions, but COARDS does. For 
compatibility reasons CF recommends such ordering. I thought that the 
auxiliary coordinates names had to be specified in the same order as COARDS 
conventions, but that seems to be an artifact of the files that I had seen. 
Indeed I cannot find such a formal requirement.

John Caron wrote:
> As an aside: the above files are valid CF, but not georeferencing, because 
> there is no lat/lon or projection info. So we cant display it with a map 
> overlay, combine it with other datasets, etc. Im sure its useful for your 
> purposes, but its not much use to anyone else.

All these things can still be done as long as your visualisation program has 
the other data in the same coordinate system. Which makes sense for the 
majority of coastal and riverine models for which the data is often 
available in national coordinate systems. For larger scale models of seas 
and oceans and riverine systems that cross international or state 
boundaries, handling coordinate systems in a proper way and relating them to 
WGS84 latitude and longitude is necessary. In the latter case the 
requirement of having latitude and longitude as coordinate variables is 
almost trivial; however, for local engineering applications it is not. I 
agree with you that such data without proper definition of horizontal and 
vertical reference systems is not suitable for distribution to arbitrary 
users without adding any further metadata. However, in the extreme case of 
simple validation tests (small flume experiments) or even hypothetical 
experiments, georeferencing is not important but data exchange may still be 
desirable, yet unrelated to any particular position on the earth.


Jonathan Gregory wrote:
> CF requires lat and lon auxiliary coords to be provided so that a generic
> application can plot the data, at least.

I did not know that lat and lon are required. Since latitude was associated 
with Y in section 2.4 of 
http://www.cgd.ucar.edu/cms/eaton/cf-metadata/conformance-req.html and since 
I do not associate Y with latitude --- longitude and latitude allways refer 
to spherical/earth/WGS84 coordinates for me; while X and Y allways refer to 
planar, cartesian coordinates for me --- I had not read the conformance text 
as "if you specify horizontal coordinates, it must be as longitude and 
latitude". I have now found the statement "When the coordinate variables for 
a horizontal grid are not longitude and latitude, it is required that the 
true latitude and longitude coordinates be supplied via the coordinates 
attribute." in section 5.6 of 
http://www.cgd.ucar.edu/cms/eaton/cf-metadata/CF-1.0.html . However, that 
still leaves me with the question how to deal with curvilinear cartesian 
coordinates that I also want to include besides the lat/lon coordinates. It 
seems that this section 5.6 "grid mappings and projections" is pointing in 
the direction of the solution, but it doesn't work out quite right. It lists 
the following example:

dimensions:
  y = 228;
  x = 306;
  time = 41;

variables:
  int Lambert_Conformal;
    Lambert_Conformal:grid_mapping_name = "lambert_conformal_conic";
    Lambert_Conformal:standard_parallel = 25.0;
    Lambert_Conformal:longitude_of_central_meridian = 265.0;
    Lambert_Conformal:latitude_of_projection_origin = 25.0;
  double y(y);
    y:units = "km";
    y:long_name = "y coordinate of projection";
    y:standard_name = "projection_y_coordinate";
  double x(x);
    x:units = "km";
    x:long_name = "x coordinate of projection";
    x:standard_name = "projection_x_coordinate";
  double lat(y, x);
    lat:units = "degrees_north";
    lat:long_name = "latitude coordinate";
    lat:standard_name = "latitude";
  double lon(y, x);
    lon:units = "degrees_east";
    lon:long_name = "longitude coordinate";
    lon:standard_name = "longitude";
  int time(time);
    time:long_name = "forecast time";
    time:units = "hours since 2004-06-23T22:00:00Z";
  float Temperature(time, y, x);
    Temperature:units = "K";
    Temperature:long_name = "Temperature @ surface";
    Temperature:missing_value = 9999.0;
    Temperature:coordinates = "lat lon";
    Temperature:grid_mapping = "Lambert_Conformal";

However, in my case the local grid is not rectilinear. So, dimensions x and 
y are not associated with x and y coordinates in projected space. Thus I end 
up with the following file:

dimensions:
  eta = 228;
  xi = 306;
  time = 41;

variables:
  int Lambert_Conformal;
    Lambert_Conformal:grid_mapping_name = "lambert_conformal_conic";
    Lambert_Conformal:standard_parallel = 25.0;
    Lambert_Conformal:longitude_of_central_meridian = 265.0;
    Lambert_Conformal:latitude_of_projection_origin = 25.0;
  double eta(eta);
    eta:long_name = "second horizontal direction";
  double xi(xi);
    xi:long_name = "first horizontal direction";
  double y(eta, xi);
    y:units = "km";
    y:long_name = "y coordinate of projection";
    y:standard_name = "projection_y_coordinate";
  double x(eta, xi);
    x:units = "km";
    x:long_name = "x coordinate of projection";
    x:standard_name = "projection_x_coordinate";
  double lat(eta, xi);
    lat:units = "degrees_north";
    lat:long_name = "latitude coordinate";
    lat:standard_name = "latitude";
  double lon(eta, xi);
    lon:units = "degrees_east";
    lon:long_name = "longitude coordinate";
    lon:standard_name = "longitude";
  int time(time);
    time:long_name = "forecast time";
    time:units = "hours since 2004-06-23T22:00:00Z";
  float Temperature(time, eta, xi);
    Temperature:units = "K";
    Temperature:long_name = "Temperature @ surface";
    Temperature:missing_value = 9999.0;
    Temperature:coordinates = "lat lon";
    Temperature:grid_mapping = "Lambert_Conformal";

What is lacking in this example is some clue that x and y are the 
coordinates in the Lambert projection. Can we add an attribute 
"mapped_coordinates" or something similar such that the listing ends with:

    Temperature:mapped_coordinates = "x y";

I have another question. Our curvilinear grid can contain points not 
associated with any particular point in space. Think of a curvilinear grid 
following a river that bifurcates: some grid lines follow one downstream 
river branch, other grid lines follow the other branch. There is, however, 
one line of the grid that ends at the bifurcation to separate the two 
channels downstream of the bifurcation. However, if we look at the matrix of 
coordinates of the overall model there must be some values at these 
undefined coordinates somewhere between the two downstream branches. In our 
model, such coordinates are set to a missing value; no physical 
interpretation should be associated with such dummy coordinates. The 
question now is, are missing values allowed in curvilinear i.e. auxiliary 
coordinates according the CF standards? I know that section 5 of 
conformance-req.html states that "A coordinate variable must not have the 
_FillValue or missing_value attributes.". However, this does not indicate 
whether this restriction also holds for auxiliary coordinates (lat, lon, x 
and y in the example above), the statement above it that "A coordinate 
variable must have values that are strictly monotonic (increasing or 
decreasing)." is definitely not valid for general auxiliary coordinates. Our 
curvilinear grids will almost allways contain such missing coordinates; so 
we require either that missing_values are allowed for auxiliary coordinates, 
or there must be another way to indicate that these dummy coordinates should 
be clipped before any further processing.

Summary:

* I would prefer if lat and lon are not necessary for some CF-minor 
compliance.
* I would prefer an extension of the "grid mappings and projections" with 
the attribute "mapped_coordinates" for models using curvilinear cartesian 
coordinates.
* I would like to learn that missing_values are allowed for auxiliary 
coordinates.

Best regards,

Bert