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

20000913: scripting of imgcopy.k for portion of image that is blank (cont.)

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: 20000913: scripting of imgcopy.k for portion of image that is blank (cont.)
  • Date: Thu, 14 Sep 2000 07:25:59 -0600
  • >from: David Harper <address@hidden>
  • >keywords: 200009132058.e8DKwlb00832 McIDAS-X IMGCOPY RTGINI netCDF
  • >organization: NCAR/RAP
Tom,

Sorry, I forgot to specifiy that the files that are having trouble are
goes east images.  I am running on goeswest at the other site.  Does
mcidas actually know which is which?

I am pulling all of this through the noaaport satellite feed, so they
are all gini files.  I am running on images that I manually pulled in
from the receive machine so there is no update, nor is there an old
image available.  I am looking at visual, 10.7micron and 7 micron
images.  When I looked at the visual representation I noticed the
latitude interval is compressed far below 1km/pixel.  It may have been
a coincidence that the numbers looked that way on the resolution 8
image (7 micron).

Dave

>From address@hidden Thu Sep 14 08:18:45 2000

OK, I must be confusing myself somehow.  I just looked at White Sands
and saw the same thing.  I guess the positions run from the lower
right?  When I ran through the data far enough I started to see the
data I expected.  Is the image 500 from the center or 500 total?
Something is obviously escaping me, and I am not sure what it is yet.
I'm beginning to think it is not mcidas as I originally assumed.

White Sands worked well, but Dugway seems to be too far West, by half
the image.

email I was going to send before I checked White sands:
---------------------------------------------

I was trying to get Dugway Utah running (thinking it might be a
goeseast issue) and I found the same problem.  I ask for:

imgcopy.k RTGINI/GW1KVIS NCDF/GINI.1 LATLON=40 113.5 SIZE=500 500

But I get:
 latitude =
  41.83825, 41.83965, 41.84104, 41.84243, 41.84383, 41.84523, 41.84662,
    41.848, 41.84939, 41.85078, 41.85218, 41.85356, 41.85495, 41.85634,
    41.85772, 41.8591, 41.86049, 41.86187, 41.86325, 41.86464, 41.86602,
-skipping lats (there are 500 in the visual):
    42.43253, 42.43356, 42.43459, 42.43562, 42.43665, 42.43767, 42.43869,
    42.43972, 42.44074, 42.44177,
-next row:
  41.82965, 41.83104,

The odd part is that White Sands seems to work perfectly.  I'm going to
take a closer look, but I am pretty confident of that based on my
lat/lon projection software.  -Our display software requires that the
image is a lat/lon grid, so I had to "project" the netCDF file I get
from Mcidas.  To forstall the question, the data I am looking at comes
right out of mcidas prior to my code working on it.

-Dave

Unidata Support wrote:


>From address@hidden Thu Sep 14 09:12:07 2000
>Subject: Re: 20000913: scripting of imgcopy.k for portion of image that is 
>blank

Sorry it was my fault afterall.  I didn't realize that the skew was as
prominant as it is.  That's why the first several rows so far from the
center latitude.  The difference in the interval is based on the amount
of skew (as basic trig would say).  Turns out I did not properly
compensate for the opposite skew angle on the east coast.

Thanks for all the time,
Dave