Hi all, Thanks very much for your inputs! A few points to respond to:
>From Randy: > if the current geostationary projection parameters are deprecated, I would be > very surprised if the products for the yet to be launched GOES-R series > satellites (T and U) will reflect any changes you are proposing. I understand, this is an issue that's present with all of the major satellite data producers. I do not intend to deprecate anything, but rather to provide clarifications so that implementing things are easier. @steingod thanks for chiming in as well, it's very much appreciated. # TLDR I myself have sought further clarification of the issue with one of our optical imager engineers @ameraner who has been kind enough to delve deep into the details of how `sweep_angle_axis` and `fixed_angle_axis` are used. I think that the issue can in fact be resolved not by adding additional attributes, but rather by clarifying in the notes how these axes are used. [PROJ probably has the best documentation on this](https://github.com/OSGeo/PROJ/blob/master/docs/source/operations/projections/geos.rst) - concise and understandable - and I believe that CF would profit from similar clarity in the notes. I'll propose specific changes to the notes in a TBW PR, but surgery on the Conventions needs care and so I'm summarising the specifics of the issue below. # Nuts and bolts [As nicely described by PROJ](https://github.com/OSGeo/PROJ/blob/master/docs/source/operations/projections/geos.rst) the geostationary projection works using a gimbal model of an observation point's viewing angle, like thus:  Some terms: **Sweep-angle axis**: This is the outer-gimbal axis, the one whose axis is aligned with the "base" in the figure. If you imagine this as the Earth, its equator always describes the same great circle. **Fixed-angle axis**: This is the inner-gimbal axis, the one whose axis is attached to the "equator" of the outer-gimbal circle. Therefore its "equator" describes a different great circle depending on the position of the outer gimbal. As you can see, the definitions could be considered counterintuitive but they're widely adopted and there's no reason to (try to) change them. The important thing to note is that even if you know the azimuth and elevation of a given point, you also have to know which axis is aligned with the conceptual outer and inner gimbal. Order of operations matters in this case. _This contradicts what I was asserting earlier_ and has led to implementation difficulties, not because the attributes are incorrect, but rather because they require some mental gymnastics to parse. The solution is to clarify a few things in the notes: - How the axes correspond to a gimbal view, as this has confused developers - That the y-axis (in existing implementations, and probably for the foreseeable future) aligns with N/S and the x-axis aligns with E/W. This is true in practice but is not specified in our description. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/cf-convention/cf-conventions/issues/258#issuecomment-613355463 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].
