Should "GeographicCRS" be used instead of "GeodeticCRS"?

[jonblower]

At the moment we use GeodeticCRS to indicate that a latitude-longitude-[height] coordinate reference system. This is technically correct with respect to ISO19111, but is perhaps not specific enough to be helpful to clients. ISO19111 unified two previous types (GeographicCRS and GeocentricCRS) into GeodeticCRS:

• A GeodeticCRS uses an ellipsoidal approximation of the Earth as a datum
• A GeographicCRS is a subtype of GeodeticCRS, which uses an ellipsoidal coordinate system.
  • An Ellipsoidal CS has its origin on the Earth's surface and uses geodetic longitude, geodetic latitude and height above the ellipsoid. (E.g. CRS84)
• A GeocentricCRS is also a subtype of GeodeticCRS, but uses a spherical or cartesian coordinate system, with its origin at the centre of the Earth.
  • A Spherical CS uses geocentric longitude, geocentric latitude and distance from the centre
  • A Cartesian CS uses orthogonal x, y and z coordinates

Apparently the ISO19111 team is considering re-introducing Geographic and Geocentric CRSs into the spec. The OGC GeoAPI retains the distinction between these CRSs as it is helpful (as does Apache SIS, which is derived from GeoAPI).

I wonder if we should use GeographicCRS instead of the more general GeodeticCRS, as this indicates definitively to clients that the axes will be geodetic longitude, geodetic latitude [and height], without looking up the full CRS definition . This helps when creating coordinate axis labels, for instance.

(Numerical models often use spherical Earths. In this case we would use a Geographic CRS with a datum in which the semi-minor and semi-major axes are equal. There is probably no official CRS definition for this yet.)

[Thanks to Martin Desruisseaux for helping our understanding with this!]

[letmaik]

The problem is that even if the type was given as GeographicCRS, then the axis order is not implicitly defined, so clients would still have to know the specific CRS that is used. What would be the advantage then of using the subtypes instead of the supertype?

[jonblower]

That's a good point. But I still think that "GeographicCRS" is more useful. "GeodeticCRS" is pretty much useless as a type, as it covers so many completely different cases. At least "GeographicCRS" narrows down the options and gives some indication of the data provider's intent.

(By the way, on axis order - I think there's a good case for avoiding left-handed CRSs wherever possible, and there could be something in the spec to discourage this. Not sure it can be completely banned but it would be good if it could be.)

[letmaik]

(Numerical models often use spherical Earths. In this case we would use a Geographic CRS with a datum in which the semi-minor and semi-major axes are equal. There is probably no official CRS definition for this yet.)

Why would this not be a GeocentricCRS?

[jonblower]

Because you would usually measure elevations from the surface of the datum (or something near it), not the centre of the Earth. That makes it a GeographicCRS (although if there is no vertical axis there isn't a practical difference for a spherical Earth).

I just thought of something else:

The problem is that even if the type was given as GeographicCRS, then the axis order is not implicitly defined,

We define "x" to be the longitude/easting in our domain types. Therefore if you have one of our domain types, axis labels of "x", "y" and "z" and a GeographicCRS, you know that the axis labels must be "geodetic longitude", "geodetic latitude" and "height" respectively, without inspection of the CRS itself.

[letmaik]

OK, this would also remove the burden of "having" to use CRS84 for datasets which are not WGS84 based, but rather just using GeographicCRS or GeocentricCRS as type, possibly without an "id" property. Then it would be possible to say that latitude/longitude is used, without specifying an exact datum etc, which is fine for medium/low-resolution model grids.

Do you want to do a pull request for the two spec documents? I can do the rest as in the other pull request.