[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Datastream #OIZ-367680]: GOES16 location

Hi Greg,

First, I drove your note into our inquiry tracking system so that more
than one Unidata staff member can respond if/when they have pertinent
information.

re:
> Perhaps you can help decipher if there is an issue or not.  I sent email
> (to ldm-users) more than a month ago but never heard from anyone in Unidata.

We typically do not respond to posts to the email lists we maintain
unless we see posts by list subscribers that we believe to be incorrect,
or if we have specific information to share.  We hope that users that
are expecting an answer from us will submit a support inquiry directly
to us.

re:
> The netCDF files for GOES-16 still claim to have a nadir longitude of
> -75.0 when all NOAA web pages claim its position is -75.2.

One thing to remember is that the GOES-16 images being received in
the GRB and NOAAPort are remapped into an idealized satellite projection
(which the NWS refers to as Fixed Grid) before they are disseminated
to end-users.  This is the same approach that EUMETSAT has taken for
METEOSAT imagery for years, and I believe that the JMA is also doing
the same.  This should mean that the central latitude that the
GRB and NOAAport images report as a netCDF global attribute is correct
for the images that are delivered.

Even though I am not a "true believer" in the remapping to a Fixed Grid
approach, it does have the advantage of greatly simplifying the
navigation parameters, and it _should_ account for the fact that a
geostationary satellite actually moves in both the latitudnal and
longitudnal directions continuously.  This movement is the reason
that all geostationary satellites are put through E-W and N-S maneuvers
to keep them in the 1 degree box that they are supposed to occupy
(by treaty or by international agreement).

re:
> Considering my remapping software depends on this value being correct
> and since it claims to be a floating point variable, not integer in the
> netCDF files directly; should this be corrected if indeed the longitude
> is at 75.2?

I do not think so, but I need to test to make sure that the central
latitude reported as a netCDF global attribute matches the latitude
calculated for the center pixel using the navigation parameters included
in the image.

(later)

I did the following in McIDAS-X to compare the Lat,Lon of the central
pixel in an image using the navigation transforms included with the
most recent GRB full disk channel 13 image:

- display the image so that the central pixel (line,element) is exactly
  in the center of the display frame

- interrogate values for that pixel using built-in McIDAS routines

The result of this is that the latitude,longitude calculated for the
central pixel matches the central latitude and longitude included
in the original netCDF-4 image file.  This reinforces my view that
the central latitude reported in the image is _not_ the actual location
of the satellite (which moves continuously), but, rather, the central
latitude of the remapped image.

I hope that this helps...

By the way, the remapping of non-full disk scans in the images being sent
in NOAAPort is a big issue since those remaps result in information loss.
It has been shown by NOAA GOES-R scientists that the second remap (the
first is the one that puts the original image into the Fixed Grid
projection) can lessen the usefulness of the images that are produced
by the second remap.  This becomes important for things like estimation of
fire intensities and areal coverage.  I am under the impression that NOAA
will eliminate the second remap for the NOAAPort-delivered images possibly
sometime this spring. The second remaps are currently for the CONUS, Puerto
Rico and Mesoscale coverages: CONUS is remapped into Lambert Conformal;
Puerto Rico is remapped into Mercator; and the Mesoscale sectors are typically
remapped into Lambert Conformal but they have also been remapped into
Mercator.  The weather service ran tests last fall that showed that leaving
the various coverages in the Fixed Grid projection would eliminate/minimize
the information loss that is now seen.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: OIZ-367680
Department: Support Datastream
Priority: Normal
Status: Closed
===================
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata 
inquiry tracking system and then made publicly available through the web.  If 
you do not want to have your interactions made available in this way, you must 
let us know in each email you send to us.