⇐ ⇒

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

From: Bert Jagers <Bert.Jagers>
Date: Thu, 23 Nov 2006 20:55:12 +0100

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 _at_ 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 _at_ 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
Received on Thu Nov 23 2006 - 12:55:12 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:40 BST

⇐ ⇒