Feedback: Ext-Swath

[erget]

The extension looks like it a good step forward towards standardizing the description of satellite data encoded in NetCDF. I'll send a pull request today with some (very minor) typographical suggestions that I'll reference against this issue.

featureTypes

I think that getting these new featureTypes approved is a good step, but we should position them carefully within the CF standard so that they're easy to find - at the least there should be a new table listing all supported featureTypes in the entire standard, preferably in neither of the chapters on Discrete Sampling Geometries or Swath Data, as these are more specific.

Geo-Shapes

I notice that you require here that the vertices are listed in anticlockwise order viewed from above with the Earth's surface. I agree with this, but not all implementations might. In order to give weight to the requirement I suggest mentioning that it is based on the Simple Features Access standard (ISO 19125) which is implemented widely. That gives it a little more weight and answers the question why you choose to do it that way.

Field-of-Regard profile

I might be interpreting Example 22 wrong, but I would be confused if I were to receive data formatted like that. How are Earth coordinates reconstructed for the individual FOVs inside the FORs? Without a priori knowledge of the geometry of the FOVs within the FOR I would be at a loss as to where to place the individual FOVs.

Wider issue: Coordinate variables

This is not a problem with the current proposal, but more of a general question which could lead to noncompliant data being produced. The solution would probably have to be found within the more general parts of the CF convention, but perhaps we could address this with the swath proposal?

At EUMETSAT we're struggling with CF compliance and data volume. I wouldn't be surprised if this also the reason why GOES-16 is not giving explicit coordinates, but instead uses a projection for geolocation. Providing the coordinates for individual pixels is just too costly when bandwidth is a limitation for a lot of our applications.

I find the CF convention a bit unclear. In CF 1.6, Chapter 5.0, it seems possible to provide projected coordinates alone, without latitude and longitude coordinates.

... If the coordinate variables for a horizontal grid are not longitude and latitude, it is recommended that they be supplied in addition to the required coordinates. For example, the Cartesian coordinates of a map projection should be supplied as coordinate variables in addition to the required two-dimensional latitude and longitude variables that are identified via the coordinates attribute. ...

Keywords here are are recommended, for example, etc.

That would make GOES-16 CF compliant because the projection is well-described, even though it doesn't fulfill this recommendation.

However, if you skip ahead to Chapter 5.6:

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.

Hmm.

If it really is required to supply coordinates with each data point, many providers may be forced to produce noncompliant data just due to bandwidth issues, as many products are distributed via satellite link with very limited bandwidth.

A possible solution would be to relax the requirement to provide true latitude and longitude coordinates, and instead require that, if they are not provided, they be reconstructable using the grid_mapping attribute which according to the standard already may be used to map projection to geographic coordinates.

[ghost]

featureTypes

I think that getting these new featureTypes approved is a good step, but we should position them carefully within the CF standard so that they're easy to find - at the least there should be a new table listing all supported featureTypes in the entire standard, preferably in neither of the chapters on Discrete Sampling Geometries or Swath Data, as these are more specific.

The fate of the featureType attribute in the Swath proposal is still to be decided. It was introduced in the proposal early on but it does not seem to be that important. So far the swath data encodings rely only on CF's handling of coordinates which is a core CF capability.

Another issue is that data producers will have to identify the correct featureType value for most of the variables in one file and this may be too cumbersome. It is convenient to name all the different swath feature types but not sure those need to be put in a variable attribute. And if not a variable attribute, is there any reason to make it a global attribute and what would its value(s) be then?

Geo-Shapes

I notice that you require here that the vertices are listed in anticlockwise order viewed from above with the Earth's surface. I agree with this, but not all implementations might. In order to give weight to the requirement I suggest mentioning that it is based on the Simple Features Access standard (ISO 19125) which is implemented widely. That gives it a little more weight and answers the question why you choose to do it that way.

Actually, this is included in the draft of the CF 1.7 convention: http://cfconventions.org/cf-conventions/cf-conventions.html#cell-boundaries, Bounds for 2-D coordinate variables with 4-sided cells.

Field-of-Regard profile

I might be interpreting Example 22 wrong, but I would be confused if I were to receive data formatted like that. How are Earth coordinates reconstructed for the individual FOVs inside the FORs? Without a priori knowledge of the geometry of the FOVs within the FOR I would be at a loss as to where to place the individual FOVs.

That feature type is explicit about storing geolocation for FORs as a whole. Geolocation for individual FOVs is not what it is supposed to provide. Example 21 is for that.

Wider issue: Coordinate variables

This is not a problem with the current proposal, but more of a general question which could lead to noncompliant data being produced. The solution would probably have to be found within the more general parts of the CF convention, but perhaps we could address this with the swath proposal?

I think this is the issue for the CF convention. The CF Satellite community could mobilize to propose possible solutions that would work for their applications.

I find the CF convention a bit unclear. In CF 1.6, Chapter 5.0, it seems possible to provide projected coordinates alone, without latitude and longitude coordinates.

If the coordinate variables for a horizontal grid are not longitude and latitude, it is recommended that they be supplied in addition to the required coordinates. For example, the Cartesian coordinates of a map projection should be supplied as coordinate variables in addition to the required two-dimensional latitude and longitude variables that are identified via the coordinates attribute.

Keywords here are are recommended, for example, etc.

That would make GOES-16 CF compliant because the projection is well-described, even though it doesn't fulfill this recommendation.

However, if you skip ahead to Chapter 5.6:

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.

Hmm.

My interpretation of the first quote is that longitude and latitude coordinates are always required.

A possible solution would be to relax the requirement to provide true latitude and longitude coordinates, and instead require that, if they are not provided, they be reconstructable using the grid_mapping attribute which according to the standard already may be used to map projection to geographic coordinates.

I agree. The geolocation provided in files should be tailored to the intended uses of the data.