Hi Randy,
On 11/23/11 9:27 AM, Randy Horne wrote:
Martin:
Thanks for getting back to me !
If I may be so bold as to better explain what we are doing in GOES-R
GS with the hope you will continue to provide us with valuable insights …
Unlike previous generations of GOES, the level 1b and 2 products
generated from the imager will exist on a idealized fixed grid. What
this means is that the products will remain in the satellite's
projection space, but any jitter caused by the fact the satellite's
navigation is imperfect will be corrected in level 1 processing. The
origin of this idealized fixed grid will be at the intersection of the
equator and the designated longitude for the particular satellite.
(GOES has an active east and west satellite.
The CF conventions currently require lat/lon coordinates in the
product file. This is a problem for us. This topic was discussed on
the CF metadata message board in the August time-frame of this year.
I think the way it ended was that the NetCDF development team,
specifically John, took an action to figure out what to do.
In the NetCDF files we produce, we (typically) will generate two
dimensional arrays on this idealized fixed grid. As a result, we want
a CF conventions compliant grid mapping that will allow users of our
product files to easily map the (x,y) coordinates of the NetCDF data
variables we generate to lat/lon coordinates.
I work on the GOES-R AWG Imagery Team. We've essentially done this with
simulated ABI full-disk and meso datasets. The files contain (x,y) in
radians
with a Projection variable setting up the transform. As Martin
re-iterated, this
is somewhat non-standard as CF projections define (x,y) meters (distance
on the
projection plane), but some simple extensions to the ncIdv.jar allowed us to
to do nav algorithmically. We also have master (lon,lat) files for the
three resolutions,
2km,1km,hkm. So we already have the Java code to do this. It would be nice
if this could be standardized. We've done this now to test the
concept, we can't
always wait for things to be decided externally and by committee.
Tom
very respectfully,
randy
Hi Randy,
Funny that you bring this up, since the proposal I want to make
originates from a discussion with Tom Rink, which apparently works
also on GOES-R and netCDF/CF...
Anyhow, the difference between geos and vertical perspective is that
the former is directly linked to the scanning angle, while the latter
is related to the distance between pixels on a projection plane.
For example, in order to get the lon/lat with geos from the scanning
angle alpha in radians from a satellite at height h, the projection
coordinates to provide would simply be something like h*alpha.
Instead, the vertical perspective would require something along the
lines of h*tan(alpha) as projection coordinates.
Snyder is right of course when he says that vertical perspective is
how the earth is viewed from space. The geos is actually distorted to
that regard, since it's dependent on the viewing geometry of the
satellite instrument. But that is the way we receive the data, and
geos makes it easier to compute lon/lats from there, hence my
proposal. For more technical details about geos, see the CGMS 03
document I cite in the original post.
Don't hesitate to ask more if I wasn't clear !
Best regards,
Martin
----- Reply message -----
Från: "Randy Horne" <rhorne@xxxxxxxxxxxxxxxxx
<mailto:rhorne@xxxxxxxxxxxxxxxxx>>
Till: "cf-metadata@xxxxxxxxxxxx <mailto:cf-metadata@xxxxxxxxxxxx>"
<cf-metadata@xxxxxxxxxxxx <mailto:cf-metadata@xxxxxxxxxxxx>>,
"Raspaud Martin" <martin.raspaud@xxxxxxx <mailto:martin.raspaud@xxxxxxx>>
Kopia: "cf-satellite@xxxxxxxxxxxxxxxx
<mailto:cf-satellite@xxxxxxxxxxxxxxxx>"
<cf-satellite@xxxxxxxxxxxxxxxx <mailto:cf-satellite@xxxxxxxxxxxxxxxx>>
Rubrik: [CF-metadata] Making a proposal for the addition of the
geosprojection
Datum: tis, nov 22, 2011 22:36
Martin:
I am working the GOES-R program (next generation geostationary
weather satellite program).
It is our plan to generate CF convention compliant NetCDF product
files that are projected from the idealized scanning imager on the
satellite. We had thought the vertical perspective was the
appropriate projection.
I went back and read through the "vertical perspective projection" in
John Snyder's document (Map projections- A Working Manual), and it it
unclear why this existing projection in the CF conventions is not
applicable. It is true that the GOES-R satellite imager (i.e.
camera) does not precisely faces the center of the Earth because it
is scanning in approximately 500 km N-S swaths from west to east, but
I am confused how this characteristic changes the projection geometry.
Could you augment the explanation you have already provided ?
very respectfully,
randy
---------- Original Message ----------------------------------
From: Martin Raspaud <martin.raspaud@xxxxxxx
<mailto:martin.raspaud@xxxxxxx>>
Date: Tue, 22 Nov 2011 13:28:32 +0100
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi all,
>
>There seems to be a need from the weather satellite folk to add the
>"geos" projection to the list of projections in the CF metadata.
>
>"geos" stands for geostationary. The projection is described in detail
>in the "CGMS 03, LRIT/HRIT Global specification" document.
>(see here also:http://remotesensing.org/geotiff/proj_list/geos.html)
>
>My question is thus: how do we make a proposal for the addition of the
>projection ?
>
>On a side note, it looks like "Vertical perspective" and "geos" are
>mixed up in the current version of the conventions (the link to "geos"
>is provided under "Vertical perspective"). The difference is that the
>geos projection is related to scanning angles of the satellite, so that
>the projection is done on a piece of a sphere, while the vertical
>perspective is a kind of orthographic projection.
>
>Here comes a possible text for this projection:
>
>
>Geostationary
>- -------------
>
>grid_mapping_name = geos
>
>
>Map parameters:
>
> latitude_of_projection_origin
>
> longitude_of_projection_origin
>
> perspective_point_height
>
> false_easting
>
> false_northing
>
>Map coordinates:
>
> The x (abscissa) and y (ordinate) rectangular coordinates are
>identified by the standard_name attribute value projection_x_coordinate
>and projection_y_coordinate respectively.
>
>Notes:
>
> Notes on using the PROJ.4 software packages for computing the
>mapping may be found at
>http://www.remotesensing.org/geotiff/proj_list/geos.html. These notes
>assume the point of observation is directly over the equator.
>==============================
>
>
>Thanks a lot !
>Best regards,
>Martin
____________________________________
Randy C. Horne (rhorne@xxxxxxxxxxxxxxxxx
<mailto:rhorne@xxxxxxxxxxxxxxxxx>)
Principal Engineer, Excalibur Laboratories Inc.
voice & fax: (321) 952.5100
url: http://www.excaliburlabs.com
_______________________________________________
cf-satellite mailing list
cf-satellite@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/