What to do if OGIP conventions and the FITS standard are in conflict?

[maxnoe]

I just noticed a conflict between the OGIP conventions and the FITS standard, which is explicitly commented on in the FITS time paper, which definitions were taken over for the FITS standard version 4.0.

Specifically, in this instance, it is the keyword and its possible values specifying the time reference location.

In OGIP, it is TIMEREF with value 'LOCAL', which is given in GADF (but, pointing incorrectly to the FITS standard) and in the FITS time paper and the current standard it is TREFPOS with multiple possible values and 'TOPOCENTER' being the equivalent to 'LOCAL'.

While reworking the time definitions is also needed with respect to the current standard, I think we should take a decision on how to resolve conflicts between FITS standard and OGIP convention.

My personal preference would be to follow the FITS standard.

From the FITS time paper:

The OGIP convention uses the keyword TIMEREF and only allows values ‘LOCAL’ (i.e., Topocenter), ‘GEOCENTRIC’, ‘HELIOCENTRIC’, ‘SOLARSYSTEM’ (i.e., Barycenter); the convention contains also the somewhat peculiar keyword TASSIGN. We will not adopt these keywords in order to avoid confusion on allowed values and meaning. Instead, we adopt the keywords TREFPOS and TRPOS n

FITS Time paper: https://www.aanda.org/articles/aa/pdf/2015/02/aa24653-14.pdf FITS Standard Section 9.2.3 (TREFPOS): https://fits.gsfc.nasa.gov/standard40/fits_standard40aa-le.pdf OGIP definition: https://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/docs/rates/ogip_93_003/ogip_93_003.html

[jknodlseder]

Maybe check what other instruments do as this at the end corresponds most to what users (and software) expects.

Le 24 févr. 2022 à 10:53, Maximilian Nöthe @.***> a écrit :

I just noticed a conflict between the OGIP conventions and the FITS standard, which is explicitly commented on in the FITS time paper, which definitions were taken over for the FITS standard version 4.0.

Specifically, in this instance, it is the keyword and its possible values specifying the time reference location.

In OGIP, it is TIMEREF with value 'LOCAL', which is given in GADF (but, pointing incorrectly to the FITS standard) and in the FITS time paper and the current standard it is TREFPOS with multiple possible values and 'TOPOCENTER' being the equivalent to 'LOCAL'.

While reworking the time definitions is also needed with respect to the current standard, I think we should take a decision on how to resolve conflicts between FITS standard and OGIP convention.

My personal preference would be to follow the FITS standard.

— Reply to this email directly, view it on GitHub https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/issues/191, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAW2QV3Z4MA5QKEUDE7JWVTU4X5ZFANCNFSM5PG4CI5Q. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you are subscribed to this thread.

[maxnoe]

I don't think we should let the legacy behavior of other instruments or software take precedence over the current version of the FITS standard for new iterations of the specification.

FERMI for example uses TIMEREF and also the now deprecated RADECSYS. But FERMI software mostly precedes the current FITS standard (4.0 from August 2018) and probably even the FITS time paper (2015).

I think we should take the decision to give the FITS standard precedence in these kinds of cases, so we are in agreement with the current version and not perpetuate legacy behavior.

EDIT: FERMI references the FITS standard Version 2.0 from 2001 in their comment section of photon files freshly downloaded from their server for observation dates in 2021.

[PaulKuin]

Historically, FITS was developed to interchange data on tape, mostly from the Radio and space community (from IUE to CGRO). The adopted convention is to make all changes such that they do not break the older FITS versions. As a result, there were extensions to the FITS from both OGIP and CDS which differed. It is allowed to differ, for example, the Swift headers specify time in a way that is discouraged nowadays, but in 2004 was OK. So I would not worry too much about the above. As long as you don't break the backwards compatibility it is OK.