Closed lmohrmann closed 5 years ago
👍 , thanks!
I would suggest to add a recommendation: if the FOVALIGN
header key isn't present, codes are recommended to assume "ALTAZ"
as default.
IMO this is justified, because all existing non-radially-symmetric background models that I'm aware of have been produced in that orientation (and for past files don't contain the header key).
@kosack or @jknodlseder - Thoughts?
I'd suggest we wait for a day or two for comments here and then merge.
Generally the Github open spec process hasn't been active, and waiting for comments or even concensus from all stakeholders (mainly CTA, plus HESS, VERITAS, MAGIC, Gammapy, ctools) means no progress.
So overall the process would for the coming month just be driven by the few people like @lmohrmann that have use cases / needs to extend the spec - with the understanding that it's all prototyping, and in the future CTAO will make decisions.
So overall the process would for the coming month just be driven by the few people like @lmohrmann that have use cases / needs to extend the spec - with the understanding that it's all prototyping, and in the future CTAO will make decisions.
I agree with this, and with the proposed change. If there is no standard already in other experiments, then go for it.
This PR introduces a new header keyword useful for field-of-view coordinates. Since there are two definitions in use, namely an Alt/Az-aligned system with
DETX = FOV_ALTAZ_LON
DETY = FOV_ALTAZ_LAT
and a RA/Dec-aligned system withDETX = FOV_RADEC_LON
DETY = FOV_RADEC_LAT
, the new header keyword can be used to specify which definition was used in the construction of a 3D background model.Note that this PR only proposed to add this keyword for the background IRF, not the EVENTS file (since it's unclear whether field-of-view coordinates should be listed there at all).