[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Datastream #IUA-546454]: Re: 20190604: major upcoming change to IDD NIMAGE datastream

Hi Pete,

re:
> I had been ingesting and playing with this test NIMAGE datastream back in 
> late April,
> and was able to ingest/store/plot the data. The data is still coming in, so I 
> can turn
> my saving back on and test things if you need/want.

Testing is always good and feedback that derives from the testing is most 
welcome.

re:
> A few things I noticed.
> 
> 1) There aren't really any good GEMPAK color tables for GOES16/17 data. At 
> least not in
> the 7.5.1-1 linux distro that I'm running.
> 
> The ones in there seem to be aimed at the old 8 bit pre-GOES16 images, rather 
> than the
> high resolution GOES16+ data. We should figure out and create some better 
> ones (or steal
> from AWIPS or somewhere?)

I will make sure that Michael sees this comment, but it might be good to open a
GEMPAK inquiry so that he is sure to notice and respond (address@hidden).

re:
> 2) If you store the data in a deep path that ends up something like
> 
> /weather/data/gemdata/sat/GOES16/CloudAndMoistureImagery/Mesoscale-2/Channel01/OR_ABI-L2-CMIPM2-M6C01_G17_s20191551933570_e20191551933570_c20191551933570.nc
> 
> you will run into problems with GEMPAK - there is apparently a 108 character 
> limit on a
> SATFIL name:
> 
> Creating process: xw for queue 65896449
> [IM -1]  Image file 
> /weather//data/gemdata/sat/GOES16/CloudAndMoistureImagery/Mesoscale-2/Channel01/OR_ABI-L2-CMIPM2-M6C01_G17_s
> 
> Not a show stopper, just something to be aware of, especially since the file 
> names are
> so long to begin with.

This is also a GEMPAK-specific issue, so I would include it in the GEMPAK
inquiry.  It would also be good to send tips like this to the address@hidden
list as an FYI for the gembuds.

The only thing I care about is the actual file names (not pathnames) as those
follow the mission-standard naming format detailed in the PUG.

re:
> 3) Does it make sense to continue wide IDD distribution of GOES16/17 imagery 
> in the
> three different formats that will be out there?
> 
> SATELLITE - GRB radiances and other non-ABI products
> NOTHER - tiled CMIP products
> NIMAGE - reconstituted CMIP and other level2 products, etc
> HDS - some tiles GOES16/17 level 2 products - not sure we can separate those 
> from the other gridded data on HDS - maybe collateral damage?

GEMPAK and AWIPS can each only handle the Level 2 format that will be in the
NIMAGE feed.  Other packages like McIDAS, McIDAS-V, IDV and MetPy can handle
either.  Also, some users will want the GRB imagery as those are in radiances,
not counts.

I agree that distribution of NOTHER and the L2 products in HDS is redundant.

re:
> Seems like we are wasting bandwidth by moving around lots of the same data 
> twice, at
> least between NOTHER and NIMAGE..

End-users can REQUEST exactly what they want/need.  The multi-format burden is
on the data relays.  Unfortunately, I don't know any way around that.  But, I
must reiterate that it is not really the same data that is being moved twice -
the GRB data is L1b and the NIMAGE data will be L2.  I suspect that the
great majority of end-users will want to get the NIMAGE products as they are
smaller and a bit easier to use.

re:
> Anyways, my thoughts..

And they are much appreciated!!

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: IUA-546454
Department: Support Datastream
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.