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

[GEMPAK #JUX-702363]: GOES-R WV in Gempak

Hi Mike,

I am sure that you know that we lost our GEMPAK developer early last
summer, so there is nobody to give authoritative answers to the questions
you raise below.  Nonetheless, I will attempt to provide answers/guidance
to your questions...

re:
> I've gotten Gempak to plot GOES-R imagery, but as others have noted the
> scaling appears to be off.

Yes.  Scott Jacobs (one of the original GEMPAK developers) has jumped
in to provide help.  Scott's comment with respect to image scaling was
as follows:

  "...There is no need to change any code. 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:
> My question is specifically in regards to water
> vapor imagery, which I haven't seen mentioned in support archives and I'm
> wondering if it's getting handled differently than other IR bands.

Aside from different entries in the imgtyp.tbl file, there should be no
difference in how WV images are handled by GEMPAK.

re:
> Sorry
> in advance for the lengthy email, but I want to post as much info that I've
> found as possible... I think I've got several different issues that may or
> may not be related.

OK.

re:
> I'm using Gempak 7.5.1 on Ubuntu 18.04.
> 
> So the good news is I have Gempak plotting GOES-R data, but it's only
> working from McIDAS area files.  This is true for area files coming over
> the UNIWISC feed and from area files I create myself, both appear the
> same.

Quick question:

- have you fully tested GEMPAK handling of AREA file images created
  by McIDAS?

  I mean:  displaying, using different enhancements (LUTs in GEMPAK
  lingo), overlaying with contours of parameters, overlaying with
  wind barbs, etc.

The reason you ask is I am about to announce to the community that
the imagery you are currently getting in the TEST UNIWISC feed
from conduit.unidata.ucar.edu will become the standard UNIWISC
imagery by the end of the month.  Why?  It seems that GOES-15 will
finally be turned off at the end of the month (January 31 has been
mentioned in a number of notices from NOAA, and we have not seen
anything to make us suspect that they will push off this date).  When
GOES-15 is turned off, it will mark the end of the GINI images that
have been inserted into the NIMAGE feed by our NOAAPort ingest
code.  The TEST UNIWISC feed images are designed to fill the gap
and extend capabilities for the vacuum that will be created when
the generation of GINI images by the NWS/NOAA stops.

re:
> However, in plotting .nc data I've got an odd projection issue; it
> will not be the same domain I specify in GAREA, not even close.
> Furthermore, I can't seem to manipulate GAREA in any way that will result
> in an image domain that makes sense.  I haven't found any Gempak code
> examples anywhere so I'm mostly guessing, but I'm pointing to the data
> files using SATFIL and always using SAT for PROJ.

This would most likely indicate that the addition of support for
GOES-16/17 images to GEMPAK is not fully functional/complete.

re:
> This is using the .nc
> data coming from the Unidata NIMAGE feed, but same results for .nc data I
> stitch together myself using goes-restitch.py (from tiles via Noaaport).

The reconstituted images we are sending in the revamped NIMAGE feed
_should_ be exactly the same as the images producted by goes-restitch.py
with the exception of the names of the images since I am using
goes-restitch.py code to reconstitute the images that are being distributed
in the NIMAGE feed.

re:
> I'm curious if you have any insight on why the .nc files might not be
> working.

Other than the vague comment that the support that Michael added is likely
not complete/completely correct, no, sorry.

re:
> FWIW: Your NIMAGE info page (https://www.unidata.ucar.edu/data/nimage.html)
> is very helpful! I'm following that and getting data into my system from
> that feed, with only minimal and expected edits to pqact entries.  Thank
> you for making that info page!

Thanks for the encouragement.  I always felt that there was a big information
gap in the web pages we provided about satellite imagery.  After creating
the web page for the GOES-R L1b imagery that is being produced by CSPP GEO
and we are distributing in the SATELLITE (aka DIFAX feed), I created a
web page for the NIMAGE feed.  Somewhat at the same time, I also created
a page that shows what the products in the updated UNIWISC feed will
look like:

https://www.unidata.ucar.edu/data/uniwisc_new.html

I will be returning to tweaking this page in the upcoming days in preparation
for our announcement of the change in the UNIWISC feed.  Again, you are
getting the GOES-16/17 imagery from a TEST UNIWISC feed that only a
handful of test sites have access to.

re:
> Since I'm having issues with .nc data, let's say I continue to move forward
> using area files. The next thing I notice is the data does not look
> accurate compared to images I make using McIDAS.  It appears as though it's
> only visualizing the raw data, while IIRC a bi-linear stretch needs to be
> applied.

The SSEC McIDAS developers added automatic stretching of GOES-R imagery.
This is likely the reason that the displays look different.

re:
> I have come across previous support topics such as this one (
> https://www.unidata.ucar.edu/support/help/MailArchives/gempak/msg06574.html)
> and have tried to manipulate both imgtyp.tbl and make custom LUT files. I
> can get WV close to what it should look like, but the low end still seems
> skewed, and that leads me to suspect a bi-linear stretch is still a
> required yet missing step.

When compared to current McIDAS displays which get automatically stretched,
then the GEMPAK images will look different.

re:
> Can you tell me if I'm on the right track in
> thinking this,

Yes, I think so.

re:
> and if so what an appropriate fix for this might be?

Here is where we run into problems since there is nobody in the UPC that
has a mastery of GEMPAK at the level needed.  Given this, I think that it
would be a good idea to post the question to the GEMPAK-using community
via the address@hidden email list.  I feel terrible that we can
not be of more help in this!!

re:
> Also,
> the edits to imgtyp.tbl mentioned in those support threads seem specific to
> longwave IR bands, where WV bands are substantially different; so those
> values given don't seem to be what's needed.

I would imagine that the users that posted questions were focusing on the
thermal IR band first.  We have not received any inquiry before yours that
was specific to the WV bands.

re:
> I apologize for not including any real code/data/image samples.  I've tried
> so many different things it's all a little disorganized right now, figured
> it might be better to see if you had any insight first. But let me know and
> I can include whatever you think might be helpful.

I really wish that I understood the ins and outs of GEMPAK deeply enough
to offer insights, but, alas, I do not.

re:
> As a tangential side-note, getting Gempak 7.5.1 to install on Ubuntu was an
> ordeal.  I believe Michael James was at the very least clued into some of
> these complications given this Gitub issue of his (
> https://github.com/Unidata/gempak/issues/42).  My "fix" to get it to
> install is far from ideal though, basically requiring two separate install
> attempts with an edit to a Makeinc file in between.  I plan on doing a more
> complete write-up to the Gembud list, but wanted to see if there was any
> more recent intel on this front before I did.

Unfortunately, no.  I have built GEMPAK 7.5.1 myself, but that was on a
CentOS 7 system (for the AMS Datastreme project website).  That build was
very easy in that all I had to do was make sure that all of the packages
needed for the build were installed on the target machine.

re:
> Thank you for any help you can provide.

I am sorry that the "help" I can offer is so "thin"!

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: JUX-702363
Department: Support GEMPAK
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.