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

[Perry Greenfield]

Are these necessarily exclusive approaches? (by the way, most of ast  
links are slightly corrupted by appended closing parentheses  
apparently).

Perry

On May 2, 2012, at 5:40 AM, David Berry wrote:

> On 2 May 2012 10:06, Erik Tollerud <erik.tollerud at gmail.com> wrote:
>> Hi David,
>>
>> I'm curious about your point of separating the frame/coordinate  
>> system
>> and the coordinates themselves.  Are you saying you think it's  
>> clearer
>> from the *user* perspective, or from the *implementation/developer*
>> perspective? (or both?)
>
> I'm talking about someone developing high-level application code - say
> an application to resample an arbitrary FITS data array so that it is
> aligned with a second arbitrary FITS data array. That sort of level -
> people who need to use  coordinate systems (world, pixel, what ever)
> to achieve some useful higher level functionality, and want their code
> to be generic rather than tied to some specific type of coordinate
> system (images, cubes, spectra, etc).
>
> Separating coordinate system definitions from the axis values (i.e.
> having something like a separate Frame class) allows you to define a
> whole load of useful operations that depend only on the nature of the
> coordinate system, and not on any specific positions within that
> coordinate system. For instance:
>
> 1) Given two Frames, find a transformation between them. For instance,
> if you have a pair of Frames representing different celestial
> coordinate systems, or spectral coorinate systems, or time coordinate
> systems, or any combination, AST has a method
> (http://www.starlink.ac.uk/docs/sun211.htx/node245.html) that will
> return you a Mapping (if possible) that can be used to transform
> position from one Frame to the other. This is
>
> 2) Navigate around a coordinate system. Given that some coordinate
> systems are flat (i.e. pixel coords) and some are spherical (e.g.
> celestial), together with the varying dimensionality (1D spectra, 2D
> images, 3D spectral cubes, etc), produces quite a bit of complication.
> So having Frame methods that can answer questions like "If I start at
> point A in Frame xyz and move towards point B for a distance X, then
> turn through an angle Y and move a further distance Z, where do I end
> up?" is really useful (lots of AST  examples - e.g.
> http://www.starlink.ac.uk/docs/sun211.htx/node340.html)
>
> 3) Attaching a set of coordinate systems to a data cube (i.e. the sort
> of thing the FITS WCS papers cover) - you can define the Frames
> ("pixel", "Focal plane", "sky", etc), and the Mappings between them,
> and then join them all into some higher level object (a "FrameSet" in
> AST - http://www.starlink.ac.uk/docs/sun211.htx/node270.html) that
> allows you to convert positions between any pair of frames.
>
> 4) If you read such a FrameSet from a data set, you can search it for
> coordinate systems with particular properties by using a Frame as a
> sort of wild-card template ("search the FrameSet for any Frames that
> have properties matching this template Frame" -
> http://www.starlink.ac.uk/docs/sun211.htx/node264.html).
>
> 5) The Frame can define things like how to format or parse axis
> values. For instance,  equatorial sky coordinates may be represented
> internally in degrees or radians, but should probably be represented
> as sexagisimal RA and Dec values. But other coordinate systems (e.g.
> galactic sky coords or pixel coords) are usually represented as
> decimal values. A Frame class is a good place to encapsulate all this
> knowledge (e.g.
> http://www.starlink.ac.uk/docs/sun211.htx/node435.html).
>
> 6) Plus of course, a Frame can encapsulate axis labels, axis units,
> coordinate system title, etc, etc.
>
>> While I definitely see the merits of such a separation from the dev
>> side of things (wish I'd seen this sooner, actually!), it seems a bit
>> more confusing from the user side.  I personally favor a user-level
>> interface along the lines of:
>>
>> coord = ICRSCoordinates('1:2:3.4 +56:7:8.9')
>>
>> or possibly
>>
>> coord = Coordinates('1:2:3.4 +56:7:8.9',system='ICRS')
>>
>>
>> and then you just do
>>
>> coord.convert(GalacticCoordinates)
>>
>> or
>>
>> coord.convert('galactic')
>>
>> or even
>>
>> coord.galactic
>>
>>
>> These seem more natural to people I talk to who aren't used to
>> thinking about OO concepts (astropy is intended for both "users" and
>> "developers," although that distinction is ill-defined for
>> astronomers).
>>
>> Such an interface can definitely be mapped onto an underlying system
>> like you suggest for easier development, but here I'm talking about
>> the more "user"-level interface.
>
> I probably agree with you about that. The system I describe gives more
> flexibility, but is certainly more verbose.
>
> David
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy