[AstroPy] comments on coordinate system and wcs packages

[Perry Greenfield]

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  
available.

Perry

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[0], mycoord[1]).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  
> unit.
>>
>>
>> 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[0], x[1] #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.
>>>
>>> Vicki