[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[McIDAS #JGN-249914]: IMGMAKE
- Subject: [McIDAS #JGN-249914]: IMGMAKE
- Date: Tue, 12 Dec 2017 13:31:51 -0700
Hi Mike,
re:
> First thing's first, I've been doing quite a bit with GOES16 and
> McIDAS since the release and almost everything has gone very very
> well. I'm still very happy with how everything is working.
Hmm... the 'almost' in the sentence doesn't bode well :-(
re:
> However, there is one problem I seem to be having, IMGCOPY. Some
> example commands are below, but when I try to IMGCOPY a data set and
> then plot the copy, all I see is white.
Wow!
re:
> For context, I'm doing this because I want to remap one data set (ABI
> band 02) based on another data set's projection (ABI band 01) using
> IMGREMAP PRO=DEST.
OK.
As an aside comment: the only time the projection would be different
is if you are remapping a Full Disk image over a CONUS image since the
last images sent in NOAAPort still had different projections for the
Full Disk, CONUS and Puerto Rico sectors.
re:
> I need to do this in order to combine data sets of
> different spatial resolutions. IMGREMAP itself doesn't have any
> problems, and if my first data set is copied via IMGREMAP then the
> second one with PRO=DEST works just fine. But IMGCOPY does not seem
> to copy either the data, nor the data's projection information, so the
> subsequent IMGREMAP yields no data as well.
Yikes, this is VERY bad indeed!
I just ran an IMGCOPY test on locally stored, NOAAPort-delivered, ldm-alchemy
stitched together CONUS band 1 and IMGDISP displayed it, and my values are
all black, not white. The navigation, however, is correct.
re:
> Simple example:
> IMGCOPY NPGOESR/CONUSC01 GOESR.2 SIZE=ALL
> IMGDISP GOESR.2 LAT=37 90 MAG=-4
Another aside comment:
Following your example, I IMGCOPYed an RTGOESR CONUSC01 image to a
local AREA dataset (MYDATA/IMAGES) and found that the copy would fail
with a totally unexpected error when SIZE=ALL was specified:
IMGCOPY RTGOESR/CONUSC01 MYDATA/IMAGES.3001 SIZE=ALL
IMGCOPY: No images satisfy the selection criteria
IMGCOPY: done
IMGCOPY failed, RC=1
I found, however, that the IMGCOPY will work if one specifies SIZE=SAME,
and the IMGDISP of the IMGCOPYed image was identical to the original.
The failure on SIZE=ALL appears to be a bug in the SSEC ABIN AGET server,
but I'll need to do some more investigating before I report it.
Back to the problem at hand...
re:
> White image, though oddly enough the information on the frame label
> (e.g. date, time, satellite) are accurate on the copy.
And, for me, at least, the navigation is also correct.
re:
> Following the above commands with these:
>
> IMGREMAP NPGOESR/CONUSC02 GOESR.2 PRO=DEST
> IMGDISP GOESR.2 LAT=37 90 MAG=-4
>
> Also a white image.
In my test, the result was a black display, not a white one. Equally
incorrect, of course...
re:
> While the textual output from these commands yields no errors, IMGCOPY
> doesn't appear to be doing its job. If that's the case, I figured
> you'd want to know.
Yes, absolutely. I'm debugging now...
re:
> Hope all is well,
It was _until_ I got your email :-(
I'll let you know what I come up with.
Thanks for reporting this!
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: Open
===================
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.