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

20040129: 20040121: 20040120: GEMPAK and area files. (fwd)



Mark,

>that is possible.  If 5.6m or 5.7.1 are anticipated in the near future
>then it would make more sense for us to just wait and upgrade the entire
>distribution.

Yes, 5.6.M is being packaged at this time (in between meetings and system 
failures).

Did you try setting the data reange to 0 to 1024 for the GOES-12 2 byte images?

Also, you probably have oversampled data from SSEC if it looks really streatched
in the horizontal. That is just the native resolution of the data.
You would have to resamle the data in the horizontal using McIDAS if you wanted
to decimate the oversampling.

Steve Chiswell



>From: Mark Tucker <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200401291850.i0TIoBp2010499

>
>Steve,
>I sent this message out last week and haven't gotten any response from
>Unidata.  I checked the archives and didn't find it there so I am
>resending it.  Sorry if this is a duplicate.
>
>Mark Tucker
>Meteorology Dept. Systems Administrator
>Lyndon State College
>http://apollo.lsc.vsc.edu
>address@hidden
>(802)-626-6328
>
>---------- Forwarded message ----------
>Date: Thu, 22 Jan 2004 15:49:37 +0000 (UTC)
>From: Mark Tucker <address@hidden>
>Reply-To: address@hidden
>To: Unidata Support <address@hidden>
>Cc: address@hidden
>Subject: Re: 20040121: 20040120: GEMPAK and area files.
>
>> >> file depending on what version of GEMPAK you have.
>> >>
>> >> The entries would look similar to:
>> >> GOES12               VIS           0  30240     78      1      2 GRAY
>> >> GOES12               IR2           0    255     78      2      2 GRAY
>> >> GOES12               IR3           0    255     78      4      2 watvap.t
> bl
>> >> GOES12               IR4           0    255     78      8      2 GRAY
>> >> GOES12               IR5           0    255     78     16      2 GRAY
>> >> GOES12               IR6           0    255     78     32      2 GRAY
>> >> GOES12               IR4           0    255     78    128      2 GRAY
>> >>
>> >> Also, depending on whether or not your files have the expected
>> >> calibration information, you may get an all black image
>> >> (which I have created a fix for in the display drivers).
>> >> If you get that, we'll have to update your distribution.
>> >
>> >After editing the imgtyp.tbl, it looks like we're getting an all black
>> >image now with gpmap.  We're currently running gempak 5.6k.  Is the fix
>> >for the display drivers found in 5.6l or is that a patch I'd have to
>> >apply?
>
>> The modification will be in the 5.6.m/5.7.1 distribution (forthcoming).
>> I would have to create a patch if this were the problem. But first,
>> check below.
>
>I checked the items below (see below) and still get an all black image.
>If it is not too much trouble I would like to try a patch on our build if
>that is possible.  If 5.6m or 5.7.1 are anticipated in the near future
>then it would make more sense for us to just wait and upgrade the entire
>distribution.
>
>> >Also, the only projection that seems to work is "sat".  The SAT
>> >projection gives us a us map and lat/long lines that appear "sloped" to
>> >the north (with the black satellite image).   If any other projection is
>> >specified, it does not appear to load the image (the line at the bottom
>> >describing the date and time of the data does not appear).
>>
>> The SATFIL variable is only used when PROJ=sat. GEMPAK only
>> displays images in their given projection.
>
>Okay, that makes sense.  It is a strange projection but that's SSEC's
>doings I guess.
>
>> >
>> >> The 2 numbers that specify the data range are dependent on
>> >> how the values are found in your files. For example, the
>> >> range of 0 to 30240 for visible is based upon the
>> >> raw values in the data files- but yours may be different.
>> >
>> >How would I determine what the data range values are?
>>
>> Later versions of GEMPAK have a program "arinfo" that
>> can dump out the data range. If you get all black, then
>> it sounds like you want the data range 0 to 255.
>> If you were getting all white, then the data values would be much larger
>> than 255, so the 0 to 1024 or 0 to 30240 would be more likely.
>
>arinfo is very useful.  I wish I'd found that sooner, it's nicer than
>parsing the output from strings.  It reports that the data range is 0 to
>522 but no max or min brightness values:
>
>mark@platypus:~> arinfo -m goes12_1_2003_162_0102.area
>(Area header info has been swapped.)
>Minimum Pixel Value = 0
>Maximum Pixel Value = 522
>Minimum Brightness Value = 0
>Maximum Brightness Value = 0
>
>
>
>-- 
>Mark Tucker
>Meteorology Dept. Systems Administrator
>Lyndon State College
>http://apollo.lsc.vsc.edu
>address@hidden
>(802)-626-6328
>
>From address@hidden Thu Jan 22 08:49:39 2004
>Received: from apollo.lsc.vsc.edu (apollo.lsc.vsc.edu [155.42.21.5])
>       by unidata.ucar.edu (UCAR/Unidata) with ESMTP id i0MFnbp2025754;
>       Thu, 22 Jan 2004 08:49:38 -0700 (MST)
>Organization: UCAR/Unidata
>Keywords: 200401221549.i0MFnbp2025754
>Received: from platypus.lsc.vsc.edu (platypus.lsc.vsc.edu [155.42.21.102])
>       by apollo.lsc.vsc.edu (8.12.10/8.12.9) with ESMTP id i0MFnbaf025865;
>       Thu, 22 Jan 2004 15:49:37 GMT
>Date: Thu, 22 Jan 2004 15:49:37 +0000 (UTC)
>From: Mark Tucker <address@hidden>
>Reply-To: address@hidden
>To: Unidata Support <address@hidden>
>cc: address@hidden
>Subject: Re: 20040121: 20040120: GEMPAK and area files. 
>In-Reply-To: <address@hidden>
>Message-ID: <address@hidden>
>References: <address@hidden>
>MIME-Version: 1.0
>Content-Type: TEXT/PLAIN; charset=US-ASCII
>X-Spam-Status: No, hits=-1.7 required=5.0
>       tests=AWL,IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,REFERENCES,
>             SIGNATURE_SHORT_DENSE,SPAM_PHRASE_01_02,USER_AGENT_PINE
>       version=2.43
>X-Spam-Level: 
>
>> >> file depending on what version of GEMPAK you have.
>> >>
>> >> The entries would look similar to:
>> >> GOES12               VIS           0  30240     78      1      2 GRAY
>> >> GOES12               IR2           0    255     78      2      2 GRAY
>> >> GOES12               IR3           0    255     78      4      2 watvap.t
> bl
>> >> GOES12               IR4           0    255     78      8      2 GRAY
>> >> GOES12               IR5           0    255     78     16      2 GRAY
>> >> GOES12               IR6           0    255     78     32      2 GRAY
>> >> GOES12               IR4           0    255     78    128      2 GRAY
>> >>
>> >> Also, depending on whether or not your files have the expected
>> >> calibration information, you may get an all black image
>> >> (which I have created a fix for in the display drivers).
>> >> If you get that, we'll have to update your distribution.
>> >
>> >After editing the imgtyp.tbl, it looks like we're getting an all black
>> >image now with gpmap.  We're currently running gempak 5.6k.  Is the fix
>> >for the display drivers found in 5.6l or is that a patch I'd have to
>> >apply?
>
>> The modification will be in the 5.6.m/5.7.1 distribution (forthcoming).
>> I would have to create a patch if this were the problem. But first,
>> check below.
>
>I checked the items below (see below) and still get an all black image.
>If it is not too much trouble I would like to try a patch on our build if
>that is possible.  If 5.6m or 5.7.1 are anticipated in the near future
>then it would make more sense for us to just wait and upgrade the entire
>distribution.
>
>> >Also, the only projection that seems to work is "sat".  The SAT
>> >projection gives us a us map and lat/long lines that appear "sloped" to
>> >the north (with the black satellite image).   If any other projection is
>> >specified, it does not appear to load the image (the line at the bottom
>> >describing the date and time of the data does not appear).
>>
>> The SATFIL variable is only used when PROJ=sat. GEMPAK only
>> displays images in their given projection.
>
>Okay, that makes sense.  It is a strange projection but that's SSEC's
>doings I guess.
>
>> >
>> >> The 2 numbers that specify the data range are dependent on
>> >> how the values are found in your files. For example, the
>> >> range of 0 to 30240 for visible is based upon the
>> >> raw values in the data files- but yours may be different.
>> >
>> >How would I determine what the data range values are?
>>
>> Later versions of GEMPAK have a program "arinfo" that
>> can dump out the data range. If you get all black, then
>> it sounds like you want the data range 0 to 255.
>> If you were getting all white, then the data values would be much larger
>> than 255, so the 0 to 1024 or 0 to 30240 would be more likely.
>
>arinfo is very useful.  I wish I'd found that sooner, it's nicer than
>parsing the output from strings.  It reports that the data range is 0 to
>522 but no max or min brightness values:
>
>mark@platypus:~> arinfo -m goes12_1_2003_162_0102.area
>(Area header info has been swapped.)
>Minimum Pixel Value = 0
>Maximum Pixel Value = 522
>Minimum Brightness Value = 0
>Maximum Brightness Value = 0
>
>
>
>-- 
>Mark Tucker
>Meteorology Dept. Systems Administrator
>Lyndon State College
>http://apollo.lsc.vsc.edu
>address@hidden
>(802)-626-6328
>
--
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.