NOTE: The cf-satellite mailing list is no longer active. The list archives are made available for historical reasons.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Randy, On 23/11/11 20:54, Tom Rink wrote: > 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. It's nice to see that we can having the same job done twice here with GOES-R :) Just to give some more info, I could just say that the idea of idealized grid you describe is exactly what is done at Eumetsat for geostationary satellite data dissemination. Thus, the disseminated level 1b product are in geos projection: the pixels correspond to the scanning angle steps. Best regards, Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOzf8SAAoJEBdvyODiyJI4YmIH/018apWXwrTSE+d24Q7OzvJh xQnYExRkP0pY7EIKIacHurzQRXmw28mXPezZJSgbYgILf6yoA1PvFdSm46RPiPfx X0j+J5fwH4C4HNSoe4uQLAQkfme6nYvN56CaSURHBdP3Uwfq7hBIX7/HbmuT6wvs AI2+3tOezvQTI1F6SLOBLiwrZncP75npBItRndnSaJGqoJrPW0DyAgkVAtEeOiCC eX3SGC5ZOPXCbFVxWgV4Ywhhb+81Z32qEWd6+6M2VrUKJA1kPyyaC+Ec6mZEZL8o 3EyDlnZQRJlGkskeRfkUTIIMJZxqa2WIbzLK39XxPOTRIoXHHbpwMR30QRNQs5w= =QFUx -----END PGP SIGNATURE-----
begin:vcard fn:Martin Raspaud n:Raspaud;Martin org:SMHI adr;quoted-printable;quoted-printable:;;Folkborgsv=C3=A4gen 1;Norrk=C3=B6ping;;60176;Sweden email;internet:martin.raspaud@xxxxxxx tel;work:+46 (0)11 495 8261 tel;cell:+46 (0)11 495 8261 url:www.smhi.se version:2.1 end:vcard
cf-satellite archives: