CameraGeometry should store pixel coordinates as SkyCoord

[kosack]

I would like to store the camera coordinates inside CameraGeometry as a SkyCoord (not really sky, but that's the base class for astropy coordinates, even if confusingly named), but as of right now, this is difficult because when talking about a CameraGeometry, we do not necessarily have the focal length of the telescope in which the camera is installed.

Therefore, I would like to have CameraFrame be a base frame that does not need any parameters (it's just pixel pos in meters, relative to the center of the camera). Then to transform to an angular system where the pixels are positions on the sky (e.g. the TelescopeSystem), I would then add information about the focal length only. This system should be the same as CameraSystem, but angular coordinates, still centered on the center of the telescope's FOV.

Finally, I would later go to a AltAz or nominal by adding information on the pointing position of the telescope, etc.

@ParsonsRD is there a reason why it is not done this way? Right now I need to have the focal length to specify a CameraSystem coordinate, but I don't have that info, and it shouldn't be needed.

[kosack]

I guess, to me it makes sense like this:

 CameraFrame ---[telescope optics]---> TelescopeFrame ---[pointing]---> NominalFrame

[kosack]

This would then allow us to store the frame type in the CameraGeometry class (without loading a telescope optics description), and support the various frames described in #255

[ParsonsRD]

Hi, sorry was on vacation for the last week. I think thats fine and shouldn't cause any serious problems.

[maxnoe]

I recently implented a working set of Coordinate Transformation for FACT here:
https://github.com/fact-project/pyfact/blob/master/fact/coordinates/camera_frame.py

I learned quite a lot about how astropy frames are supposed to work and what members they need to have to make transformation work painlessly.

I started working on implementing these in ctapipe, but right now I cannot give a timeframe when I will open a PR for this.

In the mean time, i'd like to know if there are definitions of the camera coordinate system and telescope coordinate system somewhere.
This would be very helpful for writing tests and the actual implementation.

[kosack]

I think @tino-michael is debugging that right now for his reconstruction, and found for example the extra 90 deg rotation that we are missing to go from the sim_telarray coord sys to the sky, etc. He's not using astropy coordinates yet, but once he has them finalized, they should be translated into them.

[kosack]

see #580

[labsaha]

@maxnoe By definitions of the camera coordinate system and telescope coordinate system, you mean the frame of references for camera and telescope in which you have to provide FACT camera and telescope coordinates information to do the analysis using ctapipe, right?

@kosack is that the final ctapipe coordinate will be sim_telarray coordinate? or the sky one?

[maxnoe]

@maxnoe By definitions of the camera coordinate system and telescope coordinate system, you mean the frame of references for camera and telescope in which you have to provide FACT camera and telescope coordinates information to do the analysis using ctapipe, right?

No I mean stuff like: CameraCoordinates are defined as x pointing right and y pointing up, when one looks onto the camera plane from the mirror.

Or anything similiar. The definitions of what x and y should mean.

Is there somthing lik a CTA Document describing these coordinate frames?

[labsaha]

I see. I don't know if any such CTA document exits. Others might have some more information on that. I see quite some discussion on coordinate systems in #255.

[kosack]

The standards for coordinate systems don't exist (and indeed each camera is doing things differently), so right now we only support the sim_telarray coordinate system, which is admittedly strange, and I couldn't even really find a reference for it (coordinate definitions are not mentioned in the sim_telarray manual - https://www.mpi-hd.mpg.de/hfm/~bernlohr/sim_telarray/Documentation/sim_hessarray.pdf). Eventually, we can standardize this better, and in fact the project office has been informed that this is a problem.

[kosack]

see also #580

[ParsonsRD]

Hi, agreed @kosack no standards or requirements exist for this. The systems as they are, are a mish -mash between the HESS system, plus some other stuff I thought we might need. I agree this code definitely needs seriously refactoring but should we not try to fix the requirements (or at least get started on them) before we launch into a lot of work about this?

@AMWMitchell, from the PO side of thinks what do you think we need to do about fixing the requirements? Do you know if there is any existing group working on the coordinates standards?

Also, tagging @GernotMaier, what do you think?

[AMWMitchell]

Yes, the PO is aware of the need for common pointing / co-ordinate definitions asap, and Gino Tosti agreed to start a document on this, but as yet I haven't seen any drafts and was considering starting one myself (with the FACT doc started by @maxnoe as input/reference as well as sorting out the mix of HESS / sim_telarray). Gino has ALMA/ASTRI experience, so between us (incl. those with VERITAS experience) we should have most variants covered.
Not sure which requirements you're thinking about - the only one relevant here would be to follow the applicable standards for co-ordinate definitions (TBD).

[ParsonsRD]

Hi @AMWMitchell yeah requirements was a nomenclature fail on my part, agreed the only requirement should be follow the standards :-).

I just think it's probably worthwhile discussing the use cases for the coordinate frames to define what we actually need before launching into anything.

[tino-michael]

I just think it's probably worthwhile discussing the use cases for the coordinate frames to define what we actually need before launching into anything.

Do you want to start a google doc or something to "brain-storm"?

[maxnoe]

This is basically implemented with attaching frame to CameraGeometry and adding transform_to