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

[McIDAS #MOR-277707]: Remapping GOES-17 to Area

Hi Mike,

re:
> I'm working on visualizing some of the non-op GOES-17 data that's coming
> over NOAAPort, and I'm running into an issue using IMGREMAP.  When I try
> the remap command it appears to execute well, but when I IMGDISP the area
> file I receive an "Units requested are not available for this image"
> error.  I can display the imagery if I don't remap, which makes me think
> something about the remap or area file is off.

I ran a simple test of IMGREMAPping a Full Disk channel 13 image into MERCator
projection centered over Miami:

IMGREMAP NPGOESS/FDC13 MYDATA/IMAGES.3400 STA=KMIA PRO=MERC SIZE=1000 1000 RES=2

and then displayed it with no problems:

ERASE F;EU REST;IMGDISP MYDATA/IMAGES.3400 STA=KMIA;MAP;MAP LALO INT=5 5

I must say that I am using my as yet unreleased v2018 distribution, however.

re:
> I'll give some examples of everything below, but I've been doing this with
> GOES-16 data and that's worked without issue.  This is the first time I've
> seen an error like this, so I was hoping you could shed some light on
> what's happening or what I might be doing wrong.

It might well or something lacking in v2017.

re:
> This is all taking place on a Ubuntu 18.04.1 server off to the side of our
> main operation, with McIDAS v2017d (recently upgraded from 2016, not a
> totally fresh install if that matters).

Hmm... the Unidata McIDAS installation creates a different hierarchy
for each major release (e.g., 2015, 2015, 2016, 2017), so there shouldn't
be a problem with mixing of source code between versions.  If the ~mcidas/bin
directory is the same, then newly built executables will overwrite old
ones during installation.

re:
> Example:
> IMGREMAP NPGOESSL/CONUSC14 GOES17.14 PRO=LAMB 5 28 98.5 SIZE=ALL
> (the remap doesn't show any error)
> IMGDISP GOES17.14
> IMGDISP: Units requested are not available for this image
> IMGDISP: done
> IMGDISP failed, RC=2

Hmm...  I ran what I feel is essentially the same command and did not
run into any problem:

IMGREMAP NPGOESS/CONUSC14 MYDATA/IMAGES.3401 PRO=LAMB 5 28 98.5 SIZE=ALL
***********************************************
*                  WARNING                    *
* The entire source image will be used to     *
* create the destination image. If the source *
* image is located on a remote server, the    *
* total number of bytes transfered will be:   *
*                  3.75 MB                    *
***********************************************
Beginning Image Data transfer, bytes= 3751220
IMGREMAP: transformations complete ... begin data move
Transferring AREA data outbound, bytes= 37163768
IMGREMAP: Done...

SF 12;ERASE F;EU REST;IMGDISP MYDATA/IMAGES.3401 MAG=-4
Erased image frame(s) 12-12
Erased graphic frame(s) 12-12
ERASE: Done
EU: Restoring default enhancement to frame(s)= 12
EU: Done
Beginning Image Data transfer, bytes= 1410928
IMGDISP: loaded frame  12
IMGDISP: done

IMGLIST MYDATA/IMAGES.3401 FORM=ALL
Image file directory listing for:MYDATA/IMAGES
 Pos Satellite/         Date       Time      Center      Res (km)   Image_Size
     sensor                                 Lat  Lon    Lat   Lon
 --- -------------  ------------  --------  ---- ----  ----- ----- ------------
3401  G-17 IMG       2 OCT 18275  22:11:21    36   95
   Band: 14   11.2 um IR Imagery,SST,clouds,rainfall    0.96  0.96  4895 x 7592
     proj:    0 created: 2018275 221615  memo: GOES-17 ConUS Sector [ABIN]
     type:VISR     cal type:BRIT
     offsets:  data=     768 navigation=  256 calibration=    0 auxiliary=    0
     doc length:   0   cal length:   0   lev length:   0 PREFIX=   0
     valcod:          0 zcor:  0 avg-smp: N
     start yyddd: 2018275  start time:221121  start scan:    0
     lcor:16322  ecor:  6516  bytes per pixel: 1  ss:188
     Resolution Factors (base=1):   Line=    1.0   Element=    1.0
IMGLIST: done

Comment:

- NPGOESS is the group name for the NOAAPort GOES-17 images we are
  receiving as tiles through NOAAPort (NOTHER feed) and restitching
  into full scenes using Ryan's ldm-alchemy Python script

- NPGOESS is available on two of the ADDE server instances that we
  operate:

  atm.ucar.edu
  lead.unidata.ucar.edu

  If you decide to access the NPGOESS images from us, please use atm.ucar.edu
  instead of lead.unidata.ucar.edu.  Lead is already very busy, and atm is
  essentially idling.

re:
> By comparison, the same set of commands work fine with GOES-16 imagery.
> 
> In case it helps, here's the output of IMGLIST:
> 
> IMGLIST GOES17.14 FORM=ALL
> Image file directory listing for:GOES17
>  Pos Satellite/         Date       Time      Center      Res (km) Image_Size
>      sensor                                 Lat  Lon    Lat   Lon
> --- -------------  ------------  --------  ---- ----  ----- ----- ------------
> 14  G-17 IMG       2 OCT 18275  19:11:21    36   95
>   Band: 14   11.2 um IR Imagery,SST,clouds,rainfall    0.96  0.96  4895 x 7592
>     proj:    0 created: 2018275 214006  memo: GOES-17 ConUS Sector [ABIN]
>     type:VISR     cal type:BRIT
>     offsets:  data=     768 navigation=  256 calibration=    0 auxiliary= 0
>     doc length:   0   cal length:   0   lev length:   0 PREFIX=   0
>     valcod:          0 zcor:  0 avg-smp: N
>     start yyddd: 2018275  start time:191121  start scan:    0
>     lcor:16322  ecor:  6516  bytes per pixel: 1  ss:188
>     Resolution Factors (base=1):   Line=    1.0   Element=    1.0
> 
> And again for comparison, here's the same for an area file with GOES-16 data:
> 
> IMGLIST GOES16.14 FORM=ALL
> Image file directory listing for:GOES16
>  Pos Satellite/         Date       Time      Center      Res (km) Image_Size
>      sensor                                 Lat  Lon    Lat   Lon
> --- -------------  ------------  --------  ---- ----  ----- ----- ------------
> 14  G-16 IMG       2 OCT 18275  18:57:19    39  102
>   Band: 14   11.2 um IR Imagery,SST,clouds,rainfall    0.94  0.94  5392 x 8340
>     proj:    0 created: 2018275 214321  memo: GOES-16 ConUS Sector [ABIN]
>     type:VISR     cal type:BRIT
>     offsets:  data=     768 navigation=  256 calibration=    0 auxiliary= 0
>     doc length:   0   cal length:   0   lev length:   0 PREFIX=   0
>     valcod:          0 zcor:  0 avg-smp: N
>     start yyddd: 2018275  start time:185719  start scan:    0
>     lcor:15738  ecor:  5504  bytes per pixel: 1  ss:186
>     Resolution Factors (base=1):   Line=    1.0   Element=    1.0
> 
> Thank you for any insight you can provide.

The only thing I can think of is that there is something in v2018 that is
lacking in v2017x.  In order to test this theory, I have put a v2018
distribution out there for you to grab by FTP:

machine:   ftp.unidata.ucar.edu
user:      anonymous
pass:      address@hidden
directory: pub/mcidas/2018
files:     mcidasx2018.tar.gz, mcunpack

Please let me know when you have grabbed these files so I can remove them
from FTP!

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: MOR-277707
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.