...
(Chiang) I think it is probably better to draw the line after adding Galactic coordinates. I am often asked by people who are browsing the data using fv, ds9, ROOT, etc. why we don't have Galactic coordinates in the FT1 file, especially since in gamma-ray astronomy it is incredibly useful to know the location of a source relative to the Milkway.
Revised proposed resolution: Omit SKYX/Y columns. Let's include Galactic coordinates, for the reason that Jim gives. We do not have, and are not planning to provide, a coordinate conversion utility for event files, and Galactic coordinates certainly would be convenient to have available.
13. Live time
(Digel) Way back when (until early 2003), the events file was defined to include a column called 'Deadtime' which was to be the 'Deadtime accumulated since the start of the mission.' It was removed, partially because Masa pointed out that information that relates specifically to the LAT belong in the FT2 file. Also, live time turns out to be more convenient to work with.
...
(Chiang) If we keep CONVERSION_LAYER as a column, then I would go even further and include in the numbering scheme the tracker layers that do not have radiators. This would help guard against any ambiguity regarding where the conversion occurred since we would be using the same layer ids that are used in the reconstruction code. However, ultimately, we may choose to omit the CONVERSION_LAYER information in favor of an EVENT_CLASS variable.
Proposed resolution: Omit CONVERSION_LAYER (see below).
19. EVENT_CLASS
(Chiang) There would be a one-to-one correspondence between IRF "subtypes" and possible EVENT_CLASS values. Presently, there are only two possible event classes, Front and Back, indicating in which set of radiators the conversion occurred. As the instrument calibration and IRF implementation evolve, there will likely be more classes than just two. An advantage of using EVENT_CLASS over something like CONVERSION_LAYER is that such a scheme helps ensure that the user will only be able to make cuts that are supported by our IRF implementations.
Proposed resolution: Include EVENT_CLASS as Jim describes in place of CONVERSION_LAYER and as a way to encode other classes that we come up with. After discussion with Jim, I think we should also have a column called something like CONVERSION that would indicate, e.g., by value 1,2, or 3 whether the event is FRONT, BACK, or CAL-ONLY. This would be in addition to EVENT_CLASS, although until we have other ways defined to discriminate other kinds of response functions it will have the same value.