Epoch / Equinox support in target list

[chazshapiro]

Important for A&G. Are we requiring all ICRS (~J2000) coordinates or doing various conversions ourselves?

[astronomerdave]

@chazshapiro There is an epoch field in the detail pane. Currently, I believe the only place it is used is as follows: any characters are removed (i.e. the "J") and the numeric value (i.e. 2000) is sent to the TCS as the equinox for the coordinates.

[chazshapiro]

Right, so for that usage, it's mislabeled. epoch != equinox

Second, the astrometry solver assumes ICRS and will miss the slit if the user is assuming something else. We could simplify by requiring users to use ICRS.

Here are my notes on this:

NGPS COORDINATE CHOICES

Epoch: Time of observations. Objects with parallax or proper motions will be in slightly different locations for 2 different epochs.

Equinox: Reference time of an (RA, DEC) coordinate system that precesses with the Earth.

ICRS: International Coordinate Reference System – modern, non-precessing (RA, DEC)

GAIA: Epoch=J2016.0 Coordinates = ICRS

• Maybe GAIA should be evolved to time of A&G images (TBC)
• Defines coordinates of A&G solution

Target List: Require ICRS coordinates?

• matches A&G solution, i.e. coordinates mean the same thing (good!)
• No need for an EQUINOX column (N/A for ICRS)
• EPOCH column not currently in use... TBD
• Users would have to provide parallax and proper motions.
• Maybe those are in our catalog, but why are we doing user’s homework

User could provide GAIA ID; only needed for close-by targets. Maybe verify coords as a check

TCS: Requires equinox as argument for slew

• Mismatch with GAIA/TL probably doesn’t matter, A&G will correct the offset (~arcsec)

OTM/ETC: Coordinate inconsistencies are too small to matter

[chazshapiro]

After conversing with Christoffer, we think it's fine to require users to specify all coordinates in ICRS or FK5(J2000.0). These 2 options should be aligned closely enough that the user doesn't need to specify which they are using. Thus, there does not need to be an EPOCH or EQUINOX field in the GUIs or CSV files. TCS commands should always specify equinox J2000.0.

If we find that the A&G is significantly missing the slit due to coordinate definitions (e.g. for very small slit widths) we can revisit this issue. We may only need a binary choice - ICRS or J2000.

As for supporting moving targets, we expect that this will affect only a few users, and those users would know how to evolve their coordinates to the time of observation. If we think many users would benefit from it, the GAIA ID idea above could be implemented. That would require a GAIA ID field in the CSV and the detail pane.