⇐ ⇒

[CF-metadata] curvilinear cartesian coordinates case

From: Bert Jagers <Bert.Jagers>
Date: Tue, 28 Nov 2006 08:33:34 +0100

Hi Brian,

> Thanks for the clarification. We had not envisioned the case of the
> projection coordinates being represented by auxiliary coordinate
> variables.
> To support this use case I agree with your recommendation to move the
> grid_mapping attribute to the appropriate auxiliary coordinate variables.
> If this were done then the coordinates attribute of data variables can
> point to all applicable coordinates. For example:
>
> float waterlevel(TIME,M,N);
> waterlevel:long_name = "water level" ;
> waterlevel:units = "M" ;
> waterlevel:standard_name = "sea_surface_height" ;
> waterlevel:positive = "up" ;
> waterlevel:coordinates = "z_lat z_lon zgrid_y_nl zgrid_x_nl zgrid_y_de
> zgrid_x_de";


Indeed, the CF conventions state that the true latitude and longitude
coordinates be supplied via the coordinates attribute, i.e. not the local
coordinates. Basically, there are two options:

1) as you indicate by specifying all auxiliary coordinates (according
terminology section 1.2 of the conventions, also z_lat and z_lon are
auxiliary coordinates) as part of the coordinates attribute. The
grid_mapping associated with the coordinates should be used to uniquely
identify coordinate pairs.

2) let the reader search for compatible coordinates (dimensions match data)
based on standard_names. The grid_mapping associated with the coordinates
should be used to uniquely identify coordinate pairs.

The first, approach would help the reader to find the relevant coordinate
variables, but will probably break some of the current implementations
(assuming only one coordinate pair in the coordinates attribute). The second
option would require more effort by reader, but would allow you to keep the
coordinates attribute to point to only the lat lon pair.

> and the projection coordinates are explicity associated with the
> appropriate mapping, for example
>
> double zgrid_x_nl(M,N);
> zgrid_x_nl:long_name = "grid cell centres, x-coordinate, EPSG19914" ;
> zgrid_x_nl:units = "M" ;
> zgrid_x_nl:standard_name = "projection_x_coordinate" ;
> zgrid_x_nl:grid_mapping = "EPSG19914" ;
> double zgrid_y_nl(M,N);
> zgrid_y_nl:long_name = "grid cell centres, y-coordinate, EPSG19914" ;
> zgrid_y_nl:units = "M" ;
> zgrid_y_nl:standard_name = "projection_y_coordinate" ;
> zgrid_y_nl:grid_mapping = "EPSG19914" ;
> double zgrid_x_de(M,N);
> zgrid_x_de:long_name = "grid cell centres, x-coordinate, EPSG16362" ;
> zgrid_x_de:units = "M" ;
> zgrid_x_de:standard_name = "projection_x_coordinate" ;
> zgrid_x_de:grid_mapping = "EPSG16362" ;
> double zgrid_y_de(M,N);
> zgrid_y_de:long_name = "grid cell centres, y-coordinate, EPSG16362" ;
> zgrid_y_de:units = "M" ;
> zgrid_y_de:standard_name = "projection_y_coordinate" ;
> zgrid_y_de:grid_mapping = "EPSG16362" ;

That should work indeed.

>> By the way should x_sea_water_velocity and y_sea_water_velocity be
>> velocity
>> components in lat, lon directions or projection_x_coordinate and
>> projection_y_coordinate directions? I guess the former, if so, I would
>> suggest renaming the components to east_sea_water_velocity and
>> north_sea_water_velocity.
>
> The x/y vector components refer to some rectangular grid other than a
> lat/lon grid. Since you've provided multiple projection coordinates for
> the same values of the vector components I would guess that the vector
> component are relative to lat/lon coordinates rather than relative to one
> of the two projection coordinates. In this case the appropriate standard
> names are eastward_sea_water_velocity and westward_sea_water_velocity (but
> westward_sea_water_velocity is missing from the standard name table).
> Note
> also that the names x_sea_water_velocity and y_sea_water_velocity have
> been
> updated to sea_water_x_velocity and sea_water_y_velocity.

Okay thanks, great. I just realized there was an issue when I asked the
question yesterday.
I should have checked the standard name list first.

Best regards,

Bert
Received on Tue Nov 28 2006 - 00:33:34 GMT

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

⇐ ⇒