
Date: Thu, 29 Mar 2001 20:24:13 +0200
From: Peter Kretschmar <peter.kretschmar@obs.unige.ch>
Subject: GTI handling revisited
To: Hornstrup Allan <allan@dsri.dk>, Oxborrow Carol Anne <oxborrow@dsri.dk>, Huovelin Juhani <Juhani.Huovelin@Helsinki.fi>, Westergaard Niels Jorgen <njw@dsri.dk>, Larsson Stefan <stefan@astro.su.se>, Maisala Sami Petri <Sami.Maisala@astro.Helsinki.fi>
MIME-version: 1.0
Content-transfer-encoding: 7bit
X-Accept-Language: de,fr


  Dear friends,

  after some discussions in the last weeks, ISDC has devised a standardized 
and somewhat simplified scheme for GTI handling. Unfortunately, it means
yet again a change to our documentation and a _slight_ change to the
code of anyone using GTIs.

  As described already in our latest ADD the unified scheme has below the 
SWG an Index of GTIs (xxxx-GNRL-GTI-IDX). These GTI's can be created by
a variety of programs (gti_create only deals with HK); specifically 
foreseen are additional executables to build GTIs from attitude data
(stable/instable periods) and based on data gaps - the relevant code
already mostly exists but mixed with other functionality in OSM.
For offline analysis a user could also add a personal GTI, created 
manually or by some tool.

  The change is that gti_merge shall no longer create a JMXi-MERG-GTI
but just another entry in this table. The entry can be identified
because all GTI tables have a keyword "GTI_NAME" and this would be
set to a specific string ("Analysis" I think, need to find the note).

  So why is ISDC doing this? Well, I only took part via phone, so I
did not get all the discussion, but the main point seems to be that
in this way one can stay in principle flexible and access multiple
different GTIs from one's code, if one so wishes, instead of being
stuck with a merged overall GTI. Personally, I prefer the latter
- at least one stays consistent - but others seem to want more freedom.

  As long as we stay with a single merged GTI, almost nothing changes
from a program development point of view: Instead of passing the string 
"MERG" to the DAL3HK function, we would pass "Analysis" (or whatever the
tag is). All the rest is a problem of DAL3HK that naturally first needs 
to be updated (next week?).

  The implementation of this change is _not_ urgent, so please ignore
this for the **URGENT** V2 Consolidation updates. If everything
goes well, it should be a trivial step in Finalization to adapt to
this - if your code needs adaption at all ...

  Regards,
  Peter

P.S. Naturally I will update the ADD drawings accordingly, you may need
     to do this for your inputs (JMXi-MERG-GTI -> JMXi-GNRL-GTI)
