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

20021210: dates stored in McIDAS AREA files and NOAAPORT GINI images

>From: "Paul L. Sirvatka" <address@hidden>
>Organization: COD
>Keywords: 200212110353.gBB3rS419799 McIDAS AREA ADDE LDM IDD

Hi Paul,

I got both of your messages, so I know the first item you reported is not
necessarily a problem with the v2002 McIDAS distribution.

There are two reasons for my reply:

1) the way that dates are stored in McIDAS area files is, in fact,
   a problem for the _long_ haul.  Dates are stored as seconds since
   1970, so they will stop being unique after sometime in the year
   2032.  The good news for both of us is that we shouldn't have to
   worry about this :-)

2) at one point you were thinking of ingesting the NIMAGE (NOAAPORT
   GINI images) feed on a machine at COD.  What is your current thinking
   on this?  I ask because I see that COD machines are still the
   greatest users of GINI imagery on the cooperating community ADDE
   server, adde.ucar.edu:     8.05D+09  climate.cod.edu     2.22D+09  dyn253-03.cod.edu

   These numbers are bytes accessed since the last time the log file
   was rotated, which was last Friday night.

Continued ADDE access to the images on adde.ucar.edu is not a problem,
but it would be more efficient if you were ingesting and accessing
them locally.  Also, as we talked about before, if you were ingesting
the data, you could turn around and offer access to it to other sites
through ADDE server(s) on your own machine.


>I think something changes with the new version of McIDas that we installed
>a while back. we just found the problem now/
>the errors were as follows from a script that did the work
>"Transferring AREA data
>outbound, bytes= 22560848
>IMGREMAP: Done...
>03:31:00 is time
>02345 is date
>Notice here is the string we have for the time and date...
>/home/mcidas/bin/imgcha.k: Nominal start date is out of range  -2139062144
>     Directory Block Changes
>Changed Band Sequence from: 8 16 24 32  to: 27
>Changed Image Day from: -2139062144  to: 2002345
>Changed Sensor Source from: -2139062144  to: 7
>Changed Image Time from: -2139062144  to: 33100
>aparently there is something different about how it reads the time and
>/home/mcidas/bin/imgcha.k: Invalid Data Block Position
>/home/mcidas/bin/imgcha.k: Byte offset must be greater than or equal to
>I have a script that looks like this in the key area
># This is the command to set date and time
>system ("/home/mcidas/bin/imgcha.k SAT.4467 SS=7 BAND=27 DAY=$date
>system ("/home/mcidas/bin/imgcha.k SAT.4468 SS=7 BAND=27 DAY=$date
># print "system (\"imgcha.k SAT.4467 SS=7 BAND=27 DAY=$date
>where time and date strings are as listed above. 
>It looks like the way the time and date are stored is not in Julian day
>format and time xx:xx:xx format but in values in the system keytable. W
>Any help you can throw my way?
>>From address@hidden Wed Dec 11 07:19:31 2002
>in my haste to write you last night I forgot to llok at the image that I
>was mapping from...
>it had this as a time
>44 JAN 62144
>Eveidently in the next 60 years, we will have much longer months...:-)
>Now i  need to figure out how that date happened on my area file.

>From address@hidden Wed Dec 11 12:10:54 2002
>Subject: Re: 20021210: dates stored in McIDAS AREA files and NOAAPORT GINI 

re: date in AREA files not valid after 2032

>If I need to worry about it, I'll bug someone else by then! :-)

>I do not know why that got messed up...I will have to be more careful in
>looking at things nif it were to happen again.

re: setting up NIMAGE ingest at COD

>This term I have been taking perl, writing a ton of scripts to process
>images for radar. Take a look at

>That is what we have been doing. We even have a script to select floater
>sites as needed. But I am happy to say, I finished!!! This morning as a
>metter of fact! We had been using WXP to do the images and just stayed
>with that for a bit more simplicity.

>My next project is moving and setting up the reception of satellite images
>via gini. I may be asking questions for help if it comes to that. So that
>is my plan...I would like to get it done asap...maybe by Christmas if at
>all possible. Once that works, the hits your server will take (or any ones
>elses) will be diminished! Those uses will be McIDAS.

>Anyway...I hope you are doing well. Skiing much? Have a great Christmas!


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.