[AstroPy] comments on coordinate system and wcs packages

[Wolfgang Kerzendorf]

Hey guys,

I have thought about this all a little bit and think we need to think in general in astropy how to separate different responsibilites. I think, later on astropy should definitley consist of little building blocks that one can stack together to do something more complex. I'm in favour of keeping these building blocks relatively simple and leave the interconnection up to the user. Obviously, if there's things that people want to do a lot there are helper functions (going from just sticking two building blocks together to pipelines with many blocks; e.g. finding stars in an image and then doing aperture photometry on them). 

1. WCS: A class that maps from n pixel coordinates (unitless)  to m world coordinates (with units like K, m, degree, ...). These world coordinates are independent axes and are not grouped (no link between ra, dec and wavelength). We want to stick to the real world as close as possible (and RA, DEC and wavelength are independent). 

2. A Celestial coordinate, maps between equatorial at different epochs to galactic (or other celestial coordinate systems). 

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(). 

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