[McIDAS #JGN-249914]: IMGMAKE

Hi Mike,

Sorry for the slow reply, I was in meetings this morning...

re:
> I made an interesting discovery yesterday that you may want to know
> about.  When GOES-16 is in 5 minute full disk mode (abi_mode 4), the
> metadata for the CONUS data changes in several ways.  The effect is
> after going through ldm-alchemy's goes_restitch, the data is stored in
> a TCONUS subdirectory instead of a CONUS subdirectory.

Interesting.  I had noticed the appearance of TCONUS directory in July,
but I did not tie it to ABI scanning in mode 4.  Thanks for alerting me
to this!

re:
> GOES-16 has
> been in this mode since yesterday afternoon and I noticed your
> lead.unidata.ucar.edu server doesn't seem to have CONUS data from
> today... so this may be why.

Thanks!

re:
> The silly thing about it is this feels like the way it should be,
> TCONUS does have a different domain from CONUS.

Yes, but it has the same projection information and size as the CONUS
scans.

re:
> But it still comes in
> under (TIRC..) and we'd only get one or the other, never both at the
> same time.  So the most appropriate way to account for this is still a
> little debatable in my mind.

Hmm... Off of the top of my head, I would say that they both should
be classified as CONUS scans.  I base this comment on the variability
in spatial coverage in NOAAPort-delivered GINI imagery while not trying
to label the images as being different.

re:
> The decision I went with was to change and re-run that dsserve batch
> file.  I changed .../GOES16/CONUS/... to .../GOES16/*CONUS/... which
> should account for both subdirectories.

Yup, this will do it.  I just make the same change on lead.unidata.ucar.edu
to the NPGOESR dataset CONUS elements.

re:
> I also have a general McIDAS question regarding MAG.  When defining
> our sectors for satellite imagery we use MAG to adjust zoom, but since
> it only accepts integers the difference between can be substantial.
> Is there any way to have more fine control when zooming in or out?
> Or, dare I propose, change MAG to accept float values?

No, integral MAG factors is a hallmark of McIDAS treatment of imagery.
The reasoning is that a blow down (negative MAG= factors) results
in a sampling of pixels, not an averaging, and a blow up results in
the replicating of pixels.  This approach results in the pixels
that are displayed being the actual ones from the original image,
not some function of the original ones (e.g., average, spline fit,
etc.).

re:
> I feel like we
> use McIDAS differently than most so I'm not sure how much this has
> come up or if it's something others have requested.

One can achieve the same sort of effect by an appropriate use of
IMGREMAP.  It is my understanding that the satellite meteorologists
who are the target users of McIDAS do not want pixel values changed
from originals.

Just so you now:

- I made a slight modification to the calibration block setting
  routine in abisutil.c that should eliminate the black pixels
  at 242K that you reported in a previous email

  This change is in the code running on lead.unidata.ucar.edu.

- contacted SSEC about what ADDE server naming convention they would
  like to see for ADDE servers for NOAAPort-delivered GOES-R imagery

  I had chosen ABIS (e.g., abisadir.cp, abisaget.cp) since it made
  sense to me (ABI SBN), and because the name that I though would
  be most appropriate, ABIN (ABI NOAAPort), was already taken.  Their
  recommendation was to use ABIW (ABI Weather service).  Based on
  this recommendation, and my intention to get my servers adopted
  into the McIDAS core, I have changed the name of the files and
  procedures that I am developing.

- while talking to SSEC, I learned that they have recently made a
  number of changes to the GOES-R calibration module, kbxabin.dlm

  I started to use the existing version of their GOES-R calibration
  module as a template for a new calibration module for the NOAAPort
  delivered GOES-16 data (both imagery and products).  I am now
  evaluating the code modifications that I am seeing in the newer,
  unreleased calibration module.
  
- I will put together an update that contains the code modifications
  that I have made to the ADDE servers and let you know about it
  in a few days

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.