Clarify geostationary projection items

[erget]

See issue #258 for discussion of these changes.

It is a work in progress and is not yet ready for review.

[taylor13]

Just curious and maybe I should know this, but what does "WIP" stand for in the issue title?

[JimBiardCics]

Work In Progress

[erget]

Hi Karl, sorry, it's shorthand for "Work In Progress". I didn't know when I'd have a chance to finish this so I thought it was more important to note concretely what I want to do based on the discussion in #258 in the manuscript, obviating to re-read the long thread before restarting. After reaching a state that I think can be discussed, I will remove the "WIP" prefix.

[TomLav]

Hei @erget and all,

I happen to have spent the week-end on this projection, browsing through the history, and trying to understand what we were encoding in the CF object. I received great help from the Pytroll community.

I propose a small clarification (against the current 1.9 doc) to:

In the case of this projection, the projection coordinates in this projection are directly related to the scanning angle of the satellite instrument.

First, we have "this projection" twice.

Second, "related to the scanning angle". Aren't they the scanning angle themselves, can we drop "related to"?

Third, it seems to me that this projection introduces a mismatch between what is stored in the CF file (the angles in radians) and what "mainstream" projection libraries (Proj) use (distance from origin in meters). So that the wording "the projection coordinates" could be confusing.

Thus, I humbly suggest:

In the case of this projection, the x and y coordinates stored in the file are directly the scanning angles of the satellite instrument.

I also suggest a sentence to be added in the bullet points, to warn the non-expert user, along the lines of:

Note that the CF convention stores the scanning angles (with canonical unit gradients) as the coordinates for this projection, while the popular library PROJ uses distance from origin (meters).

I understand the implementation in PROJ shouldn't be driving the CF convention (and it didn't), but I feel we could be explicit for the non-expert users (after all, AFAIK, the geostationary projection is the only one in CF where CF stores something different that what PROJ returns/expects).

[erget]

@TomLav thanks for this input - @JonathanGregory is moderating this discussion and has requested that discussion take place on the linked issue #258. Would you mind re-posting this there for the sake of traceability?