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

[LDM #CBT-761337]: GOES-17 data

Hi Mike,

re:
> OK Tom, thanks for checking this out.  The upshot is that this exercise did
> prompt me to take a better look at my ldmd.conf file,which did have some
> oddities.

I hope that you found and fixed the redundant/unneeded REQUEST for CONDUIT 
gfs.*0p25 data.  Unneeded since all of CONDUIT is/was already being
REQUESTed by virtue of the 5-way split REQUESTs.

re:
> BTW - this webpage shows some of the new GOES imagery produced by Gempak
> (just in time for classes).  So it can be done, albeit with a fair amount
> of fiddling and customization of color tables, etc.
> http://www.met.sjsu.edu/weather/sat2/

Who sat on the earth? ;-)

As far as fiddling with color tables, we were advised by Scott Jacobs
that there is a need for users to adjust a GEMPAK table:

 "There is a table that sets the min/max pixel values for an image. The
  table is $GEMPAK/tables/sat/imgtyp.tbl. The max values for GOES16 and
  GOES17 non-visible imagery need to be adjusted. I tested with a Channel
  4 image and had to set the max value to 128. I did this because the
  NetCDF file says that the data range is 0-4095. However to map to the
  color tables, the data is scaled to 0-255 by shifting to the right 4
  bits. This should work, but I found that the data range for the image
  I tested is actually 0-2082. When this range is shifted 4 bits, the\
  range becomes 0-(about)130. Modifying imgtyp.tbl with the new max value
  makes the colors look correct."

re:
> Questions/musings:
> Is the translation of the raw ABI GOES "SATELLITE" feed to "NIMAGE" feed
> done by Unidata or SSEC?  Reason I'm asking is there are many things I
> haven't been able to figure out, given limited time and abilities.

The ABI L2 images that are in NOAAPort are created from the ABI L2 tiles
that are sent in NOAAPort.  What we do is stitch together the tiles into
full scenes.  The internals of the resultant files are, in essence, 
exactly the same as the internals of the tiles with the exception of
the larger image sizes.  All of this is done at/by Unidata.  SSEC has adopted
our method of stitching together the tiles and naming of images for
use by their Data Center.  The NIMAGE feed originates here in Unidata
and is, unfortunately, not replicated anywhere else.

re:
> E.G. A Goes 17 plot with default Gempak mapping looks like this (180 off
> longitude, so  minus sign somewhere!):
> http://www.met.sjsu.edu/weather/goes17/Goes17-sample.gif

This is a GEMPAK issue, not something with the images which work
flawlessly in McIDAS-X, IDV, McIDAS-V and AWIPS.

re:
> But I can get it to plot US map in correct place (but anytime I expand the
> map to some world view it goes 180 degrees off.)
> http://www.met.sjsu.edu/weather/goes17/WV-F/g17-ani.html

Again, this is a GEMPAK issue.

re:
> And yet Goes16 seems OK out of the box:
> http://www.met.sjsu.edu/weather/goes16/WV-F/g16-ani.html

Because of this, I am left with the impression that the GEMPAK issue is
somehow caused by the dateline being in the field of view.

re:
> There are other oddities of course for both 16/17 such as Channel02 and
> Channel14 (there could be more) have the color scales reversed so a custom
> color table is required.

For the GRB L1b images, the differences are undoubtedly due to the
bit_depth of the different channels.  The NIMAGE ABI L2 imagery,
on the other hand, all have the same bit_depth of 12.  Given this,
I think that all VIS channels should be more or less the same as
each other, and all IR channels should be more or less the same as
each other.

re:
> Just throwing some of this out there in case it's of interest to anyone at
> Unidata or the broader community.

I am sure that there will be many support emails as the school year really
gets rolling.  We're in a very difficult situation (as you know) since we
don't have anyone familiar enough with GEMPAK to figure out the remaining
oddities and fix them.

re:
> Thanks as always for your great support!

Beer? ;-)

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: CBT-761337
Department: Support LDM
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.