[AstroPy] API question: Instantiating of time/coord and similar

[David Berry]

On 2 May 2012 10:06, Erik Tollerud <erik.tollerud at gmail.com> wrote:
> Hi David,
>
> I'm curious about your point of separating the frame/coordinate system
> and the coordinates themselves.  Are you saying you think it's clearer
> from the *user* perspective, or from the *implementation/developer*
> perspective? (or both?)

I'm talking about someone developing high-level application code - say
an application to resample an arbitrary FITS data array so that it is
aligned with a second arbitrary FITS data array. That sort of level -
people who need to use  coordinate systems (world, pixel, what ever)
to achieve some useful higher level functionality, and want their code
to be generic rather than tied to some specific type of coordinate
system (images, cubes, spectra, etc).

Separating coordinate system definitions from the axis values (i.e.
having something like a separate Frame class) allows you to define a
whole load of useful operations that depend only on the nature of the
coordinate system, and not on any specific positions within that
coordinate system. For instance:

1) Given two Frames, find a transformation between them. For instance,
if you have a pair of Frames representing different celestial
coordinate systems, or spectral coorinate systems, or time coordinate
systems, or any combination, AST has a method
(http://www.starlink.ac.uk/docs/sun211.htx/node245.html) that will
return you a Mapping (if possible) that can be used to transform
position from one Frame to the other. This is

2) Navigate around a coordinate system. Given that some coordinate
systems are flat (i.e. pixel coords) and some are spherical (e.g.
celestial), together with the varying dimensionality (1D spectra, 2D
images, 3D spectral cubes, etc), produces quite a bit of complication.
So having Frame methods that can answer questions like "If I start at
point A in Frame xyz and move towards point B for a distance X, then
turn through an angle Y and move a further distance Z, where do I end
up?" is really useful (lots of AST  examples - e.g.
http://www.starlink.ac.uk/docs/sun211.htx/node340.html)

3) Attaching a set of coordinate systems to a data cube (i.e. the sort
of thing the FITS WCS papers cover) - you can define the Frames
("pixel", "Focal plane", "sky", etc), and the Mappings between them,
and then join them all into some higher level object (a "FrameSet" in
AST - http://www.starlink.ac.uk/docs/sun211.htx/node270.html) that
allows you to convert positions between any pair of frames.

4) If you read such a FrameSet from a data set, you can search it for
coordinate systems with particular properties by using a Frame as a
sort of wild-card template ("search the FrameSet for any Frames that
have properties matching this template Frame" -
http://www.starlink.ac.uk/docs/sun211.htx/node264.html).

5) The Frame can define things like how to format or parse axis
values. For instance,  equatorial sky coordinates may be represented
internally in degrees or radians, but should probably be represented
as sexagisimal RA and Dec values. But other coordinate systems (e.g.
galactic sky coords or pixel coords) are usually represented as
decimal values. A Frame class is a good place to encapsulate all this
knowledge (e.g.
http://www.starlink.ac.uk/docs/sun211.htx/node435.html).

6) Plus of course, a Frame can encapsulate axis labels, axis units,
coordinate system title, etc, etc.

> While I definitely see the merits of such a separation from the dev
> side of things (wish I'd seen this sooner, actually!), it seems a bit
> more confusing from the user side.  I personally favor a user-level
> interface along the lines of:
>
> coord = ICRSCoordinates('1:2:3.4 +56:7:8.9')
>
> or possibly
>
> coord = Coordinates('1:2:3.4 +56:7:8.9',system='ICRS')
>
>
> and then you just do
>
> coord.convert(GalacticCoordinates)
>
> or
>
> coord.convert('galactic')
>
> or even
>
> coord.galactic
>
>
> These seem more natural to people I talk to who aren't used to
> thinking about OO concepts (astropy is intended for both "users" and
> "developers," although that distinction is ill-defined for
> astronomers).
>
> Such an interface can definitely be mapped onto an underlying system
> like you suggest for easier development, but here I'm talking about
> the more "user"-level interface.

I probably agree with you about that. The system I describe gives more
flexibility, but is certainly more verbose.

David