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

Tim Jenness tim.jenness at gmail.com
Fri May 4 12:07:19 EDT 2012

On Thu, May 3, 2012 at 2:31 PM, Wolfgang Kerzendorf
<wkerzendorf at gmail.com> wrote:
> On 2012-05-03, at 5:17 PM, Tim Jenness wrote:
>> On Thu, May 3, 2012 at 11:53 AM, Wolfgang Kerzendorf
>> <wkerzendorf at gmail.com> wrote:
>>> But AST doesn't handle unit conversion (e.g. from Kelvin to eV) which are
>>> also coordinate transformations, because it has a different focus (namely
>>> astronomical images and now spectra). For now, we have made the
>>> distinctions: time, celestial coordinates, SI units, world coordinate
>>> systems for array based data.
>>> That doesn't mean, we don't want them working together: you give a world
>>> coordinates system a pixel coordinate, it gives back a celestial coordinate
>>> (with units degrees) which I then can easily convert to galactic
>>> coordinates. For example
>>> mycoord = myimage.wcs.pix2world(200,300)
>>> mycoord.units is in degrees
>> What happens if you have a 2d image with 3d coordinates (for example
>> an IFU)? Does mycoord know that it has 3 coordinates and only two of
>> them are relating to the sky wcs?
>> Can mycoord be converted back to a pixel position or is the mapping
>> back to image completely lost?
> mycoord for has exactley the number of coordinates that the wcs gives it. For an IFU that is 3. a world coordinate system (in the general term of the word) has nothing to do with angles or celestial coordinates. it just maps n-> m dimensions. In the IFU case it's mapping from three pixel coordinates to an angle, an angle and a wavelength/frequency.
> It could equally well map onto a temperature, a density and a length (well obviously not for an IFU).

My point is that when you have 2 pixel coordinates returning an ra/dec
and something else you need your interface to be able to handle it so
that it doesn't get confused when you then ask it to convert the
result to galactic+wavelength. It's clearly important for some control
to be provided for formatting the coordinates when you are displaying
them and I also wonder how you query the coords object to determine
the underlying physical representation of the value.

I wrote a perl module on CPAN called Astro::Coords
(https://github.com/timj/perl-Astro-Coords  ) which handles
astronomical coordinate conversions (and supports planets and orbital
elements as subclasses) so I have some experience in the approach of
separating the coordinate from its earlier context. It is clearly a
requirement to be able to convert radec to galactic to azel to
whatever but the isolated coordinate is an endpoint and I think what
AST has demonstrated is that a holistic approach to coordinate systems
and how they are related is an incredibly powerful and useful approach
to the problem.

>>> mytime = time.from_jd(245423423423)
>>> mytime.to_utc -> will give back a datetime object
>>> mycoord = coord.from_equatorial(200, 20)
>>> mycoord.units  (is degrees).
>>> mycoord.to_galactic -> gives back a tuple with galactic coordinates in
>>> degrees
>> can mycoord convert to AZEL? (ie does it retain the observer location
>> and the epoch).
> These questions are relating to things that we have not thought about it as a group. IMHO:
> There's obviously a function that will map it to terrestrial coordinates. I also think there is a function which takes a distance and it gives you back the coordinates in 3D (and then you could ask what's the AZ EL from some other planet).
> But it does not retain it no (it might not have one epoch or observer location as it was observed from multiple telescopes multiple times; most objects are like this).

I think these coordinate objects sound like entries in a catalogue
(which is exactly what I did for Astro::Coords but that has an option
to add a telescope and date). Standalone coordinate objects are
important but not sufficient.

Tim Jenness

More information about the AstroPy mailing list