[McIDAS #OPE-279047]: New Sandwich Command

Hi Mike,

re:
> Starting off with some good news,

I always like good news :-)

re:
> I was able to get SANDWICH working this
> morning.  Attaching a sample; same domain as one of our regional sectors to
> make it easy to compare this to the base bands used.  I must say, I'm a fan.

Yes, it does create a visually pleasing display.

re:
> Side-note: You can ignore my other email about getting errors with
> SANDWICH.  I was rushing things, and the errors had to do with not having
> the same projection / resolution between the vis and IR bands.  I got my
> remaps sorted out this morning and that took care of those errors.

OK, noted.

re:
> Also, do you happen to know how / where IR gets cut off?  I'm guessing it's
> a certain brightness temperature value.

For GOES-R, the warm end for IR is now 400K.  I don't think that the cool
end changed much, but I will need to check to be sure.

re:
> If SANDWICH gets a documentation
> page eventually it'd be nice to see this described there too, just a small
> request.

The only way that SSEC is likely to document SANDWICH fully is if they
promote it from XRD to CORE.  I have no idea if this is in their plans.

re: including some more XRD in the Unidata McIDAS-X release

> Neat.  These will be good additions to have for sure.

So far, I have only added more map databases.  I will continue to
look at the XRD routines to see which might be of real use.  The
problem with adding routines is it incurs additional work to make
sure that they build/install/work on the set of platforms in use
in the Unidata McIDAS-X community.  All that SSEC does with XRD
routines is make sure that they compile!

re: SANDWICH.ET

> I checked again on my own just before your last email hit my inbox, and got
> the ET file then.  Just copying it to the data directory was enough, and it
> looks like that's all the updated makefile would have done as well.

The install actions in 'makefile' make hard links in needed directories
(e.g., ~mcidas/bin, ~mcidas/data, etc.), not copies.

re:
> Hopefully there will be actual documentation on the SANDWICH command at
> some point, but it is noteworthy that SANDWICH.ET is used even if you never
> specify it yourself; it's used by the SANDWICH command.  Now everything
> will still work if that doesn't exist (it will give you an error, really
> just a warning), but then the end result just looks like you copied a B/W
> IR image on top of a visible image.

OK, and I wouldn't hold my breath waiting for a fully documented SANDWICH
command.

re: several changes in the Unidata v2019a release

> Good to know.  I'll try to keep an eye out for v2019a.

I can say that the incremental changes I have made to the ABIN servers
have so far resulted in them running faster.  They were already fast
to begin with, so the end-user might not notice a big change.

re:
> One last thing, I was also playing with the ABITRUCOL script and got that
> working too.

Me too, and I really liked what I saw.

re:
> I'm looking forward to better documentation here as well,
> though I did find some by reading the contents of that file.

You can list the REMark lines from McBASI scripts using HELP:

HELP ABITRUCOL

re:
> It actually
> looks like it's doing the same thing I'm doing already, just with different
> numbers for the IMGOPER commands.

That's good to know.  I believe that Rick Kohrs, who is THE master of cool
McIDAS displays, developed ABITRUCOL.MCB.

re:
> I might use those to make some
> comparisons with what I'm doing now, but there are some cautions with using
> that script as-is:  First, unless you specify otherwise it pulls from
> remote data sources;

Yes, the default ADDE dataset is EAST, and I did create EAST datasets
to parallel/mimic/be the same as RTGOESR on our publicly facing ADDE
servers.  This is noted in the HELP for ABITRUCOL:

HELP ABITRUCOL
ABITRUCOL -- Displays a corrected ABI true-color RGB image
     ABITRUCOL dataset frame 'day/time keywords' 'positioning keywords'
Parameters:
     dataset  | GOES ABI image for input Red, Green, and
                Blue bands (def=EAST/FD.-1)
     frame    | destination frame to display the output
                color image (def=current frame)
     'day/time keywords' | DAY=, TIME= (no default)
     'positioning keywords' | LAT=, MAG=, STA=, LIN=
        see RGBDISP for more information (def='STA= MIA')
        'MAG= -24' will center a full disk image on a 480x640 frame
Examples:
  ABITRUCOL X X 'TIME=12 13' 'MAG=-2 STA=STL'
    displays the RGB image magnified over St Louis, MO between 12 and 13 UTC
  ABITRUCOL LOCAL/AREA.1 5 X 'MAG=-4 STA=MSN'
    displays the RGB image of an AREA file on frame 5 magnified over Madison, WI
Remarks:
  ABITRUCOL is based on the CIMSS Natural True Color method:
  
http://cimss.ssec.wisc.edu/goes/OCLOFactSheetPDFs/ABIQuickGuide_CIMSSRGB_v2.pdf

  ABITRUCOL is a McBASI script that executes McIDAS commands to copy
  bands 1, 2, and 3 from an ABI image, manipulate them into the same
  resolution, create an approximated green band with IMGOPER, and then
  use the RGBDISP command to display the ABI natural true-color RGB image.

  While creating the true-color RGB image, the script runs IMGCOPY,
  IMGREMAP and IMGOPER commands that overwrite Area files 4501-4540
  (AREA4501, AREA4502, ..., AREA4540). To change the Area file numbers
  or make any other changes (e.g., change the default dataset or station),
  copy the file ABITRUCOL.MCB from ~mcidas/data/ to your
  $HOME/mcidas/data/ directory and edit the file.
  ----------

re:
> I'd need to get it working with local data instead.

Just specify the local dataset to use.  I did this yesterday in my
development environment and everything worked like a charm.

re:
> Second, it uses a range of AREA files that I was already reserving for
> other projects (4501-4540), so that led to some interesting confusion for a
> bit.

Ah yes, name clash is always a problem when (forced into) using the
AREAnnnn naming convention.  The BIG problem is that output (WRITE)
ADDE datasets of type AREA are hard coded to use the AREAnnnn naming
convention.  I have always disliked this!

re:
> I also wasn't paying close enough attention to how some of the
> parameters need to be grouped together with quotes.  But once I got all
> that sorted out, it does work and gives some nice looking imagery.  Wanted
> to give an update on this as well since I was asking about it.

Thanks, I am always interested in what you are doing with McIDAS!

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