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

[David Berry]

On 3 May 2012 16:39, Wolfgang Kerzendorf <wkerzendorf at gmail.com> wrote:
> Hi all,
>
> This topic has expanded a lot;-)
>
> So adressing point 1: Yes, you're technically right. That both of these things do coordinate transformations. But there are many coordinate transformations in astronomy and in astropy we don't have a one-size fits-all mentality about them (in my sense for good reason). For example, switching between different units, doppler-shifting spectra , etc... all are technically coordinate transformations, but we treat them differently and not through one coordinate transformer.

Is there a reason for that?

> I propose to keep a world coordinate system (transforming from an array-index coordinate system to an other coordinate system (e.g. RA, DEC)) separate from astronomical 2d coordinates (Equatorial with different epochs, Galactic with different epochs). The 'world coordinate system'-package will be much broader in the sense that it will do arbitrary transforms from array-coordinate systems to anything else (in simulations data the axes might be lengths, or temperatures, ....).

If the user wants the value of an image at given galactic coords, but
the image is calibrated in (RA,Dec) then why not combined both
transformations (pixel->(RA,DEC) and (RA,Dec)->(galactic)) into one? I
don't see how pixel coords are fundamentally or practically any
different to any other coords - you do the same sort of things with
them all.

David


> I think some of the functionality (like masking) you describe is based on array data and we're already implementing this in our base array class NDData.
>
> adressing point 4: I think we want to avoid including legacy code. Don't get me wrong we want to learn from the code and use the algorithms, but what astropy strifes to do (and Erik hinted at that) is a uniform UI that provides many algorithms provided in some of these codes (like AST). In addition, we want astropy to be a glue between packages (passing data from AST which provides functionality A to pyephem which provides functionality B).
>
> For this current discussion, I would like to see API examples in pseudo python code. I think this makes it easier for us to visualize the different options.
>
> Cheers
>   Wolfgang
> On 2012-05-03, at 5:18 AM, David Berry wrote:
>
>> Hi All,  a lot of stuff was said over-night! I'll just give some brief
>> responses to one or two points:
>>
>> 1) Wolfgang mentioned the distinction between "WCS" and "coordinates".
>> I can't see much of a distinction myself. Both tackle the problem
>> "given positions in one coordinate system, how do I convert them into
>> another coordinate system".  After all, the pixel coordinate system is
>> just another coordinate system, like galactic, equatorial or whatever.
>>
>> 2) Perry made the point that if you separate the coordinate system
>> description from the actual axis values, then there is nothing to stop
>> you creating a higher level class that combines a Frame description
>> with the axis values. Absolutely so. This is exactly what AST does.
>> The AST "Region" class is a class that encapsulates a Frame together
>> with a set of axis values to define a region within a coordinate
>> system. There are sub-classes of Region to define circles, boxes, etc,
>> and also compound regions formed by the intersection or union of other
>> regions. And there is a subclass of Region that defines a simple list
>> of isolated points within the Frame. And you can transform Regions
>> using a Mapping into another specified coordinate system.
>>
>> 3) Tim followed up on my own point that AST keeps the Frames and axis
>> values separate. This may seem to contradict what I said above, but it
>> doesn't really. Regions are used mainly for masking (although they can
>> also be plotted). So you define a Region and can then ask "does this
>> random position I have fall inside or outside the Region".  But for
>> the more common problem, where a piece of code just wants to transform
>> positions from one coordinate system to another, it's more efficient
>> for the code itself to retain copies of the Frames, and then just
>> processes the axis values themselves using whatever Mappings etc are
>> required. An AST Mapping is just a description of a numerical
>> transformation with no information about what the input or output
>> values represent - this extra semantic information is embodied in the
>> Frame class that is retained by the calling application.
>>
>> 4) Several people made the point about astropy wanting to avoid C
>> libraries. That sounds reasonable. My reason for mentioning AST was
>> not necessarily to try to persuade anyone to use it directly, but more
>> to advertise the model of coordinate handling it is based upon. It has
>> been shown over many years to provide a very flexible, easy to use API
>> for building coordinate handling apps (once you've got your head round
>> the concepts). And importantly it is extensible - If you add new
>> classes of coordinate system, or new types of Mapping or Regions or
>> whatever to the library, your application code should "just work"
>> without any major changes.
>>
>> David
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>