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

[McIDAS #JGN-249914]: IMGMAKE

Hi Mike,

re:
> I've been leading the GOES-16 development here so I can answer these
> questions for you...

Very good.

re: are you currently stitching together the NOTHER tiles into full scenes?

> Not exactly.  What we do now is all home-brewed python.  At face value
> we read in each tile one at a time in python, take its data and append
> it to an array to be plotted.  So to that end we are not stitching
> together tiles.  That being said...

OK.  Are you doing this every time?  If yes, it sounds a bit inefficient...

re: what software/procedure are you using to create the full scenes?

> One of the other things we tested before going to the method we use
> now was to stitch together tiles using gdal_merge.py.  It's been a
> while, but if memory serves one catch was we first needed to convert
> the netCDF tiles into GeoTIFFs via gdal_translate.  There were another
> one or two catches involving spatial information if I recall
> correctly, and GeoTIFFs weren't what we wanted anyways, so we ended up
> moving on to python.  We also tinkered with stitching the tiles using
> netCDF Operators (NCO), but didn't spend much time on that.

OK.  I personally would stay away from a method that changes the
underlying file storage.

re:
> gdal_merge.py:  http://www.gdal.org/gdal_merge.html
> NCO:  http://nco.sourceforge.net/

Thanks for the links.

re:

> It wouldn't surprise me if others are using the gdal_merge.py method.
> I don't think I have any examples lying around but I could mock
> something up a little later.

GeoTiffs would be useful for GIS systems, but not for McIDAS as GeoTiff
is not one of the supported file formats for image input (it is for
output).

re:
> This is also the first I'm hearing of ldm-alchemy, I might have to
> explore that another time.

Ryan sent a note to ldm-users some time back (can't remember exactly
when)...

re: are you interested in running some tests with the pre-v2017 release and
    providing feedback?

> We would be very excited for this opportunity.

Excellent!

re:
> We've been pretty
> anxious to see how McIDAS-X would work with GOES-16, and are hoping it
> could solve a few problems we're dealing with presently.

OK.

re:
> Please let us know how we can proceed.

Since I have sent you/Paul/COD the note, I have continued to tinker with
my ADDE servers for the images/full scenes that are the result of
Ryan's ldm-alchemy Python package.  Given this, I'd like to put off
making it available to you until next week some time.  BUT, in the
interim, you can access the reconstituted images/scenes from any
ADDE-enabled application (e.g., McIDAS-X/V, IDV, etc.) as follows:

ADDE group     server
--------------+-------------------------------------------------
NPGOESR        lead.unidata.ucar.edu

Remember that in McIDAS one can list the ADDE dataset descriptors
using DSINFO:

<from within a McIDAS-X session for example>

DATALOC ADD NPGOESR lead.unidata.ucar.edu
DSINFO IMAGE NPGOESR

Comments:

- the reconstituted images/full scenes are currently stored in
  daily directories

  This means that the number of images in a dataset will grow
  throughout the day and then reset to zero right at 0Z.

  The implication of this is that accessing the reconstituted
  mesoscale scenes is slow at the end of the day when there
  will be on the order of 1440 images in each dataset.  Access
  the FullDisk and PuertoRico images is reasonably fast since
  they are updated only every 15 minutes.  Access to the 
  CONUS images is slower than the FullDisk and PuertoRico
  images but much faster than the mesoscale ones.

- I have not finished dotting the 'i's and crossing the 't's on
  what is needed to IMGCOPY the images to local ADDE datasets
  in AREA format... that is what I am working on/finishing now

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

  This is a known problem with the developers of the GOES-16
  images being sent in NOAAPort, and I have been assured that
  it will be fixed by the time that GOES-16 goes operational
  (currently scheduled for November).  The problem is NOT being
  caused by the ADDE server!

Please fire up McIDAS-X/V or the IDV and "point" at lead.unidata.ucar.edu
for NPGOESR; try some displays and let me know what you think.

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.