Add direction attribute for coordinate axis

[snowman2]

Title

Add direction attribute for coordinate axis

Moderator

(Any takers?)

Moderator Status Review [last updated: YY/MM/DD]

???

Requirement Summary

http://docs.opengeospatial.org/is/12-063r5/12-063r5.html#40 Add a direction for the coordinate system axis attributes to specify which direction the coordinate goes in. This is useful when building a coordinate system.

Technical Proposal Summary

Example:

  double y(y);
    y:standard_name = "projection_y_coordinate";
    y:direction = "north"
    y:unit = "metre"
  double x(x);
    x:standard_name = "projection_x_coordinate";
    x:direction = "east"
    x:unit = "metre"
  float Temperature(y, x);
    Temperature:units = "K";
    ....
    Temperature:grid_mapping = "Lambert_Conformal: x y";

This could also be used for latitude & longitude:

Instead of:

float lat(lat) ;
  lat:long_name = "latitude" ;
  lat:units = "degrees_north" ;
  lat:standard_name = "latitude" ;

It could be:

float lat(lat) ;
  lat:long_name = "latitude" ;
  lat:units = "degrees" ;
  lat:direction = "north" ;
  lat:standard_name = "latitude" ;

Benefits

Would support more coordinate systems & be more explicit.

For example NORTH_POLE_EASTING_SOUTH_NORTHING_SOUTH or SOUTH_POLE_EASTING_NORTH_NORTHING_NORTH: See axis maps here: https://pyproj4.github.io/pyproj/latest/_modules/pyproj/crs/coordinate_system.html

WKT form of coordinate sytem:

    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],

Status Quo

Currently only supported in the vertical coordinate: http://cfconventions.org/cf-conventions/cf-conventions.html#vertical-coordinate

axis_name:units = "meters" ;
axis_name:positive = "down" ;

Detailed Proposal

Refer to above ^^

[DocOtak]

With the huge caveat of me not knowing the many intricacies of projection systems...

Would it make sense to extend the positive attribute to the X and Y coordinates with additional allowed values of "north", "south", "east", and "west"? This would be instead of making a new attribute. A modified version of your example to show what I mean:

  double y(y);
    y:standard_name = "projection_y_coordinate";
    y:positive = "north"
    y:unit = "metre"
  double x(x);
    x:standard_name = "projection_x_coordinate";
    x:positive = "east"
    x:unit = "metre"
  float Temperature(y, x);
    Temperature:units = "K";
    ....
    Temperature:grid_mapping = "Lambert_Conformal: x y";

[snowman2]

@DocOtak, I don't think that there would be a problem will using positive instead of direction as long as they mean the same thing.

[JonathanGregory]

If I understand this correctly, I think that in general one cannot specify a geographical direction for a projection coordinate, because (of course) the projection axes do not coincide with longitude and latitude axes. For example, in some grids, the positive x-direction might be both north and east at all points, but why would you say it was east rather than north? In other grids, the local direction will vary from point to point. You really need to differentiate the coordinates in geographical space to find the local direction, don't you?

[JimBiardCics]

@JonathanGregory Most all projected coordinate systems are east-north aligned. The main questions are which component is which and which direction is positive. But your question points out the more difficult case of swath data where X and Y are not aligned to east and north.

[JimBiardCics]

@snowman2 There is a long-standing use of the units 'degrees_north' and 'degrees_east' within CF that I think precludes making a change to using units of 'degrees' for latitude and longitude. It is used by some as a way to determine that a given variable is a latitude or longitude coordinate variable.

[JonathanGregory]

Dear @JimBiardCics Yes, I agree that many projected coordinate systems look somewhat like east-north, but not all of them, for example stereographic. CF also allows rotated pole, which is not true east-north by construction, and and indeed any sort of X and Y grid with 2D lat and lon, such as the ocean tripolar grid, which is east-north for a lot of the world, but variably distorted north of a certain latitude as it approaches its two north poles. In such cases it would be misleading to label X and Y as east and north, I feel. Jonathan

[snowman2]

Adding excerpt from: http://docs.opengeospatial.org/is/12-063r5/12-063r5.html#40

Axis direction indicates the positive increment along an axis. The handedness of a 2- or 3-dimensional coordinate system may be derived from the directions.

