[McIDAS #JGN-249914]: IMGMAKE

Hi Mike,

re: COD processing of GOES-16 image tiles sent in the NOAAPort-derived NOTHER 
feed

> Short version is we read in the data once, then take all the actions
> we need to take in python afterwards.  So we're only reading in each
> tile once.  Our goal is to visualize each data set once then move on,
> we don't store the tiles after we've visualized them.

OK, thanks for the nice explanation.

re:
> But we do have some concerns regarding efficiency, one of the reasons
> why we're so interested to see how McIDAS will work for us.

OK.  Since you are only visualizing an image once, the ADDE servers I
wrote will be very fast.

re: I personally would stay away from a method that changes the
    underlying file storage

> As would we, which is why we moved away from those ideas.  But as you
> stated, GeoTIFFs do work well for GIS applications, which is partly
> why I think others are doing things this way.

Yup, I would bet that was why that approach was developed.

re: Ryan sent a note to ldm-users some time back

> Good to know, I'll do some digging.

I'd check the ldm-alchemy part of the Unidata section of GitHub.

re: ADDE-served reconstituted images are available right now

> I just fired up IDV and have data!

Excellent.

re:
> We have the latest McIDAS-X from Unidata, which IIRC is based off SSEC
> 2016.1, which should handle the 16 ABI bands.

Yup.

re:
> So if our version can
> read from that ADDE this is a great place to start.

It can.  I routinely display the NPGOESR images hosted on lead.unidata.ucar.edu
at home from both my Unidata McIDAS-X v2016 installation on my Ubuntu 14.04 LTS
installation on my Odroid U3 single board computer (sweet!) and from Unidata
McIDAS-X v2017 from within the CentOS x86_64 VMware Player VM on my Windows
7 laptop (this is my development environment).

re:
> Otherwise, I
> won't be able to invest much time until next week anyways so the
> timing works out, no worries.

Sounds good.

re;
> Eventually we'd like to point to a local dataset since we get
> everything over NOAAPort.  From what I'm beginning to understand, when
> that time comes the better solution would involve ldm-alchemy as
> opposed to retaining the data in tiles until visualized, is that
> correct?

Correct.

re: VIS channels (bands 1-6, inclusive) for all coverages have a problem
    where the pixels that should be the brightest are mapped to zero

> Oh, we're aware.  Last I heard from some at SSEC was this would be
> addressed sometime in July, but that was a couple of months ago
> already.  By any chance have you heard anything more definitive, or
> just before it goes operational?

Well, I take all of what I hear with a _bag_ of salt mainly since time
frames I have heard in the past have proven to be more fantasy than
reality :-)  With that in mind, I _heard_ from a NOAA contact that the
fix was supposed to be implemented THIS WEEK.  We'll see :-)

re:
> Thanks again!

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