[McIDAS #JGN-249914]: IMGMAKE

Hi Mike,

re: I STRONGLY suggest that you do not use the latitude or longitude in
your  DIRFILE= regular expression as the longitude may change a bit.

> Very good point, I'll do that here shortly.

Excellent!

re:

> One more thing.  A service change notice just came out that, among
> other things, outlines some of the changes to the GOES-16 metadata.
> Namely the following:
> 
> Product metadata will reflect the new location of GOES-16,
> now on station, about to become GOES East.  The following
> specific product_name global attribute metadata changes
> will take effect with the resumption of the GOES-16 SCMI:
> 
> TMESO becomes EMESO
> TCONUS becomes ECONUS
> TFD becomes EFD
> (PRREGI will not change)
> 
> In case you didn't see the full message, I wanted to point this out
> because that TCONUS - ECONUS change may have implications for
> goes-restitch.

This was, in fact the change that Ryan made to his ldm-alchemy
python restitch script.  None of us put together that the 'T'
meant Test :-(  And, now 'E' means GOES-East :-)

re:
> Thank you again,

No worries.

By the way, I know what is going on wrt to IMGCOPY of an SCMI
dataset image to one of AREA, and I have a fix, but the fix
allows things to progress to the point where I see a problem
with IMGPROBE when interrogating the AREA file copy of the
image.  Unfortunately, I have not yet figured out where to 
fix the IMGPROBE problem.  In case you are interested: the
IMGPROBE problem is that the first thing that is done is to
get a list of valid calibrations for the image, and these
should be RAW, BRIT, and either ALB or TEMP.  The problem
is _something_ is going off and getting the valid calibration
types for ABIN images, and those are RAW, RAD, BRIT and either
ALB or TEMP.  Since the SCMI images have no RAD(ience),
the server can't return a value when IMGPROBE asks for it,
and then IMGPROBE will end complaining about an invalid
calibration unit.  As soon as I find where the incorrect
determination is being made, I will fix it and we should
be good to go.  More later...

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: JGN-249914
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.