Requirement: the following constraints shall apply:

i.        For geodetic CRSs having an ellipsoidal 2-D coordinate system, the two-dimensional ellipsoidal coordinate system axes are geodetic latitude, positive northwards, and geodetic longitude, positive eastwards. Axis direction shall be ‘north’ and ‘east’ respectively.
ii.        For geodetic CRSs having an ellipsoidal 3-D coordinate system, the three-dimensional ellipsoidal coordinate system axes are geodetic latitude, positive northwards, geodetic longitude, positive eastwards, and ellipsoidal height, positive upwards. Axis direction shall be ‘north’, ‘east’ and ‘up’ respectively.
iii.       For geodetic CRSs having a geocentric Cartesian coordinate system, in WKT strings the axis directions shall be ‘geocentricX’, ‘geocentricY’ and ‘geocentricZ’ respectively. The first axis of the earth-centred 3D Cartesian coordinate system lies in the equatorial plane such that a vector pointing in the positive direction passes through the intersection of the equator and the prime meridian. The second axis is in the equatorial plane such that a vector pointing in the positive direction passes through the intersection of the equator and the meridian of 90°E. The third axis is perpendicular to the first two such that it completes a right-handed coordinate system; it is approximately parallel to the earth’s rotation axis, positive towards the north pole.
 iv.      For projected CRSs, except for coordinate systems centred on a pole, the axis direction shall be ‘north’ or ‘south’ and ‘east’ or ‘west’.

    For coordinate systems centred on a pole the direction for both axes will be ‘south’ (for the north pole case) or ‘north’ (for the south pole case); the axes direction shall be supplemented with a <meridian> description. This is the value of the meridian that the axis follows from the pole. The prime meridian from which the meridian value is reckoned is given through the <prime meridian> object; if no <prime meridian> object is in the WKT string then the IRM or Greenwich meridian shall be assumed.
v.       For vertical CRSs, the axis direction shall be ‘up’ or ‘down’.
vi.       For temporal CRSs, the axis direction shall be ‘future’ or ‘past’.
vii.      In engineering CRSs the horizontal directions are only approximate, the set of directions indicating whether the coordinate system is left-handed or right-handed. (In the 2D case, the handedness is when viewed from above the plane of the system). For engineering CRSs with polar coordinate systems the direction of the rotational axis shall be ‘clockwise’ or ‘counterClockwise’. The specified direction from which the rotation is measured shall be given through the supplementary object <bearing>; the bearing value shall be given in the unit defined through <axis unit>.

See 6.5 for comment on case sensitivity.

NOTE        The requirements in 7.5.4, iv) for projected CRSs with a coordinate system centred on a pole and in 7.5.4, vi) for engineering CRSs with a polar coordinate system require the enumeration for <axis direction> in 7.5.1 to be an extended version of the codelist given in ISO 19111:2007, 9.4.

I think this adds clarity for some of the concerns raised by @JonathanGregory. Thoughts?

[JimBiardCics]

@snowman2 I am generally opposed to this proposal as it stands.

If we want to adopt some sort of convention about this sort of thing, I suggest it be something like what I've written below.

