# Moderator @user # Moderator Status Review [last updated: YY/MM/DD] Brief comment on current status, update periodically # Requirement Summary The [geostationary project](http://cfconventions.org/cf-conventions/cf-conventions.html#_geostationary_projection) should be compatible with all generations of satellites that are used to generate data products from geostationary orbit. # Technical Proposal Summary The current wording of the geostationary projection uses the concept of `sweep_angle_axis` and `fixed_angle_axis`. This is applicable for when instruments sweep their view along a given axis of a data product, whereas the other axis of the product is fixed. An example of this is the Meteosat mission, whose satellites' imagers "sweep" north as the satellite spins about its fixed axis.
This is no longer an applicable description of how newer satellites work. GOES-17, for example, uses a different approach to scans, as will Meteosat Third Generation. These satellites are three-axis stabilised and don't have a fixed axis. As in practice, `sweep_angle_axis` and `fixed_angle_axis` refer to the elevation and azimuth, independent of the instrument's operating principles, I propose adding the capability of having a more general description of the image which does not rely on the underlying scan mechanism. In the end, the grid definition is a mathematical construct and the user is interested in understanding the grid in order to recover Earth coordinates from it; the instrument's function is likely interesting but not important in order to understand the geophysical observation. # Benefits Users and producers of geostationary data products. # Status Quo It is currently possible to encode data using the CF Conventions with the attributes described in Appendix F, but this can be confusing, especially for data producers, when spin and sweep aren't actually related to the instrument in question. # Detailed Proposal It might be a bit tricky to get this right so I'm open to suggestions. I'd like to wait to create a PR until I receive feedback from the community. In a nutshell I propose: - Clarifying the notes related to spin and sweep in order to specify the generations of satellites they apply to. I might also include some language describing what they actually meant in the context of those satellites, some of which will soon be considered legacy. - Add the possibility of using elevation and azimuth rather than spin and sweep axes, whilst stating that the data producer must specify *either* one of elevation/azimuth *or* one of spin/sweep axis. This would not break existing data, and for future data it would be a bit clearer. However, it makes the projection a little bit more involved, as we would have 2 sets of attributes that would essentially be identical. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/258 This list forwards relevant notifications from Github. It is distinct from [email protected], although if you do nothing, a subscription to the UCAR list will result in a subscription to this list. To unsubscribe from this list only, send a message to [email protected].
