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

[Perry Greenfield]

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.

Perry