[McIDAS #JGN-249914]: IMGMAKE

Hi Mike,

re: since it is almost 100% sure that the Weather Service is going to stick
with converting to SCMI format for NOAAPort distribution,

> Does this mean they'll continue to transmit reprojected as opposed to
> transmitting everything in fixed-grid?  I hadn't heard anything but
> figured that was more or less bound to happen at this point.

No, not necessarily.  My gut feeling is that they will send all ABI
images in NOAAPort in the Fixed Grid projection while keeping the
format of the images SCMI.  If they had done as I had hoped (not
convert to SCMI), then everyone could use the core SSEC McIDAS ABIN
ADDE servers directly.  This would have had the benefit of not having
to use two different servers, and being able to use those same servers
on the images downloaded from CLASS.

re: To see the reworked names, do the following from a McIDAS-X session:
> >
> > DATALOC ADD RTGOESR lead.unidata.ucar.edu
> > DATALOC ADD NPGOESR lead.unidata.ucar.edu
> >
> > DSINFO IMAGE RTGOESR
> > DSINFO IMAGE NPGOESR
> 
> Okay, I see what you're talking about here.  So for an end-user of
> your remote feed it would just be a change in naming convention and
> not much else, right?

Correct.

re: the L2 products being sent in NOAAPort are also part of NPGOESR

> I do see that!  And speaking of distractions I've already gotten
> myself side-tracked in playing with the new data.  Thanks for sharing.
> :)

:-)

re: some tweaking will be needed

> I suppose the first thing I'd want to do, for the sake of consistency,
> is make my local dataset names match this new convention.  That's not
> a big deal.

Yes to both.

re:
> For the L2 data, is there any special way to save that
> data from NOAAPort, or do I just need to point to where I store the
> *.nc4 files?

Actually, yes one does need to jump through some hoops wrt to the
naming convention used for the L2 products.  I crack the netCDF file
and extract the name of the original product (global attribute
'dataset_name' and use it to name/link to the product filed to disk
by Ryan's ldm-alchemy routine 'strip_header.py'.  What really should
be done is rework 'strip_header.py' to do all the needed work, or
write a new LDM pattern-action file action that does all of the work.

Take a look at the difference in directory structure that 'strip_header.py'
creates for L2 products and what my script is producing:

http://thredds-test.unidata.ucar.edu/thredds/catalog/satellite/goes16/catalog.html

Then click on:

GOES-16 -> Products
http://thredds-test.unidata.ucar.edu/thredds/catalog/satellite/goes16/GOES16/Products/catalog.html

Compare:

A99 -> 20171110

   GOES16_A99_20171110_0000.nc4
   GOES16_A99_20171110_0001.nc4
   ...

to:

AerosolDetection -> CONUS -> 20171110

   OR_ABI-L2-ADPC-M3_G16_s20173132357191_e20173132359564_c20173140000203.nc
   OR_ABI-L2-ADPC-M3_G16_s20173140012191_e20173140014564_c20173140015205.nc
   ...

Also note that I am also creating a directory that has a 'current' set of
images:

AerosolDetection -> CONUS -> current

I set the number of the images kept in each 'current' directory as a function
of the type of image and/or its update frequency.  I find that this is VERY
useful for ADDE serving of datasets as the number of images is limited AND
the 'current' set can span day boundaries.

re:
> Another question I have, will McIDAS come packaged with any special
> SU/EU tables designed to help visualize GOES-16 products?

I asked the same question of SSEC, and they do not (yet) have specialized
enhancements for the L2 products or ABI images.  I will be working on
creating these AFTER I release v2017.

re:
> For
> example, looking at some of these L2 products like land surface temp
> or cloud top phase, I can plot them and see 0-255 grey-scale values
> but can't help thinking "there's got to be a better way."

I totally agree!

re:
> I've had
> similar thoughts with some of the ABI bands (band 5 is a good
> example), but the L2 products especially could use some help to convey
> their information more intuitively.

Agree, agree, agree :-)

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.