[AstroPy] comments on coordinate system and wcs packages

[Marshall Perrin]

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. 

>>> mycoord = myifu.pixel2world(500, 500, 500)
<SpectralCelestialCoord object>
>>> mycoord.ra
Value with unit: 200 deg
>>> mycoord.wavelength
Value with unit: 6562 Angstrom

One can then imagine just casting between coordinates with attributes (internally implemented as a method call wrapped in @property, probably)

>>> mycoord.galactic
(8:04:02, -12:34:56 )

>>> mycoord.freq
Value with unit: 4.56e14 Hz

For spectroscopic data, note that wavelength, frequency, and energy should all be included, and it ought to be possible to specify a rest wavelength in which case the axis can also be cast to velocity, too.


On May 4, 2012, at 5:01 PM, Scott Ransom wrote:
> To kind-of second this emotion, it's important to remember that a lot of 
> other non-O/IR data uses data cubes as well (such as radio/mm/submm) and 
> handling for this kind of thing is crucial for them (CASA for EVLA and 
> ALMA data heavily uses Python and works with data cubes). 

Would you be willing to summarize a bit what the interface in CASA is like? I'll admit that looking at CASA is on my to-do list but I haven't made it there yet...

 - Marshall



> 
> To summarize, a WCS should be a transformation from a pixel coordinate system to another coordinate system and should not treat (in the first instance) some axes special. 
> 
> Wolfgang
> 
> 
> 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
>> 
>> 
>> On 05/04/2012 02:22 PM, James Turner wrote:
>>>> First, addressing AST. There seem to be two separate thoughts on this;
>>>> one is that AST should be adopted as is (made the underlying basis for
>>>> an astropy library) and the second is that it's interface should be
>>>> considered for any library constructed for astropy (but that the AST
>>>> implementation itself need not be adopted).
>>> Well, I think there's a third thought that we should study the AST
>>> design, talk to Tim&  David and heavily borrow any useful concepts :-).
>>> It seems unlikely that the interface would be identical in Python. I
>>> did also have one or two questions myself about why AST does things
>>> certain ways, compared with what I'd had in mind previously.
>>> 
>>> What you say about keeping things like units&  fitting separate
>>> certainly makes sense and indeed we have to solve the problem of
>>> adding the necessary fitting code first.
>>> 
>>> It would be good to sync up on where things stand at some point; I've
>>> had to put this on the back burner for a while and it sounds like in
>>> the meantime you've made a bit of progress and Wolfgang and others
>>> have been thinking about co-ordinate handling in AstroPy. My
>>> assumption was that I'd quickly have to implement something as simple
>>> as possible by myself (or maybe with Nadia) when I get back to it (I
>>> hope in the next couple of months), but if there's already something
>>> to build on, that might be a lot better :-). As I mentioned, I had
>>> this in mind as a possible AstroPy sprint (in addition to Erik's list
>>> of problems to solve).
>>> 
>>> Cheers,
>>> 
>>> James.
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy