[McIDAS #AMH-341410]: 2 questions

Hi Ioan,

re:
> the created: time value is surprising indeed.:)) I hope SSEC can clarify
> that.

After poking through code, I was reminded that the image creation time is
its start time.  The creation time in the example I sent was the time that
IMGCOPY created the AREA file in my local MYDATA/IMAGES dataset, and this
_is_ correct.

There are a couple of other words in an AREA file header that are described
as being (word reference is 1-based):

    W46.  Actual image start year and Julian day, yyyddd
    W47.  Actual image start time, hhmmss; in milliseconds for POES data

Since SSEC is setting the nominal time of the image:

     W4.  YYYDDD:   Nominal Year and Julian day of the data
     W5.  HHMMSS:   Nominal Time of the data

to the value of 'time_coverage_start', so including the actual start time
again would be a (little) bit redundant.

Also, there is no formalism for storing the image scan end time in the
AREA file header.

re: why is the scanning mode important to you?

> Well, long story short...GOES satellites have been giving us some trouble
> because, from our perspective, they are/were unstable when it comes to their
> scanning schedules. Of course this might be because we don't really have
> any hurricanes in Europe and we are used to very stable scanning (MSG).

Interesting.  I have never assumed that the the start of a scan would
be fixed to a particular minute much less second.  I am a bit surprised
that MSG's scanning schedule is so fixed.

re:
> Internally we use NetCDF to store data and we split the time dimension into
> 2 dimensions (date and time) (DFB/DAY day from beginning) and SLOT/TIME
> (just a whole number representing the number or position of the  image in
> the range of total number of images a specific instrument would acquire
> during during a day)

OK.

re:
> We do this for a number of reasons, most important  being the
> simplification of the computations we do using the satellite data (solar
> radiation estimation).

OK.

re:
> While the day/dfb business is straightforward, the slot is not.
> Whenever the current or past GOES instrument changed its scan mode or
> regime to RSO or SRSO, some images are shifted (SH coverage is taken at 05
> instead of 07 for example) and the process we call slot mapping was storing
> suddenly CONUS images instead of SH ones:))
> This resulted  in temporal holes in our  radiation database  for South
> America and complaining customers:))

Interesting.

re:
> I however, fixed all these issues when I started with Solargis so now we
> kind of have everything under control.
> For current GOES these mapping involve using the coverage of the data so we
> don't get tricked by the change of the scan regime.
> 
> For GOES16 I designed some functions which take as input the nominal time
> of an image and the scan regime and return the corresponding slot number
> for that given image in the day.

OK, I understand.

re:
> This functions will work even if I do not know the scan regime because I
> hard-coded the scan regimes into the code and even if GOES 16 will move to
> M6 scan regime I will store only let's say 96 images in our archive and
> ignore the others by using the M3 scan regime.

I think I understand...

re:
> It is very important however for us to know the exact time when a pixel was
> scanned to model the solar radiation at a given location precisely. this is
> why i need the end of scan time, to compute the scan time for every line in
> the image

Question:

- why can't you simply use the start scan time for your computation?

  This is the type of thing I have done in the past when helping a user...

re:
> In the implementation i use (I did some stats on CLASS data) :
> channel_no, scan time duration (s)
> 1 636.647916667
> 2 636.647916667
> 3 636.648958333
> 4 636.644791667
> 5 636.648958333
> 6 637.211458333
> 7 637.775
> 8 636.645833333
> 9 637.204166667
> 10 637.771875
> 11 636.645833333
> 12 637.204166667
> 13 637.769791667
> 14 636.645833333
> 15 637.216666667
> 16 637.784375
> 
> 
> 
> 
> I am attaching my ABI slot mapping module  in case you want to understand
> exactly how it works

OK, got it.  I am still curious why using the scan time beginning is not
as useful as using the scan time end.  Again, the McIDAS AREA format does
not have a formalism for storing scan time end.

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: AMH-341410
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.