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