[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20020430: NIDS products
- Subject: 20020430: NIDS products
- Date: Tue, 30 Apr 2002 11:11:55 -0600
Anton,
A program like GPMAP is an example of how the data file is read.
In GPMAP, you will find a call to IM_SIMG ($GEMPAK/source/gemlib/im/imsimg.f).
The IM_ library routines read the header of the file, determine what type of
image it is, and store the header information in common block variables
including data offsets, etc.
Later, on the display side, when the image is called to display, the GN driver
routine you mention is invoked to read the image portion of the file.
So, you have 2 parts of GEMPAK. One that reads all the information that
describes the image, navigation, date/time, source/channel etc.
And the second part handles the display of the data block.
The GEMLIB routines that I wrote for reading the header information are
called through im_nexz.c. These common block variables are located in the
$GEMPAK/include/imgdef.cmn and imgdef.h include files.
Steve Chiswell
Unidata User Support
On Tue, 30 Apr 2002, Anton Kruger wrote:
> Dear Steve
>
> I believe two of our students (Brian Nelson and Michal Kraszewski) contacted
> you last week via the Unidata support webpage. We are still having problems
> reading the data files. I put the students to work, I believe they found
> the relevant ingest routine, namely crnexz.c that you wrote and last
> modified April 2001.
>
> They examined the source code and narrowed it down to the following. The
> global variables imldat and imloff must be set before crnexz is called. It
> is not clear to them what these values should be for the Archive Level III
> data that comes over the LDM feed. They started examining other routines
> such as readimgdata.c, getimgcomint to find where GEMPAK reads the image
> headers and determine file sizes. However, pretty soon they run into
> routines that need X-windows libraries and after that things get
> complicated.
>
> I would appreciate it if you help us with this problem. Basically, we need a
> little more help, and then we can read these files.
>
> One of the students, Michal will call you later today.
>
> Anton Kruger
> Associate Research Engineer
> IIHR (www.iihr.uiowa.edu), The University of Iowa (www.uiowa.edu)
> Email: address@hidden
> Website: http://www.iihr.uiowa.edu/~hml/people/kruger/
> Phone: 319-335-6287
>