For spatial coordinate systems, add an attribute named "fluffy" (this is a placeholder name — I'm unable to think of a good name yet) that will be added to each dimensional or auxiliary coordinate variable that declares the handedness of the coordinate system and declares which mathematical coordinate axis the variable is expressing.

For a lat/lon/height coordinate reference system (CRS), the information contained in each attribute would be:

• lat.fluffy - left-handed X
• lon.fluffy - left-handed Y
• height.fluffy - left-handed Z

For a polar stereographic CRS, the information would be:

• x.fluffy - right-handed X
• y.fluffy - right-handed Y
• height.fluffy - right-handed Z

For a lat/lon/depth CRS, the information would be:

• lat.fluffy - right-handed X
• lon.fluffy - right-handed Y
• depth.fluffy - right-handed Z

The values of the attribute "fluffy" above are not intended as the actual words. I'm trying to express the information that is required, but I haven't thought of what precise words should be used. If the use of X, Y, and Z above is bothersome, feel free to refer to i, j, and k or first, second, and third instead.

Some of the information may seem wrong at first glance. I was surprised when I discovered a few years ago that the lat/lon/height coordinate system is formally a left-handed coordinate system. I had just assumed that putting latitude first was "merely" a historical practice that wasn't prescriptive.

[JimBiardCics]

As far as the temporal axis goes, CF is quite strongly "future positive". It would take a lot of work to change this. I expect that the paleoclimate people would appreciate the ability to do "past positive" time coordinates that would use a (currently non-existent) calendar appropriate to their work, but I think that is wholly out of scope here.

[JonathanGregory]

For horizontal coordinates, the CF axis attribute should be used to indicate which axis is X and which Y, where X is "like" longitude and Y "like" latitude. This correspondence can't really be more than a rough guide, for reasons mentioned above. Doesn't the axis attribute meet the need? I don't think we need to introduce anything new to describe a CRS. We know that CF metadata isn't arranged the same way as OGC metadata, since the data model is different, but so long as we can translate, I think that should be OK.

[snowman2]

Doesn't the axis attribute meet the need?

So, are you saying that if we have:

  double y(y);
    y:standard_name = "projection_y_coordinate";
    y:axis = "Y"
    y:unit = "metre"
  double x(x);
    x:standard_name = "projection_x_coordinate";
    x:axis = "X"
    x:unit = "metre"
float lat(lat) ;
  lat:long_name = "latitude" ;
  lat:units = "degrees_north" ;
  lat:standard_name = "latitude" ;
float lat(lat) ;
  lat:long_name = "longitude" ;
  lat:units = "degrees_east" ;
  lat:standard_name = "longitude" ;

Then, the direction of the y coordinate should correspond with the north pulled from the lat coordinate?

[JonathanGregory]

Yes, that's right. From the preamble to sect 4 of the CF convention, "The attribute axis may be attached to a coordinate variable and given one of the values X, Y, Z or T which stand for a longitude, latitude, vertical, or time axis respectively. ... To identify generic spatial coordinates we recommend that the axis attribute be attached to these coordinates and given one of the values X, Y or Z. The values X and Y for the axis attribute should be used to identify horizontal coordinate variables." Jonathan

[JimBiardCics]

@snowman2 I don't think we can make that assumption, at least not in your example and as you've expressed it. There is no direct connection in your example between the lats and lons and the Xs and Ys. The connection of X with projection_x_coordinate and Y with projection_y_coordinate is pretty straightforward based on common sense, and on the statement in CF that, "X-Y-up should define a right-handed coordinate system, i.e. rotation from the positive X direction to the positive Y direction is anticlockwise if viewed from above." Following the same logic, longitude should be labeled as an X axis and latitude as a Y axis.

[JimBiardCics]

The association of X and Y with latitude and longitude is a complicated and difficult topic. Here's a good article about the issue.

https://wiki.osgeo.org/wiki/Axis_Order_Confusion

Here's a summary and recap as I see it.

Geodesy uses a left-hand mathematical coordinate system so that the lat,lon,height coordinate tuple order is X,Y,Z. This causes mental distress for many in other disciplines, so they say the mathematical coordinate system is right-handed and the coordinate tuple order is Y,X,Z.

CF has followed the latter convention for latitude and longitude in terms of the association of the names X, Y, and Z with coordinates. Since we don't, in general, compose coordinate tuples in CF usage, we avoid part of the problem.

OGC WKT specifies the order of coordinates in a CRS but doesn't assign X, Y, Z labels. It also allows each coordinate to specify positive direction. The handedness of the mathematical coordinate system is determined by inspection of order and positive direction.

CF doesn't specify anything about the order or positive direction of coordinates in our grid_mapping specifications. We leave the user to determine the correct composition of coordinate tuples for use in CRS transformations.

Full automation of CRS transformations using a WKT CRS string is not possible because there are too many unknowns. In practical terms, some combination of the axis attribute and standard_name attribute values is sufficient to automate most cases.

[JonathanGregory]

The last contribution to this issue was almost four years ago. I believe that the discussion shows that there is no need to add a further attribute, so I propose that the issue should be closed with the label agreement not to change if no-one says otherwise in the next three weeks, before 29th January.

[taylor13]

I agree with Jonathan's proposal (immediately above).

[snowman2]

Thank you all for your time and consideration!

[JonathanGregory]

Thanks for raising the issue, @snowman2! Happy 2024.