Don't require longitude and Latitude for projected coordinates

[erget]

In the current Conventions (V1.7), the section

[[grid-mappings-and-projections, Section 5.6, "Horizontal Coordinate Reference Systems, Grid Mappings, and Projections"]]

on CRSs states that:

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.

This strong requirement results in large amounts of locational metadata for many data sets.

A lot of data sets are defined with respect to projected CRSs or other spatial coordiantes which are not longitude and latitude.
The CRS definition is supplied and many packages provide the capability to calculate longitude and latitude coordinates from projected coordinates.

In some cases, the 2D longitude and latitude auxiliary coordinate variables are the largest part of the payload, and add limited value to the data producers.

Given the prevalence of software to support such transforms and the cost in data volume, this mandate appears to be too strong, and could be relaxed, as long as a grid_mapping is supplied.

I propose a motion to relax this constraint and enable data producers to provide well geo-referenced spatial coordinates without the inclusion of explicit longitude and latitude values.

[erget]

@dblodgett-usgs can you moderate, and @marqh would you be willing to summarise?

[marqh]

#133 is approaching a suitable text proposal, with detail review from a number of contributors.

Please may I ask whether there are any objections or concerns inn principal with this proposal? Or, is this now a matter of agreeing the detail text?

[dblodgett-usgs]

I agree with the direction this is going. I would like to see the need for 2d lat/lon described in terms of the functionality it provides. e.g. Having unprojected lat/lon is required for software that doesn't know projections but practically very burdensome (if not breaking) for data where 2d lat/lon is too large for whatever reason.

[JimBiardCics]

I agree with the proposal. I think it is just a matter of revising the text.

[kenkehoe]

I agree and voted with a thumbs up on original post above since the text says "propose a motion".

[davidhassell]

Just doing a bit of due diligence.

One of the reasons stated for this proposal is "Given the prevalence of software to support such transforms". Looking at Appendix G, I see that all of the projections are defined by PROJ, so I would say that there certainly exists widely available software for those. Can someone confirm/deny that PROJ deals with rotated pole coordinate systems?

What would happen if, in the future, CF defines a grid mapping which is not supported by PROJ? Should the existence of some third party software be a prerequisite for a new grid mapping to be accepted? Or would it be up to software library maintainers and general users to code up their own conversion algorithms in this case?

[As an aside, I wonder how many CF-aware software libraries currently use PROJ (or something else) to create lats and lons from grid mappings? cf-python currently does not, relying instead on the 2-d auxiliary coordinates, but will be upgraded to do so if this issue is accepted.]

[JimBiardCics]

@davidhassell It appears that you can specify the rotated pole coordinate system in proj4 as an example of a general oblique transformation. The proj4 string would look something like this example.

+proj=ob_tran +o_proj=latlon +o_lon_p=83 +o_lat_p=42.5 +lon_0=180

[davidhassell]

I'd like to suggest replacing the current first three paragraphs of section 5.6 in PR #133. These are:

A grid mapping variable may be referenced by a data variable in order
to explicitly declare the coordinate reference system (CRS) used for
the spatial coordinate values. For example, if the spatial coordinates
are latitude and longitude, the grid mapping variable can be used to
declare the figure of the earth (WGS84 ellipsoid, sphere, etc.) they
are based on. If the spatial coordinates are easting, northing, and
elevation in a map projection, the grid mapping variable declares the
map projection CRS used and provides the information needed to
calculate latitude and longitude from easting and northing.

When the coordinate variables for a horizontal grid are not longitude
and latitude, it is required that further information is provided to
geo-locate the horizontal position. A grid mapping variable provides
this information.

If no grid mapping variable is provided and the coordinate variables
for a horizontal grid are not longitude and latitude, then it is
required that the true latitude and longitude coordinates are supplied
via the coordinates attribute.  

The main differences are replacing "spatial" with "horizontal" (grid mappings do not apply to the vertical spatial dimension); and clarifying the agreed position that when the coordinates are not lat/lon either a grid mappaing, or lat/lon coordinates, or both are required.

Here's my new text:

A grid mapping variable may be referenced by a data variable in order
to explicitly declare the coordinate reference system (CRS) (or
systems) used for the coordinate values of the horizontal grid. For
example, for horizontal coordinates of latitude and longitude, the
grid mapping variable can be used to declare the figure of the earth
(WGS84 ellipsoid, sphere, etc.) they are based on. For horizontal
coordinates are easting, northing, and elevation in a map projection,
the grid mapping variable declares the map projection CRS used and
provides the information needed to calculate latitude and longitude
from easting and northing.

When the coordinate variables for a horizontal grid are not longitude
and latitude, it is required that further information is provided to
geo-locate the horizontal position. This is provided by a grid mapping
variable and/or latitude and longitude coordinates, the latter being
supplied via the `coordinates` attribute.

[davidhassell]

Thanks, @JimBiardCics for the PROJ details - that's good.

With regards my other question (about future mappings not supported by PROJ), I'm fine with this not being an issue at all, but thought it worth mentioning because of the rationale behind the raising of this issue. Does any else have views on this?

[marqh]

In summary, the constraint on always providing explicit latitude and longitude coordinates is proposed to be relaxed, as long as a relevant grid mapping variable is provided.

The text changes are detailed in https://github.com/cf-convention/cf-conventions/pull/133/files