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

Perry Greenfield perry at stsci.edu
Wed May 2 17:35:02 EDT 2012

On May 2, 2012, at 5:17 PM, Tim Jenness wrote:

> On Wed, May 2, 2012 at 2:04 PM, Perry Greenfield <perry at stsci.edu>  
> wrote:
>> On May 2, 2012, at 4:42 PM, Tim Jenness wrote:
>>> On Wed, May 2, 2012 at 1:03 PM, Perry Greenfield <perry at stsci.edu>  
>>> wrote:
>>>> Are these necessarily exclusive approaches?
>>> AST was designed to handle mappings from different coordinate  
>>> systems
>>> from the beginning to handle data pixel coordinates to WCS to  
>>> graphic
>>> coordinates (and vice versa) in a transparent manner.
>>> The examples earlier in this thread are more based around conversion
>>> of a single value from one frame to another and there are many
>>> simplifications that are possible when that is done. A single  
>>> galactic
>>> coordinate to the corresponding RA/Dec coordinate is a well  
>>> understood
>>> conversion that never changes. AST will let you work out the world
>>> coordinates of a particular pixel in your image, or the pixel that
>>> corresponds to a particular WCS, or the position on the graphics
>>> plotting device corresponding to either the data pixel or the WCS
>>> coordinate. The transformation from RA/Dec to Galactic is all  
>>> handled
>>> in a specialist SKY frame and you can actually do the simple
>>> translations by setting attributes in a Sky frame object without
>>> having to understand mappings and pixel coordinates (so easily
>>> wrappable).
>> I'm not sure I understand how this corresponds the two approaches  
>> (both
>> could apply to one coordinate or multiple coordinates I think).
>> Isn't the issue whether frames are disconnected from specific  
>> coordinate
>> values or not? If one designs it so that they are, what keeps one  
>> from
>> making a class that bundles the system with one or more coordinate  
>> values so
>> that it does know how to convert the value(s) to another system. I  
>> don't
>> think one needs to design two parallel systems for that. The bundled
>> representation simply contains an attribute which is a frame along  
>> with an
>> attribute for its coordinates. But I could be missing the whole  
>> point :-)
> In the AST design the SkyFrame understands everything there is to
> understand (within reason) about astronomical coordinates. It know how
> to convert from J2000 to ICRS to Galactic and has attributes of epoch,
> equinox etc.
> http://www.starlink.ac.uk/docs/sun211.htx/node677.html
> Similarly a TimeFrame knows how to convert from different types of
> time internally (TDB, UTC, TAI etc).
> http://www.starlink.ac.uk/docs/sun211.htx/node691.html
> you can use these frames standalone to do internal conversions from
> UTC to TAI or Galactic to RA/Dec.
> AST goes a step further and adds the ability to connect these frames
> together using mappings. A simple mapping would be from a pixel grid
> to a sky coordinate but you can stack mappings and frames together so,
> for example, a pointing correction can be inserted as a ShiftMap
> between the two frames as an additional mapping. You can then stack
> additional frames and mappings together for as much complexity as you
> want. There are many frames and mappings available by default.
Sure. But what keeps you from associating frames with specific  
coordinate values? In that case, the object that holds both knows how  
to convert the values to another frame.


More information about the AstroPy mailing list