[IDD #XAT-524030]: GOES-16 and -17 imagery

Hi Luis,

Many apologies for the slow response to your questions below!

re:
> So far, our LDM has been running well and GEMPAK is providing assistance
> to process the data as well to make nice displays for our web site and our
> research analyses.

Very good!

re:
> I just did the notify command and, perhaps, this means that we are
> allowed to receive the NIMAGE products.

Yes, the 'notifyme' output that you sent shows that you are ALLOWed
to REQUEST the NIMAGE feed.

re:
> In fact, this may be the way we are getting the GOES-13 and GOES-15
> datasets.

The original NIMAGE feed was solely populated by GINI imagery that
has been sent in the NOAAPort Satellite Broadcast Network (SBN) by
the U.S. National Weather Service (NWS) for the use by NWS Weather
Forecast Offices (WFOs).  The imagery from GOES-13 stopped being
sent when GOES-16 became the operational U.S. East satellite and
GOES-13 was decommissioned.  GOES-15 imagery is scheduled to be 
stopped when GOES-15 is decommissioned at the end of this year
(the last date I saw as December 31, 2019).

re:
> There is a copy, at the end of this message, from the first
> few lines from the notify output I just got.

Yes, this is how I knew that your machine is ALLOWed to REQUEST
the imagery from the "revamped" NIMAGE feed.  The "revamped"
NIMAGE feed still contains all of the NOAAPort GINI images
from GOES-15 plus the images that we are reconstituting from
the tiles for GOES-16/17 that is now being sent in NOAAPort.

Note:

The volume of imagery in the revamped NIMAGE feed is MUCH greater
than what has been in NIMAGE to date.  To get an idea of how
much data we are talking about, please compare these two real-time
stats volume plots:

NIMAGE - only GINI imagery from NOAAPort
http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?NIMAGE+leno.unidata.ucar.edu

NIMAGE - with both GINI imagery from NOAAPort plus the netCDF4 imagery from 
GOES-16/17
http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?NIMAGE+atm.ucar.edu

re:
> Please let me know what are the next steps to be followed.

The first question you have to answer for yourself is IF the network
bandwidth at CICESE is enough to be able to get all of the netCDF4
imagery that is now available in the "revamped" NIMAGE feed.

It is entirely possible that you may have enough bandwidth, but you will need
to REQUEST the imagery in more than one REQUEST.  For instance, you may need
to split a single REQUEST for everything into two REQUESTs, one for the
GOES-16 images and the other for GOES-17 images.

To become more familiar with all of the imagery in the "revamped" NIMAGE
feed, please take a look at:

Unidata HomePage
http://www.unidata.ucar.edu
  Data -> Satellite Data
  https://www.unidata.ucar.edu/data/index.html#satellite
    NIMAGE (FT21, IMAGE)
    https://www.unidata.ucar.edu/data/nimage.html

As you can see, all 16 bands (wavelength channels) for a variety of coverages
(CONUS, FullDisk, Mesoscale-1, Mesoscale-2, PuertoRico, Alaska and Hawaii)
are contained the the datastream.  The CONUS images are the largest of these
coverages since they are full resolution.  The FullDisk images all have
6 km resolution since there was not enough bandwidth in the NOAAPort SBN
to send over the full resolution FullDisk images (especially the Channel
2 images since the original Channel 2 images have 0.5 km resolution).
The other coverages' bands are all full resolution.

It is possible (likely?) that you will only want to receive some of the
images that are available.  In this case, you will need to tailor
your LDM configuration file REQUEST(s) to just get the bands that you
are interested in.  The web page referenced above has links to example
LDM pattern-action file actions and a listing of the script that is
shown in the example actions.

Another important note for GEMPAK users:

The example LDM pattern-action file action that runs the example Bourne
shell script, L2ProdFile.sh will file images in a logical hierarchy, but
the resulting pathnames are too long for GEMPAK, since GEMPAK has a
maximum pathname length of 108 characters.  This means that you will
need to modify how the files are saved on your system for use in GEMPAK.
We can give you some examples of what others have done if you are
interested.

Also:

The GOES-16/17 images in the "revampled" NIMAGE feed are in netCDF4 format,
and only the latest version of GEMPAK supports use of netCDF4, and in
particular, the internal structure of these netCDF4 files.  Other netCDF4
format imagery does _not_ work in GEMPAK.

So, what to do next?

I recommend that you setup your REQUEST(s) for all or part of the "revamped"
NIMAGE feed and use the example LDM pattern-action file action and associated
Bourne shell script as is so you can get an idea of how much of the feed
you will be able to receive with acceptable latencies.  After you have
adjusted your REQUESTs, if needed, to a set that you can handle, then
you will need to work on modifying how the images are saved on disk so
that individual image pathnames are acceptable to GEMPAK.  While this test
is going on, it will be time to download, build and install the latest
version of GEMPAK.

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: XAT-524030
Department: Support IDD
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.