[McIDAS #GGF-537346]: Making AREA files of GOES16 data for NMAP

Hi Chris,

re:
> This is a bit of a cross-over question that includes both McIDAS and
> GEMPAK elements.

OK, no worries.

re:
> We recently had a Doppler on Wheels (DOW) visiting, and we decided to
> make regional files of the GOES16 CONUS data to facilitate fast loading
> of the data in the IDV and/or McIDAS-V for our students.

Good idea.

re:
> I was able to make regional views of the data with something like:
> 
> ADDE is available from wxdata.db.erau.edu
> 
> imgcopy.k IOP1/CONUSC02 MYDATA/IMAGES STA=MCO ALL=YES SIZE=1000 1500 
> PLACE=CENTER STYPE=VISR

It is most likely that you specified MYDATA/IMAGES.288 as the output image.

re:
> cp -v AREA0288 CH02_180630_2357
> ‘AREA0288’ -> ‘CH02_180630_2357’

OK.

re:
> [ldm@hurricane Channel02]$ areaInfo CH02_180630_2357
> CH02_180630_2357
> 3.9_20180630_2357 GOES-16 1km

I don't know much about areaInfo, but I understand your use of it.

re:
> This seems to verify that this is now an 8-bit (1 byte) AREA file, right?

Nothing in the areaInfo output indicates that the output is an 8-bit
image.  But, the STYPE=VISR keyword clause in the IMGCOPY command line
does say to create an 8-bit image, and the output format should be AREA
if your dataset definition for MYDATA follows the Unidata McIDAS-X model.

re: 
> (Any idea why it thinks channel 2 is the Near IR band?)

I assume that areaInfo is hardwired to think that channel 2 is the 3.9
um channel like it is for GOES GVAR images.  I'm willing to bet that
areaInfo knows nothing about GOES-R/S images.

re:
> These files seem to work, and can be viewed properly in the IDV, but
> when I drop them into a path that NMAP sees, then they are not given
> the proper navigation.  (i.e. They are presented with the CONUS map
> in the default location, or whatever map was present before loading,
> rather than being a Florida regional view.)

Michael was never able to get the McIDAS fixed grid navigation module
(nvxabin.dlm) to work correctly in GEMPAK.  It works in some builds
but not in others.  The cause of this is a mystery, sigh.

re:
> I had similar issues trying to do this for the full CONUS images as well.
> Should I be using IMGREMAP instead of IMGCOPY?  Should I be doing
> two steps?

The successful approach that others have taken is to IMGREMAP GOES16
imagery into a projection that GEMPAK understands (e.g., LAMB, PS, MERC, TANC,
MOLL, RECT).

re:
> Do we need Gempak table entries to accommodate the GOES-16 data?

Yes, but I think that Michael has already added those to the most recent
GEMPAK release.  Since I am definitely no GEMPAK expert, I can not guarantee
that my view here is correct.

re:
> Any and all guidance is GREATLY appreciated!

I would try using IMGREMAP (imgremap.k) and specifying the PRO= projection
to be something like RECT or MERC, and then see if the result works correctly
in GEMPAK.

FYI: I am about ready to start creating GOES-16 imagery in a MSAT projection
(but rotated so that the central longitude coincides with the central
longitude of GOES-16) and then distribute those sectors (CONUS, Mesoscale-1/2
and Full Disk (but the Full Disk sectors will have 6 km resolution))
in the Unidata-Wisconsin datastream (IDD feed type UNIWISC (aka MCIDAS)).
I am being forced to do this because of the problem with getting GEMPAK
to understand the GOES-16 Fixed Grid projection, sigh!

re:
> Thanks!

No worries.

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: GGF-537346
Department: Support McIDAS
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.