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

Tim Jenness tim.jenness at gmail.com
Wed May 2 17:17:13 EDT 2012


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.


>>> (by the way, most of ast
>>> links are slightly corrupted by appended closing parentheses
>>> apparently).
>>
>>
>> I think it depends on the mailer. gmail guesses (correctly) that the
>> trailing parenthesis below is not part of the URL so it does work.
>>
> No, it's something weirder than that. I've sent all variants of urls with
> trailing parentheses and they all work as links in my mail reader.
>

Odd. Just tried them in Apple Mail (assuming we are talking about the
URLs in David's message) and that worked.

-- 
Tim Jenness



More information about the AstroPy mailing list