Define some keywords for the primary hdu

[maxnoe]

I think now, we do not make any definitions for the primary hdu.

Maybe we should also include at least some header keywords here so a file can be immediately recognized as a file produced according to theses standards here.

[lmohrmann]

Sounds like a good idea. Can you make a proposal?

[kosack]

Might consider just using the keywords that OFWG already recommends:

The OFWG recommends that the following set of keywords be used to for such purposes in each extension:

• HDUCLASS - a character string giving a general identifier of data format used
• HDUDOC - a character string giving the document (preferably published) that describes the format/classification used
• HDUVERS - a character string giving the specific version of the document specified by HDUDOC.
• HDUCLASn - an indexed set of character strings giving the classification of data in the extension

Current allowed values here: https://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/docs/ofwg_recomm/hduclas.html

You'd have to invent a HDUCLASS I guess.

[maxnoe]

These are used for the actual HDUs already.

So I'd suggest HDUCLASS = OGADF_PRIMARY?

[TarekHC]

These are used for the actual HDUs already.

So I'd suggest HDUCLASS = OGADF_PRIMARY?

I agree with this.

Maybe we should also include at least some header keywords here so a file can be immediately recognized as a file produced according to theses standards here.

Perhaps we could add a list of the different tables within the DL3 file? Perhaps that is too complex?

[maxnoe]

Perhaps that is too complex?

Not really, I think.

Is there a something standard for this? If not, something like this:

HDU0 = OGADF_PRIMARY
HDU1 = EVENTS
HDU2 = RESPONSE/EFF_AREA/POINT-LIKE/AEFF_2D
HDU3 = RESPONSE/EDISP/POINT-LIKE/EDISP_2D

This could be optional but recommended in the standard, since you can always get this information thorugh looking at the individual hdus's

[jknodlseder]

Here is the standard

https://heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/docs/ofwg_recomm/hduclas.html

Note sure what the "_PRIMARY" stands for. "OGADF" for HDUCLASS seems sufficient.

Le 23 mars 2020 à 16:46, Maximilian Nöthe [email protected] a écrit :

Perhaps that is too complex?

Not really, I think.

Is there a something standard for this? If not, something like this:

HDU0 = OGADF_PRIMARY HDU1 = EVENTS HDU2 = RESPONSE/EFF_AREA/POINT-LIKE/AEFF_2D HDU3 = RESPONSE/EDISP/POINT-LIKE/EDISP_2D This could be optional but recommended in the standard, since you can always get this information thorugh looking at the individual hdus's

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/issues/141#issuecomment-602684939, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAW2QV4B23WSS3BO3OTOB3LRI574ZANCNFSM4LQOA4SQ.

[maxnoe]

@jknodlseder this is about the first primary hdu, that is not used in this standard for anything right now. HDUCLASS is recommended to be GADF in the current standard, so the primary hdu (the image hdu the FITS standard requires as first hdu) could have:

HDUCLASS = "GADF"
HDUDOC   = "https://..."
HDUVERS  = "v0.3"
HDUCLAS1 = "PRIMARY"

[adonath]

@MaxNoe your latest proposal seems reasonable to me as well. It's probably the minimal compliant information that can be put...

[TarekHC]

Going through the format used within the CREF# keywords in Fermi-LAT IRFs (also containing arrays), the way they store them is:

Instead of @MaxNoe proposal:

HDU2 = RESPONSE/EFF_AREA/POINT-LIKE/AEFF_2D HDU3 = RESPONSE/EDISP/POINT-LIKE/EDISP_2D

It would be:

HDU2 = (RESPONSE,EFF_AREA,POINT-LIKE,AEFF_2D)
HDU3 = (RESPONSE,EDISP,POINT-LIKE,EDISP_2D)

Maybe the initial "(" helps identifying that an array is coming? Anyway, if we can be as consistent as possible with other approaches used in the past, better.

[maxnoe]

That's actually not standard conform, so we should not use it.

Enclosed in quotes as a string, it would be.

[jknodlseder]

Using HDUCLASS for an empty extension does not make any sense. HDUCLASS is meant to identify content.

Le 24 mars 2020 à 16:19, Maximilian Nöthe [email protected] a écrit :

@jknodlseder https://github.com/jknodlseder this is about the first primary hdu, that is not used in this standard for anything right now. HDUCLASS is recommended to be GADF in the current standard, so the primary hdu (the image hdu the FITS standard requires as first hdu) could have:

HDUCLASS = "GADF" HDUDOC = "https://..." HDUVERS = "v0.3" HDUCLAS1 = "PRIMARY" — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/open-gamma-ray-astro/gamma-astro-data-formats/issues/141#issuecomment-603300982, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAW2QV5FRXZPAMPR64KULN3RJDFRBANCNFSM4LQOA4SQ.

[kosack]

I agree with Jurgen. You don't need an HDUCLASS in the primary. Couldn't you just identify the file type by which HDUs are present? There's also the hierarchical grouping standard to group a set of HDUs together, but I think it also leaves the primary HDU blank. https://fits.gsfc.nasa.gov/registry/grouping.html