[AstroPy] API question: Instantiating of time/coord and similar
wkerzendorf at gmail.com
Wed May 2 17:32:55 EDT 2012
So I'm not quite getting what you're telling us? How do you want us to implement coordinates (not WCS) into astropy (the API - not the underlying mechanics)?
P.S.: I should also apologize as this was meant for the astropy-dev list and not for astropy (but I guess everyone who's on dev is on astropy as well).
On 2012-05-02, 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
>> 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.
> Similarly a TimeFrame knows how to convert from different types of
> time internally (TDB, UTC, TAI etc).
> 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
>>> 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
> AstroPy mailing list
> AstroPy at scipy.org
More information about the AstroPy