Dear Jim: A key objective of the geostationary projection when it was defined is that it would work for all geostationary weather satellites whose imagery was projected on an idealized fixed grid … a reasonable design tenet given all the other math in the geolocation algorithm is exactly the same.
We struggled with these names (sweep_angle_axis and fixed_angle_axis). These names are not great, but this was the best we could come up with. It is just really odd that the location of data points in the projection vary as a function of how the imaging instrument works (which is why these projection parameters are instrument-centric). Maybe some fresh eyes can come up with something better. very respectfully, randy > On Apr 1, 2020, at 1:37 PM, JimBiardCics <[email protected]> wrote: > > > Randy, what you say is quite correct. Do you have a suggestion for better > names that don't assume too much? > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/cf-convention/cf-conventions/issues/258#issuecomment-607390902>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AOJPXWLS2WUZB4RUJ5RKFKLRKN3XNANCNFSM4LZAULXA>. > ++++ Hi Daniel: It is not an issue of the generation of the satellite. There is nothing that precludes a 3-axis stabilized satellite from operating like Meteosat. The geolocation algorithm in the gestationary projection includes multiple rotation matrix multiplication operations. The order of these operations vary as a function of how the scanning is done (i.e. sweep and fixed axes) Matrix multiplication is not commutative. very respectfully, randy > On Apr 1, 2020, at 10:46 AM, Daniel Lee <[email protected] > <mailto:[email protected]>> wrote: > > > Moderator > > @user <https://github.com/user <https://github.com/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 > > <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, view it on GitHub > <https://github.com/cf-convention/cf-conventions/issues/258 > <https://github.com/cf-convention/cf-conventions/issues/258>>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AHZDNAJJL66ICSBUEZCVUSLRKNHUBANCNFSM4LZAULXA > > <https://github.com/notifications/unsubscribe-auth/AHZDNAJJL66ICSBUEZCVUSLRKNHUBANCNFSM4LZAULXA>>. > > This list forwards relevant notifications from Github. It is distinct from > [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[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] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>. _____________________________________ Randy C Horne ([email protected] <mailto:[email protected]>) Principal Engineer, Excalibur Laboratories Inc. voice & fax: (321) 952.5100 cell: (321) 693.1074 url: http://www.excaliburlabs.com <http://www.excaliburlabs.com/> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/cf-convention/cf-conventions/issues/258#issuecomment-607350319>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOJPXWN2INNVGOQ35QXHN7LRKNS4LANCNFSM4LZAULXA>. _____________________________________ Randy C Horne ([email protected]) Principal Engineer, Excalibur Laboratories Inc. voice & fax: (321) 952.5100 cell: (321) 693.1074 url: http://www.excaliburlabs.com -- 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-607480360 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].
