[AstroPy] comments on coordinate system and wcs packages
perry at stsci.edu
Sat May 5 11:25:57 EDT 2012
Remember this is also not an either/or situation.
I've taken to heart that there are users that want access to very
vanilla arrays for whatever reason (they may be good reasons or bad
reasons, but if you want them to use it, you have to keep that in
mind). It could be that they have their own fancy objects and whatever
object you present is inconsistent with theirs. Sure, we'd like
everyone to use a common set objects, but there are cases where the
common scheme won't fit certain uses. So long as it is simple (and
efficient) to get at the results as regular numpy arrays, that
shouldn't preclude a more complex representation that lets one access
different coordinates by name.
Furthermore, don't lose sight of the fact that labeled axes are
definitely planned as one of the numpy enhancements (the idea and
prototype implementation has been around a while now). It would be
wise to avoid a design that can't easily take advantage of that. That
really would seem to be the natural solution once the capability is
On May 4, 2012, at 7:08 PM, Marshall Perrin wrote:
> On May 4, 2012, at 3:58 PM, Wolfgang Kerzendorf wrote:
>> In that sense transforming from an ifu cube (which has a coordinate
>> system in equatorial). is simply mycoord = myifu.pixel2world(500,
>> 500, 500) -> (200. -60 6562) (the wcs has the units, so we can look
>> them up).
>> mygal = coord.from_equatorial(mycoord, mycoord).to_galactic().
> I'm with Vicki on this: better to return complex objects rather than
> just tuples. For instance in this case, keep in mind that there's no
> universal convention in IFU data for whether the wavelength axis is
> first or last. So in this example, is it (ra, dec, wave) or (wave,
> ra, dec), or what? Much better to return instead some kind of
> Coordinate object with attributes, each of which has some associated
>> On 2012-05-04, at 2:32 PM, Victoria G. Laidler wrote:
>>> I would just like to chime in that I think the IFU use case
>>> is going to become increasingly important, and I would like
>>> to see an IFU example worked out in the
>>> documentation/rationale for whatever approaches are considered.
>>> I'd also like to call out the question of whether a
>>> mapping/transform produces a tuple of floats, or a more
>>> complex object that knows its contents and units, and has
>>> fields that can be accessed to get the floats. The latter is
>>> the approach we took in Astrolib Coords, and I think it is
>>> more versatile, not *too* much more verbose, and *much* more
>>> readable to write, say,
>>> x = eq_to_galactic(y)
>>> x.ra, x.dec
>>> than to write
>>> x = eq_to_galactic(y)
>>> x, x #danger will robinson
>>> ra, dec = x #ok, but why not do the former?
>>> This circles back to the original question of user
>>> interfaces, and touches on Perry's point about units.
More information about the AstroPy