[AstroPy] API question: Instantiating of time/coord and similar
d.berry at jach.hawaii.edu
Thu May 3 05:18:56 EDT 2012
Hi All, a lot of stuff was said over-night! I'll just give some brief
responses to one or two points:
1) Wolfgang mentioned the distinction between "WCS" and "coordinates".
I can't see much of a distinction myself. Both tackle the problem
"given positions in one coordinate system, how do I convert them into
another coordinate system". After all, the pixel coordinate system is
just another coordinate system, like galactic, equatorial or whatever.
2) Perry made the point that if you separate the coordinate system
description from the actual axis values, then there is nothing to stop
you creating a higher level class that combines a Frame description
with the axis values. Absolutely so. This is exactly what AST does.
The AST "Region" class is a class that encapsulates a Frame together
with a set of axis values to define a region within a coordinate
system. There are sub-classes of Region to define circles, boxes, etc,
and also compound regions formed by the intersection or union of other
regions. And there is a subclass of Region that defines a simple list
of isolated points within the Frame. And you can transform Regions
using a Mapping into another specified coordinate system.
3) Tim followed up on my own point that AST keeps the Frames and axis
values separate. This may seem to contradict what I said above, but it
doesn't really. Regions are used mainly for masking (although they can
also be plotted). So you define a Region and can then ask "does this
random position I have fall inside or outside the Region". But for
the more common problem, where a piece of code just wants to transform
positions from one coordinate system to another, it's more efficient
for the code itself to retain copies of the Frames, and then just
processes the axis values themselves using whatever Mappings etc are
required. An AST Mapping is just a description of a numerical
transformation with no information about what the input or output
values represent - this extra semantic information is embodied in the
Frame class that is retained by the calling application.
4) Several people made the point about astropy wanting to avoid C
libraries. That sounds reasonable. My reason for mentioning AST was
not necessarily to try to persuade anyone to use it directly, but more
to advertise the model of coordinate handling it is based upon. It has
been shown over many years to provide a very flexible, easy to use API
for building coordinate handling apps (once you've got your head round
the concepts). And importantly it is extensible - If you add new
classes of coordinate system, or new types of Mapping or Regions or
whatever to the library, your application code should "just work"
without any major changes.
More information about the AstroPy