Improve field-of-view coordinate transformations #2009
Conversation
|
I deleted the old code and made the change you suggested, @cdeil. |
|
@lmohrmann - Thanks! I think There's of course the question if we should implement FOV frame using astropy.coordinates directly. But this PR is a big step forward towards simpler code, so I'm merging this in now without further discussion. Once we have a first caller / use of this functionality or two, we can improve further - suggestions or PRs welcome any time. |
| # Create a frame that is centered on the pointing position | ||
| center = SkyCoord(lon_pnt, lat_pnt) | ||
| fov_frame = SkyOffsetFrame(origin=center) | ||
|
|
There was a problem hiding this comment.
Wouldn't it be simpler to pass a SkyCoord for the pointing direction directly?
If I understand correctly this will work only if the pointing coordinate is in the right AltAz system, right?
There was a problem hiding this comment.
Yes, this might be simpler, but I did not do it because I wasn't sure what would happen when the user passes a SkyCoord that is defined in another system. You're right that currently, the transformation works for the conversion between AltAz and an AltAz-aligned field-of-view system, and not e.g. between RaDec and a RaDec-aligned field-of-view system. The pointing therefore needs to be specified in AltAz coordinates, yes.
My understanding was that Gammapy will work with AltAz-aligned field-of-view systems only, and so I avoided the complication to also support a RaDec-aligned system.
It might be a good idea to make it more clear in the comments that the field-of-view system is always assumed to be AltAz-aligned.
| fov_frame = SkyOffsetFrame(origin=center) | ||
|
|
||
| # Define coordinate to be transformed. | ||
| target_sky = SkyCoord(lon, lat) |
There was a problem hiding this comment.
Same here. Having a SkyCoord seems more efficient and less error prone regarding systems used.
There was a problem hiding this comment.
For the same reason as above, I decided against passing this as a SkyCoord.
|
|
||
| # Switch sign of longitude angle since this axis is | ||
| # reversed in our definition of the FoV-system | ||
| return -target_fov.lon, target_fov.lat |
There was a problem hiding this comment.
I don't know what is the definition used by CTA here, but couldn't it be simpler to keep lon and lat and simply revert the HESS background IRF to be in the same system?
There was a problem hiding this comment.
I'm using the same transformation/definition of field-of-view system as is being used in the HESS software. That is, if you convert into field-of-view coordinates with these functions, you should get the same values as are listed in the exported EVENTS FITS file as FOV_ALTAZ_LON and FOV_ALTAZ_LAT.
|
|
||
| # Create a frame that is centered on the pointing position | ||
| center = SkyCoord(lon_pnt, lat_pnt) | ||
| fov_frame = SkyOffsetFrame(origin=center) |
There was a problem hiding this comment.
I would directly pass the pointing SkyCoord.
|
To follow up on the suggestions by @registerrier to use SkyCoord in the API: @registerrier - I was also thinking about suggesting to use @kosack - do you already use FOV coordinates in ctapipe? I think in CTA there is no definition for this yet, right? What do you think of the definitions here? @lmohrmann - is the code here in line with the definitions here? Maybe you could send a follow-up PR to add a link to the definition in the docstring, and if you want to introduce SkyCoord as input / output, do that? Would suggest to wait for @kosack to comment though to avoid changing back and forth. |
Yes, I think it is. At least it agrees with the transformations as used in the HESS exporter, and my understanding was that that code is in line with the specs. |
Following discussion in #1987, this PR improves the field-of-view coordinate transformations by using astropy utilities, namely the
SkyOffsetFrame.I've kept the old versions as comments, since the new ones are apparently much slower (in a very quick test I did). If performance ever becomes an issue (which is not so unlikely), we may want to consider to go back to the old transformations.