From martin.raue at desy.de  Tue May  1 05:41:30 2012
From: martin.raue at desy.de (Martin Raue)
Date: Tue, 1 May 2012 11:41:30 +0200
Subject: [AstroPy] AstroPy Digest, Vol 68, Issue 13
In-Reply-To: <mailman.1.1335805203.32014.astropy@scipy.org>
References: <mailman.1.1335805203.32014.astropy@scipy.org>
Message-ID: <FB642458-DB1A-4604-BF4F-83C6BFC8DB88@desy.de>

> Dear all,
> 
> I am trying to create a FITS file with a bintable extension containing unsigned integers with pyfits but could not get it to work (example below). Does maybe someone know what I am doing wrong here?
> 
> Best wishes,
> Martin
> 
> import numpy as np
> import pyfits as pf
> 
> phdu = pf.PrimaryHDU(uint=True)
> 
> a_uint = np.ones(1, dtype=np.uint32)
> 
> events = pf.new_table(
>    pf.ColDefs([
>        pf.Column(name='EVENT_ID', array=a_uint, format='J', bscale=1, bzero=2**31)
>        pf.Column(name='OBS_ID', array=a_uint, format='J', bscale=1, bzero=2**31)
> #       ... a few more columns
>        ])
>    )
> 
> hdulist = pf.HDUList([phdu, events])
> 
> hdulist.writeto('tmp.fits')
> 
> hdulist = None
> 
> f = pf.open('tmp.fits')
> 
> In [2]: f[1].data
> Out[2]: 
> FITS_rec([(1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0)], 
>      dtype=[('EVENT_ID', '>i4'), ('OBS_ID', '>i4'), ('TIME', '>f4'), ('RA', '>f4'), ('DEC', '>f4'), ('DETX', '>f4'), ('DETY', '>f4'), ('ENERGY', '>f4'), ('HIL_MSW', '>f4'), ('HIL_MSL', '>f4')])
> 
> In [3]: f[1].data.field('EVENT_ID')[0].dtype
> Out[3]: dtype('float64')
> 
> 
> -----------------------------------
> 
> Martin Raue
> 
> Group Leader - LEXI Young Investigator Group
> "Cosmic radiation fields and search for dark matter in the early universe"
> http://wwwiexp.desy.de/groups/astroparticle/crf/
> 
> University of Hamburg
> Institute for Experimental Physics
> Luruper Chaussee 149
> D-22761 Hamburg
> Germany
> 
> Phone  : +49-40-8998-2993
> Fax    : +49-40-8998-2170
> E-Mail : martin.raue at desy.de
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 30 Apr 2012 11:18:25 -0400
> From: Erik Bray <embray at stsci.edu>
> Subject: Re: [AstroPy] Writing unsigned int with pyfits
> To: <astropy at scipy.org>
> Message-ID: <4F9EAD41.2050204 at stsci.edu>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
> 
> On 04/30/2012 09:45 AM, Martin Raue wrote:
>> Dear all,
>> 
>> I am trying to create a FITS file with a bintable extension containing unsigned integers with pyfits but could not get it to work (example below). Does maybe someone know what I am doing wrong here?
>> 
>> Best wishes,
>> Martin
>> 
>> import numpy as np
>> import pyfits as pf
>> 
>> phdu = pf.PrimaryHDU(uint=True)
>> 
>> a_uint = np.ones(1, dtype=np.uint32)
>> 
>> events = pf.new_table(
>>     pf.ColDefs([
>>         pf.Column(name='EVENT_ID', array=a_uint, format='J', bscale=1, bzero=2**31)
>>         pf.Column(name='OBS_ID', array=a_uint, format='J', bscale=1, bzero=2**31)
>> #       ... a few more columns
>>         ])
>>     )
>> 
>> hdulist = pf.HDUList([phdu, events])
>> 
>> hdulist.writeto('tmp.fits')
>> 
>> hdulist = None
>> 
>> f = pf.open('tmp.fits')
>> 
>> In [2]: f[1].data
>> Out[2]:
>> FITS_rec([(1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0)],
>>       dtype=[('EVENT_ID', '>i4'), ('OBS_ID', '>i4'), ('TIME', '>f4'), ('RA', '>f4'), ('DEC', '>f4'), ('DETX', '>f4'), ('DETY', '>f4'), ('ENERGY', '>f4'), ('HIL_MSW', '>f4'), ('HIL_MSL', '>f4')])
>> 
>> In [3]: f[1].data.field('EVENT_ID')[0].dtype
>> Out[3]: dtype('float64')
> 
> I believe that you are doing this correctly.  However, when a column has 
> non-trivial BSCALE and/or BZERO values, the values in that column are 
> converted to floats on the fly.  That's because the TSCALn and TZEROn 
> values themselves are actually treated as floats by the FITS standard.
> 
> So while the column format shows up as ints, the actual values given to 
> the user are floats with the bscale+bzero applied.  If you save changes 
> to the file the values will be converted back to ints.
> 
> I think the problem here is that PyFITS supports unsigned ints in image 
> data by using the `uint=True` argument when opening a FITS file.  Using 
> that argument causes PyFITS to recognize that you want pseudo-unsigned 
> ints to be returned as actual unsigned ints, and not floats.  However, 
> it seems like it only works for images, and not for table columns. 
> That, perhaps, should be fixed.

For table creation (i.e. in Column) maybe one could also support for the pseudo data types S, U and V, as done in cfitsio, which then get automatically converted to the correct TZERO/TSCALE values.
http://heasarc.gsfc.nasa.gov/docs/software/fitsio/quick/node10.html

m.

> 
> Erik
> 
> 
> ------------------------------
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
> 
> 
> End of AstroPy Digest, Vol 68, Issue 13
> ***************************************



From wkerzendorf at gmail.com  Tue May  1 20:05:33 2012
From: wkerzendorf at gmail.com (Wolfgang Kerzendorf)
Date: Tue, 1 May 2012 20:05:33 -0400
Subject: [AstroPy] API question: Instantiating of time/coord and similar
Message-ID: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>

Hello guys,

I've just worked on the time package in astropy (PR https://github.com/astropy/astropy/pull/212) which generated some discussion about the general API for instantiating time/coord (and similar).

There are multiple ideas and issues. I'll use the coordinates as an example as it demonstrates the problems rather well:

Imagine a class coord that somehow takes a coordinate stores it in an internal format (let's say x, y, z for coords) and then can convert it into any other format (galactic, equatorial, my fancy system). 



Instantiation:

(1) The instantiation can happen through different keywords: mycoord = coord(equatorial=(200, 20)); mycoord = coord(galactic=(200,20)).

(2) The instantiation can happen through classmethods: mycoord = coord.from_equatorial(200,20); mycoord = coord.from_galactic(200,20)

the next question is how flexible should this be (using notation (1)):

mycoord = coord(equatorial=(200, 20)) and mycoord = coord(equatorial=('15:20:44.5', '3d5m7s')).

or should we require that it is spelt out what is read (format and units would have defaults):

mycoord = coord(equatorial=(200, 20), format='num', units='degree') and mycoord = coord(equatorial=('15:20:44.5', '3d5m7s'), format='sex', units='hour')

There are many other implementation possibilities. Brainstorm! ;-)

But please stay on topic, we are only talking about the API exposed to the user here.

Cheers
    Wolfgang



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120501/a4a061f0/attachment.html>

From d.berry at jach.hawaii.edu  Wed May  2 03:08:23 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Wed, 2 May 2012 08:08:23 +0100
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
Message-ID: <CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>

Hi Wolfgang

If you are writing an object-oriented coordinate handling system,
PyAST may give you some ideas (see
http://dsberry.github.com/starlink/pyast.html). It's a python
interface  to the WCS coordinate handling system used by the DS9 and
GAIA image browsers amongst other things.

On your specific question, fifteen years of using AST has convinced me
that separating the definition of the coordinate system from the
coordinate values themselves leads to greater flexibility. So AST has
a "Frame" class that defines the properties of a coordinate system,
and then it has a PointList class which encapsulates a Frame  and
numerical axis values for a set of points. So using pyast, an
instantiation of a PointSet to describe a set of points on the sky in
galactic coords would look like this:

import starlink.Ast as Ast
frame = Ast.SkyFrame( "System=Galactic" )
points = Ast.PointList( frame, [[ 120.2,78.0], [118.3,77.0], [115.6,72.3] ] )

So for instance with a separate Frame class, it is natural to have a
Frame method that automatically generates a transformation between two
Frames:

frame2 = Ast.SkyFrame( "System=ICRS" )
ICRS_to_galactic =  Ast.Convert( frame, frame2 )

("ICRS_to_galactic" is a "Mapping" that allows numerical axis values
to be transformed from "frame" to "frame2").

or to create compound Frames by combining two or more Frames into a
more complex coordinate system. For instance, a Frame to  describe a
3D spectral cube:

frame3 = Ast.SpecFrame( "System=VELO, RestFreq=1.0E15, StdOfRest=LSRK" )
cubeframe = Ast.CmpFrame( frame, frame3 )

and you can use Frames for lots of other purposes (e.g. creating trees
of Frames connected by Mappings to describe a library of coordinate
systems, etc).

David


On 2 May 2012 01:05, Wolfgang Kerzendorf <wkerzendorf at gmail.com> wrote:
> Hello guys,
>
> I've just worked on the time package in astropy
> (PR?https://github.com/astropy/astropy/pull/212) which generated some
> discussion about the general API for instantiating time/coord (and similar).
>
> There are multiple ideas and issues. I'll use the coordinates as an example
> as it demonstrates the problems rather well:
>
> Imagine a class coord that somehow takes a coordinate stores it in an
> internal format (let's say x, y, z for coords) and then can convert it into
> any other format (galactic, equatorial, my fancy system).
>
>
>
> Instantiation:
>
> (1) The instantiation can happen through different keywords: mycoord =
> coord(equatorial=(200, 20)); mycoord = coord(galactic=(200,20)).
>
> (2) The instantiation can happen through classmethods: mycoord =
> coord.from_equatorial(200,20); mycoord = coord.from_galactic(200,20)
>
> the next question is how flexible should this be (using notation (1)):
>
> mycoord = coord(equatorial=(200, 20)) and mycoord =
> coord(equatorial=('15:20:44.5', '3d5m7s')).
>
> or should we require that it is spelt out what is read (format and units
> would have defaults):
>
> mycoord = coord(equatorial=(200, 20), format='num', units='degree') and
> mycoord = coord(equatorial=('15:20:44.5', '3d5m7s'), format='sex',
> units='hour')
>
> There are many other implementation possibilities. Brainstorm! ;-)
>
> But please stay on topic, we are only talking about the API exposed to the
> user here.
>
> Cheers
> ? ? Wolfgang
>
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>


From erik.tollerud at gmail.com  Wed May  2 05:06:21 2012
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Wed, 2 May 2012 02:06:21 -0700
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
Message-ID: <CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>

Hi David,

I'm curious about your point of separating the frame/coordinate system
and the coordinates themselves.  Are you saying you think it's clearer
from the *user* perspective, or from the *implementation/developer*
perspective? (or both?)


While I definitely see the merits of such a separation from the dev
side of things (wish I'd seen this sooner, actually!), it seems a bit
more confusing from the user side.  I personally favor a user-level
interface along the lines of:

coord = ICRSCoordinates('1:2:3.4 +56:7:8.9')

or possibly

coord = Coordinates('1:2:3.4 +56:7:8.9',system='ICRS')


and then you just do

coord.convert(GalacticCoordinates)

or

coord.convert('galactic')

or even

coord.galactic


These seem more natural to people I talk to who aren't used to
thinking about OO concepts (astropy is intended for both "users" and
"developers," although that distinction is ill-defined for
astronomers).

Such an interface can definitely be mapped onto an underlying system
like you suggest for easier development, but here I'm talking about
the more "user"-level interface.



On Wed, May 2, 2012 at 12:08 AM, David Berry <d.berry at jach.hawaii.edu> wrote:
> Hi Wolfgang
>
> If you are writing an object-oriented coordinate handling system,
> PyAST may give you some ideas (see
> http://dsberry.github.com/starlink/pyast.html). It's a python
> interface ?to the WCS coordinate handling system used by the DS9 and
> GAIA image browsers amongst other things.
>
> On your specific question, fifteen years of using AST has convinced me
> that separating the definition of the coordinate system from the
> coordinate values themselves leads to greater flexibility. So AST has
> a "Frame" class that defines the properties of a coordinate system,
> and then it has a PointList class which encapsulates a Frame ?and
> numerical axis values for a set of points. So using pyast, an
> instantiation of a PointSet to describe a set of points on the sky in
> galactic coords would look like this:
>
> import starlink.Ast as Ast
> frame = Ast.SkyFrame( "System=Galactic" )
> points = Ast.PointList( frame, [[ 120.2,78.0], [118.3,77.0], [115.6,72.3] ] )
>
> So for instance with a separate Frame class, it is natural to have a
> Frame method that automatically generates a transformation between two
> Frames:
>
> frame2 = Ast.SkyFrame( "System=ICRS" )
> ICRS_to_galactic = ?Ast.Convert( frame, frame2 )
>
> ("ICRS_to_galactic" is a "Mapping" that allows numerical axis values
> to be transformed from "frame" to "frame2").
>
> or to create compound Frames by combining two or more Frames into a
> more complex coordinate system. For instance, a Frame to ?describe a
> 3D spectral cube:
>
> frame3 = Ast.SpecFrame( "System=VELO, RestFreq=1.0E15, StdOfRest=LSRK" )
> cubeframe = Ast.CmpFrame( frame, frame3 )
>
> and you can use Frames for lots of other purposes (e.g. creating trees
> of Frames connected by Mappings to describe a library of coordinate
> systems, etc).
>
> David
>
>
> On 2 May 2012 01:05, Wolfgang Kerzendorf <wkerzendorf at gmail.com> wrote:
>> Hello guys,
>>
>> I've just worked on the time package in astropy
>> (PR?https://github.com/astropy/astropy/pull/212) which generated some
>> discussion about the general API for instantiating time/coord (and similar).
>>
>> There are multiple ideas and issues. I'll use the coordinates as an example
>> as it demonstrates the problems rather well:
>>
>> Imagine a class coord that somehow takes a coordinate stores it in an
>> internal format (let's say x, y, z for coords) and then can convert it into
>> any other format (galactic, equatorial, my fancy system).
>>
>>
>>
>> Instantiation:
>>
>> (1) The instantiation can happen through different keywords: mycoord =
>> coord(equatorial=(200, 20)); mycoord = coord(galactic=(200,20)).
>>
>> (2) The instantiation can happen through classmethods: mycoord =
>> coord.from_equatorial(200,20); mycoord = coord.from_galactic(200,20)
>>
>> the next question is how flexible should this be (using notation (1)):
>>
>> mycoord = coord(equatorial=(200, 20)) and mycoord =
>> coord(equatorial=('15:20:44.5', '3d5m7s')).
>>
>> or should we require that it is spelt out what is read (format and units
>> would have defaults):
>>
>> mycoord = coord(equatorial=(200, 20), format='num', units='degree') and
>> mycoord = coord(equatorial=('15:20:44.5', '3d5m7s'), format='sex',
>> units='hour')
>>
>> There are many other implementation possibilities. Brainstorm! ;-)
>>
>> But please stay on topic, we are only talking about the API exposed to the
>> user here.
>>
>> Cheers
>> ? ? Wolfgang
>>
>>
>>
>>
>> _______________________________________________
>> 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



-- 
Erik Tollerud


From d.berry at jach.hawaii.edu  Wed May  2 05:40:59 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Wed, 2 May 2012 10:40:59 +0100
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
Message-ID: <CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>

On 2 May 2012 10:06, Erik Tollerud <erik.tollerud at gmail.com> wrote:
> Hi David,
>
> I'm curious about your point of separating the frame/coordinate system
> and the coordinates themselves. ?Are you saying you think it's clearer
> from the *user* perspective, or from the *implementation/developer*
> perspective? (or both?)

I'm talking about someone developing high-level application code - say
an application to resample an arbitrary FITS data array so that it is
aligned with a second arbitrary FITS data array. That sort of level -
people who need to use  coordinate systems (world, pixel, what ever)
to achieve some useful higher level functionality, and want their code
to be generic rather than tied to some specific type of coordinate
system (images, cubes, spectra, etc).

Separating coordinate system definitions from the axis values (i.e.
having something like a separate Frame class) allows you to define a
whole load of useful operations that depend only on the nature of the
coordinate system, and not on any specific positions within that
coordinate system. For instance:

1) Given two Frames, find a transformation between them. For instance,
if you have a pair of Frames representing different celestial
coordinate systems, or spectral coorinate systems, or time coordinate
systems, or any combination, AST has a method
(http://www.starlink.ac.uk/docs/sun211.htx/node245.html) that will
return you a Mapping (if possible) that can be used to transform
position from one Frame to the other. This is

2) Navigate around a coordinate system. Given that some coordinate
systems are flat (i.e. pixel coords) and some are spherical (e.g.
celestial), together with the varying dimensionality (1D spectra, 2D
images, 3D spectral cubes, etc), produces quite a bit of complication.
So having Frame methods that can answer questions like "If I start at
point A in Frame xyz and move towards point B for a distance X, then
turn through an angle Y and move a further distance Z, where do I end
up?" is really useful (lots of AST  examples - e.g.
http://www.starlink.ac.uk/docs/sun211.htx/node340.html)

3) Attaching a set of coordinate systems to a data cube (i.e. the sort
of thing the FITS WCS papers cover) - you can define the Frames
("pixel", "Focal plane", "sky", etc), and the Mappings between them,
and then join them all into some higher level object (a "FrameSet" in
AST - http://www.starlink.ac.uk/docs/sun211.htx/node270.html) that
allows you to convert positions between any pair of frames.

4) If you read such a FrameSet from a data set, you can search it for
coordinate systems with particular properties by using a Frame as a
sort of wild-card template ("search the FrameSet for any Frames that
have properties matching this template Frame" -
http://www.starlink.ac.uk/docs/sun211.htx/node264.html).

5) The Frame can define things like how to format or parse axis
values. For instance,  equatorial sky coordinates may be represented
internally in degrees or radians, but should probably be represented
as sexagisimal RA and Dec values. But other coordinate systems (e.g.
galactic sky coords or pixel coords) are usually represented as
decimal values. A Frame class is a good place to encapsulate all this
knowledge (e.g.
http://www.starlink.ac.uk/docs/sun211.htx/node435.html).

6) Plus of course, a Frame can encapsulate axis labels, axis units,
coordinate system title, etc, etc.

> While I definitely see the merits of such a separation from the dev
> side of things (wish I'd seen this sooner, actually!), it seems a bit
> more confusing from the user side. ?I personally favor a user-level
> interface along the lines of:
>
> coord = ICRSCoordinates('1:2:3.4 +56:7:8.9')
>
> or possibly
>
> coord = Coordinates('1:2:3.4 +56:7:8.9',system='ICRS')
>
>
> and then you just do
>
> coord.convert(GalacticCoordinates)
>
> or
>
> coord.convert('galactic')
>
> or even
>
> coord.galactic
>
>
> These seem more natural to people I talk to who aren't used to
> thinking about OO concepts (astropy is intended for both "users" and
> "developers," although that distinction is ill-defined for
> astronomers).
>
> Such an interface can definitely be mapped onto an underlying system
> like you suggest for easier development, but here I'm talking about
> the more "user"-level interface.

I probably agree with you about that. The system I describe gives more
flexibility, but is certainly more verbose.

David


From perry at stsci.edu  Wed May  2 16:03:23 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Wed, 2 May 2012 16:03:23 -0400
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
Message-ID: <766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>

Are these necessarily exclusive approaches? (by the way, most of ast  
links are slightly corrupted by appended closing parentheses  
apparently).

Perry

On May 2, 2012, at 5:40 AM, David Berry wrote:

> On 2 May 2012 10:06, Erik Tollerud <erik.tollerud at gmail.com> wrote:
>> Hi David,
>>
>> I'm curious about your point of separating the frame/coordinate  
>> system
>> and the coordinates themselves.  Are you saying you think it's  
>> clearer
>> from the *user* perspective, or from the *implementation/developer*
>> perspective? (or both?)
>
> I'm talking about someone developing high-level application code - say
> an application to resample an arbitrary FITS data array so that it is
> aligned with a second arbitrary FITS data array. That sort of level -
> people who need to use  coordinate systems (world, pixel, what ever)
> to achieve some useful higher level functionality, and want their code
> to be generic rather than tied to some specific type of coordinate
> system (images, cubes, spectra, etc).
>
> Separating coordinate system definitions from the axis values (i.e.
> having something like a separate Frame class) allows you to define a
> whole load of useful operations that depend only on the nature of the
> coordinate system, and not on any specific positions within that
> coordinate system. For instance:
>
> 1) Given two Frames, find a transformation between them. For instance,
> if you have a pair of Frames representing different celestial
> coordinate systems, or spectral coorinate systems, or time coordinate
> systems, or any combination, AST has a method
> (http://www.starlink.ac.uk/docs/sun211.htx/node245.html) that will
> return you a Mapping (if possible) that can be used to transform
> position from one Frame to the other. This is
>
> 2) Navigate around a coordinate system. Given that some coordinate
> systems are flat (i.e. pixel coords) and some are spherical (e.g.
> celestial), together with the varying dimensionality (1D spectra, 2D
> images, 3D spectral cubes, etc), produces quite a bit of complication.
> So having Frame methods that can answer questions like "If I start at
> point A in Frame xyz and move towards point B for a distance X, then
> turn through an angle Y and move a further distance Z, where do I end
> up?" is really useful (lots of AST  examples - e.g.
> http://www.starlink.ac.uk/docs/sun211.htx/node340.html)
>
> 3) Attaching a set of coordinate systems to a data cube (i.e. the sort
> of thing the FITS WCS papers cover) - you can define the Frames
> ("pixel", "Focal plane", "sky", etc), and the Mappings between them,
> and then join them all into some higher level object (a "FrameSet" in
> AST - http://www.starlink.ac.uk/docs/sun211.htx/node270.html) that
> allows you to convert positions between any pair of frames.
>
> 4) If you read such a FrameSet from a data set, you can search it for
> coordinate systems with particular properties by using a Frame as a
> sort of wild-card template ("search the FrameSet for any Frames that
> have properties matching this template Frame" -
> http://www.starlink.ac.uk/docs/sun211.htx/node264.html).
>
> 5) The Frame can define things like how to format or parse axis
> values. For instance,  equatorial sky coordinates may be represented
> internally in degrees or radians, but should probably be represented
> as sexagisimal RA and Dec values. But other coordinate systems (e.g.
> galactic sky coords or pixel coords) are usually represented as
> decimal values. A Frame class is a good place to encapsulate all this
> knowledge (e.g.
> http://www.starlink.ac.uk/docs/sun211.htx/node435.html).
>
> 6) Plus of course, a Frame can encapsulate axis labels, axis units,
> coordinate system title, etc, etc.
>
>> While I definitely see the merits of such a separation from the dev
>> side of things (wish I'd seen this sooner, actually!), it seems a bit
>> more confusing from the user side.  I personally favor a user-level
>> interface along the lines of:
>>
>> coord = ICRSCoordinates('1:2:3.4 +56:7:8.9')
>>
>> or possibly
>>
>> coord = Coordinates('1:2:3.4 +56:7:8.9',system='ICRS')
>>
>>
>> and then you just do
>>
>> coord.convert(GalacticCoordinates)
>>
>> or
>>
>> coord.convert('galactic')
>>
>> or even
>>
>> coord.galactic
>>
>>
>> These seem more natural to people I talk to who aren't used to
>> thinking about OO concepts (astropy is intended for both "users" and
>> "developers," although that distinction is ill-defined for
>> astronomers).
>>
>> Such an interface can definitely be mapped onto an underlying system
>> like you suggest for easier development, but here I'm talking about
>> the more "user"-level interface.
>
> I probably agree with you about that. The system I describe gives more
> flexibility, but is certainly more verbose.
>
> David
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From tim.jenness at gmail.com  Wed May  2 16:42:21 2012
From: tim.jenness at gmail.com (Tim Jenness)
Date: Wed, 2 May 2012 13:42:21 -0700
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
Message-ID: <CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>

On Wed, May 2, 2012 at 1:03 PM, Perry Greenfield <perry at stsci.edu> wrote:
> Are these necessarily exclusive approaches?

AST was designed to handle mappings from different coordinate systems
from the beginning to handle data pixel coordinates to WCS to graphic
coordinates (and vice versa) in a transparent manner.

The examples earlier in this thread are more based around conversion
of a single value from one frame to another and there are many
simplifications that are possible when that is done. A single galactic
coordinate to the corresponding RA/Dec coordinate is a well understood
conversion that never changes. AST will let you work out the world
coordinates of a particular pixel in your image, or the pixel that
corresponds to a particular WCS, or the position on the graphics
plotting device corresponding to either the data pixel or the WCS
coordinate. The transformation from RA/Dec to Galactic is all handled
in a specialist SKY frame and you can actually do the simple
translations by setting attributes in a Sky frame object without
having to understand mappings and pixel coordinates (so easily
wrappable).

> (by the way, most of ast
> links are slightly corrupted by appended closing parentheses
> apparently).

I think it depends on the mailer. gmail guesses (correctly) that the
trailing parenthesis below is not part of the URL so it does work.

>> 1) Given two Frames, find a transformation between them. For instance,
>> if you have a pair of Frames representing different celestial
>> coordinate systems, or spectral coorinate systems, or time coordinate
>> systems, or any combination, AST has a method
>> ( http://www.starlink.ac.uk/docs/sun211.htx/node245.html ) that will
>> return you a Mapping (if possible) that can be used to transform
>> position from one Frame to the other. This is
>>

>> up?" is really useful (lots of AST ?examples - e.g.
>> http://www.starlink.ac.uk/docs/sun211.htx/node340.html
>>
>> 3) Attaching a set of coordinate systems to a data cube (i.e. the sort
>> of thing the FITS WCS papers cover) - you can define the Frames
>> ("pixel", "Focal plane", "sky", etc), and the Mappings between them,
>> and then join them all into some higher level object (a "FrameSet" in
>> AST - http://www.starlink.ac.uk/docs/sun211.htx/node270.html ) that
>> allows you to convert positions between any pair of frames.
>>
>> 4) If you read such a FrameSet from a data set, you can search it for
>> coordinate systems with particular properties by using a Frame as a
>> sort of wild-card template ("search the FrameSet for any Frames that
>> have properties matching this template Frame" -
>> http://www.starlink.ac.uk/docs/sun211.htx/node264.html ).
>>
>> 5) The Frame can define things like how to format or parse axis
>> values. For instance, ?equatorial sky coordinates may be represented
>> internally in degrees or radians, but should probably be represented
>> as sexagisimal RA and Dec values. But other coordinate systems (e.g.
>> galactic sky coords or pixel coords) are usually represented as
>> decimal values. A Frame class is a good place to encapsulate all this
>> knowledge (e.g.
>> http://www.starlink.ac.uk/docs/sun211.htx/node435.html ).
>>

-- 
Tim Jenness


From perry at stsci.edu  Wed May  2 17:04:33 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Wed, 2 May 2012 17:04:33 -0400
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
Message-ID: <50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>


On May 2, 2012, at 4:42 PM, Tim Jenness wrote:

> On Wed, May 2, 2012 at 1:03 PM, Perry Greenfield <perry at stsci.edu>  
> wrote:
>> Are these necessarily exclusive approaches?
>
> AST was designed to handle mappings from different coordinate systems
> from the beginning to handle data pixel coordinates to WCS to graphic
> coordinates (and vice versa) in a transparent manner.
>
> The examples earlier in this thread are more based around conversion
> of a single value from one frame to another and there are many
> simplifications that are possible when that is done. A single galactic
> coordinate to the corresponding RA/Dec coordinate is a well understood
> conversion that never changes. AST will let you work out the world
> coordinates of a particular pixel in your image, or the pixel that
> corresponds to a particular WCS, or the position on the graphics
> plotting device corresponding to either the data pixel or the WCS
> coordinate. The transformation from RA/Dec to Galactic is all handled
> in a specialist SKY frame and you can actually do the simple
> translations by setting attributes in a Sky frame object without
> having to understand mappings and pixel coordinates (so easily
> wrappable).
>
I'm not sure I understand how this corresponds the two approaches  
(both could apply to one coordinate or multiple coordinates I think).

Isn't the issue whether frames are disconnected from specific  
coordinate values or not? If one designs it so that they are, what  
keeps one from making a class that bundles the system with one or more  
coordinate values so that it does know how to convert the value(s) to  
another system. I don't think one needs to design two parallel systems  
for that. The bundled representation simply contains an attribute  
which is a frame along with an attribute for its coordinates. But I  
could be missing the whole point :-)

>> (by the way, most of ast
>> links are slightly corrupted by appended closing parentheses
>> apparently).
>
> I think it depends on the mailer. gmail guesses (correctly) that the
> trailing parenthesis below is not part of the URL so it does work.
>
No, it's something weirder than that. I've sent all variants of urls  
with trailing parentheses and they all work as links in my mail reader.

Perry


From tim.jenness at gmail.com  Wed May  2 17:17:13 2012
From: tim.jenness at gmail.com (Tim Jenness)
Date: Wed, 2 May 2012 14:17:13 -0700
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
Message-ID: <CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>

On Wed, May 2, 2012 at 2:04 PM, Perry Greenfield <perry at stsci.edu> wrote:
>
> On May 2, 2012, at 4:42 PM, Tim Jenness wrote:
>
>> On Wed, May 2, 2012 at 1:03 PM, Perry Greenfield <perry at stsci.edu> wrote:
>>>
>>> Are these necessarily exclusive approaches?
>>
>>
>> AST was designed to handle mappings from different coordinate systems
>> from the beginning to handle data pixel coordinates to WCS to graphic
>> coordinates (and vice versa) in a transparent manner.
>>
>> The examples earlier in this thread are more based around conversion
>> of a single value from one frame to another and there are many
>> simplifications that are possible when that is done. A single galactic
>> coordinate to the corresponding RA/Dec coordinate is a well understood
>> conversion that never changes. AST will let you work out the world
>> coordinates of a particular pixel in your image, or the pixel that
>> corresponds to a particular WCS, or the position on the graphics
>> plotting device corresponding to either the data pixel or the WCS
>> coordinate. The transformation from RA/Dec to Galactic is all handled
>> in a specialist SKY frame and you can actually do the simple
>> translations by setting attributes in a Sky frame object without
>> having to understand mappings and pixel coordinates (so easily
>> wrappable).
>>
> I'm not sure I understand how this corresponds the two approaches (both
> could apply to one coordinate or multiple coordinates I think).
>
> Isn't the issue whether frames are disconnected from specific coordinate
> values or not? If one designs it so that they are, what keeps one from
> making a class that bundles the system with one or more coordinate values so
> that it does know how to convert the value(s) to another system. I don't
> think one needs to design two parallel systems for that. The bundled
> representation simply contains an attribute which is a frame along with an
> attribute for its coordinates. But I could be missing the whole point :-)
>

In the AST design the SkyFrame understands everything there is to
understand (within reason) about astronomical coordinates. It know how
to convert from J2000 to ICRS to Galactic and has attributes of epoch,
equinox etc.

http://www.starlink.ac.uk/docs/sun211.htx/node677.html

Similarly a TimeFrame knows how to convert from different types of
time internally (TDB, UTC, TAI etc).

 http://www.starlink.ac.uk/docs/sun211.htx/node691.html

you can use these frames standalone to do internal conversions from
UTC to TAI or Galactic to RA/Dec.

AST goes a step further and adds the ability to connect these frames
together using mappings. A simple mapping would be from a pixel grid
to a sky coordinate but you can stack mappings and frames together so,
for example, a pointing correction can be inserted as a ShiftMap
between the two frames as an additional mapping. You can then stack
additional frames and mappings together for as much complexity as you
want. There are many frames and mappings available by default.


>>> (by the way, most of ast
>>> links are slightly corrupted by appended closing parentheses
>>> apparently).
>>
>>
>> I think it depends on the mailer. gmail guesses (correctly) that the
>> trailing parenthesis below is not part of the URL so it does work.
>>
> No, it's something weirder than that. I've sent all variants of urls with
> trailing parentheses and they all work as links in my mail reader.
>

Odd. Just tried them in Apple Mail (assuming we are talking about the
URLs in David's message) and that worked.

-- 
Tim Jenness


From wkerzendorf at gmail.com  Wed May  2 17:32:55 2012
From: wkerzendorf at gmail.com (Wolfgang Kerzendorf)
Date: Wed, 2 May 2012 17:32:55 -0400
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
Message-ID: <034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>

Hi Tim,

So I'm not quite getting what you're telling us? How do you want us to implement coordinates (not WCS) into astropy (the API - not the underlying mechanics)?

Cheers,
   Wolfgang

P.S.: I should also apologize as this was meant for the astropy-dev list and not for astropy (but I guess everyone who's on dev is on astropy as well). 


On 2012-05-02, at 5:17 PM, Tim Jenness wrote:

> On Wed, May 2, 2012 at 2:04 PM, Perry Greenfield <perry at stsci.edu> wrote:
>> 
>> On May 2, 2012, at 4:42 PM, Tim Jenness wrote:
>> 
>>> On Wed, May 2, 2012 at 1:03 PM, Perry Greenfield <perry at stsci.edu> wrote:
>>>> 
>>>> Are these necessarily exclusive approaches?
>>> 
>>> 
>>> AST was designed to handle mappings from different coordinate systems
>>> from the beginning to handle data pixel coordinates to WCS to graphic
>>> coordinates (and vice versa) in a transparent manner.
>>> 
>>> The examples earlier in this thread are more based around conversion
>>> of a single value from one frame to another and there are many
>>> simplifications that are possible when that is done. A single galactic
>>> coordinate to the corresponding RA/Dec coordinate is a well understood
>>> conversion that never changes. AST will let you work out the world
>>> coordinates of a particular pixel in your image, or the pixel that
>>> corresponds to a particular WCS, or the position on the graphics
>>> plotting device corresponding to either the data pixel or the WCS
>>> coordinate. The transformation from RA/Dec to Galactic is all handled
>>> in a specialist SKY frame and you can actually do the simple
>>> translations by setting attributes in a Sky frame object without
>>> having to understand mappings and pixel coordinates (so easily
>>> wrappable).
>>> 
>> I'm not sure I understand how this corresponds the two approaches (both
>> could apply to one coordinate or multiple coordinates I think).
>> 
>> Isn't the issue whether frames are disconnected from specific coordinate
>> values or not? If one designs it so that they are, what keeps one from
>> making a class that bundles the system with one or more coordinate values so
>> that it does know how to convert the value(s) to another system. I don't
>> think one needs to design two parallel systems for that. The bundled
>> representation simply contains an attribute which is a frame along with an
>> attribute for its coordinates. But I could be missing the whole point :-)
>> 
> 
> In the AST design the SkyFrame understands everything there is to
> understand (within reason) about astronomical coordinates. It know how
> to convert from J2000 to ICRS to Galactic and has attributes of epoch,
> equinox etc.
> 
> http://www.starlink.ac.uk/docs/sun211.htx/node677.html
> 
> Similarly a TimeFrame knows how to convert from different types of
> time internally (TDB, UTC, TAI etc).
> 
> http://www.starlink.ac.uk/docs/sun211.htx/node691.html
> 
> you can use these frames standalone to do internal conversions from
> UTC to TAI or Galactic to RA/Dec.
> 
> AST goes a step further and adds the ability to connect these frames
> together using mappings. A simple mapping would be from a pixel grid
> to a sky coordinate but you can stack mappings and frames together so,
> for example, a pointing correction can be inserted as a ShiftMap
> between the two frames as an additional mapping. You can then stack
> additional frames and mappings together for as much complexity as you
> want. There are many frames and mappings available by default.
> 
> 
>>>> (by the way, most of ast
>>>> links are slightly corrupted by appended closing parentheses
>>>> apparently).
>>> 
>>> 
>>> I think it depends on the mailer. gmail guesses (correctly) that the
>>> trailing parenthesis below is not part of the URL so it does work.
>>> 
>> No, it's something weirder than that. I've sent all variants of urls with
>> trailing parentheses and they all work as links in my mail reader.
>> 
> 
> Odd. Just tried them in Apple Mail (assuming we are talking about the
> URLs in David's message) and that worked.
> 
> -- 
> Tim Jenness
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From perry at stsci.edu  Wed May  2 17:35:02 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Wed, 2 May 2012 17:35:02 -0400
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
Message-ID: <71914D8D-CB62-41B2-8312-EA7FD38A79F5@stsci.edu>


On May 2, 2012, at 5:17 PM, Tim Jenness wrote:

> On Wed, May 2, 2012 at 2:04 PM, Perry Greenfield <perry at stsci.edu>  
> wrote:
>>
>> On May 2, 2012, at 4:42 PM, Tim Jenness wrote:
>>
>>> On Wed, May 2, 2012 at 1:03 PM, Perry Greenfield <perry at stsci.edu>  
>>> wrote:
>>>>
>>>> Are these necessarily exclusive approaches?
>>>
>>>
>>> AST was designed to handle mappings from different coordinate  
>>> systems
>>> from the beginning to handle data pixel coordinates to WCS to  
>>> graphic
>>> coordinates (and vice versa) in a transparent manner.
>>>
>>> The examples earlier in this thread are more based around conversion
>>> of a single value from one frame to another and there are many
>>> simplifications that are possible when that is done. A single  
>>> galactic
>>> coordinate to the corresponding RA/Dec coordinate is a well  
>>> understood
>>> conversion that never changes. AST will let you work out the world
>>> coordinates of a particular pixel in your image, or the pixel that
>>> corresponds to a particular WCS, or the position on the graphics
>>> plotting device corresponding to either the data pixel or the WCS
>>> coordinate. The transformation from RA/Dec to Galactic is all  
>>> handled
>>> in a specialist SKY frame and you can actually do the simple
>>> translations by setting attributes in a Sky frame object without
>>> having to understand mappings and pixel coordinates (so easily
>>> wrappable).
>>>
>> I'm not sure I understand how this corresponds the two approaches  
>> (both
>> could apply to one coordinate or multiple coordinates I think).
>>
>> Isn't the issue whether frames are disconnected from specific  
>> coordinate
>> values or not? If one designs it so that they are, what keeps one  
>> from
>> making a class that bundles the system with one or more coordinate  
>> values so
>> that it does know how to convert the value(s) to another system. I  
>> don't
>> think one needs to design two parallel systems for that. The bundled
>> representation simply contains an attribute which is a frame along  
>> with an
>> attribute for its coordinates. But I could be missing the whole  
>> point :-)
>>
>
> In the AST design the SkyFrame understands everything there is to
> understand (within reason) about astronomical coordinates. It know how
> to convert from J2000 to ICRS to Galactic and has attributes of epoch,
> equinox etc.
>
> http://www.starlink.ac.uk/docs/sun211.htx/node677.html
>
> Similarly a TimeFrame knows how to convert from different types of
> time internally (TDB, UTC, TAI etc).
>
> http://www.starlink.ac.uk/docs/sun211.htx/node691.html
>
> you can use these frames standalone to do internal conversions from
> UTC to TAI or Galactic to RA/Dec.
>
> AST goes a step further and adds the ability to connect these frames
> together using mappings. A simple mapping would be from a pixel grid
> to a sky coordinate but you can stack mappings and frames together so,
> for example, a pointing correction can be inserted as a ShiftMap
> between the two frames as an additional mapping. You can then stack
> additional frames and mappings together for as much complexity as you
> want. There are many frames and mappings available by default.
>
Sure. But what keeps you from associating frames with specific  
coordinate values? In that case, the object that holds both knows how  
to convert the values to another frame.

Perry



From tim.jenness at gmail.com  Wed May  2 17:54:47 2012
From: tim.jenness at gmail.com (Tim Jenness)
Date: Wed, 2 May 2012 14:54:47 -0700
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
Message-ID: <CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>

On Wed, May 2, 2012 at 2:32 PM, Wolfgang Kerzendorf
<wkerzendorf at gmail.com> wrote:
> Hi Tim,
>
> So I'm not quite getting what you're telling us? How do you want us to implement coordinates (not WCS) into astropy (the API - not the underlying mechanics)?
>

I not trying to tell you how to do anything although I'd be happy to
help. David and I were trying to explain the concepts behind our
system. Obviously from my point of view there is 20 years of
experience in coordinate handling inside the pyast library and it
would be great to leverage that some how. I assume there is a goal of
only relying on numpy as the only non-pure python library so pyast
would not be acceptable but you could design a system that used AST
internally and switched it out at a later date when you wanted to go
pure python.

Even if you don't want to use AST I feel strongly that the idea of
separating frames from mappings and allowing frames and mappings to be
stacked together is incredibly powerful. It's a very flexible approach
that allows specific class knowledge to be added incrementally; time
support was not in the original AST release and neither was support
for spectral coordinates or IFUs.

If you want to see AST in use, the new version of DS9 relies entirely
upon AST for coordinate plotting and transformations.

>
> P.S.: I should also apologize as this was meant for the astropy-dev list and not for astropy (but I guess everyone who's on dev is on astropy as well).

I'll sign up. I had missed the dev list.

-- 
Tim Jenness
Joint Astronomy Centre.


From tim.jenness at gmail.com  Wed May  2 17:59:19 2012
From: tim.jenness at gmail.com (Tim Jenness)
Date: Wed, 2 May 2012 14:59:19 -0700
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <71914D8D-CB62-41B2-8312-EA7FD38A79F5@stsci.edu>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<71914D8D-CB62-41B2-8312-EA7FD38A79F5@stsci.edu>
Message-ID: <CA+G92RckYtyNOE9ZK6LbVDtV2NViSjcThj-Qhwpvqd0CBzbn7A@mail.gmail.com>

On Wed, May 2, 2012 at 2:35 PM, Perry Greenfield <perry at stsci.edu> wrote:
>
> On May 2, 2012, at 5:17 PM, Tim Jenness wrote:
>
>> On Wed, May 2, 2012 at 2:04 PM, Perry Greenfield <perry at stsci.edu> wrote:
>>>
>>>
>>> On May 2, 2012, at 4:42 PM, Tim Jenness wrote:
>>>
>>>> On Wed, May 2, 2012 at 1:03 PM, Perry Greenfield <perry at stsci.edu>

>>
>> AST goes a step further and adds the ability to connect these frames
>> together using mappings. A simple mapping would be from a pixel grid
>> to a sky coordinate but you can stack mappings and frames together so,
>> for example, a pointing correction can be inserted as a ShiftMap
>> between the two frames as an additional mapping. You can then stack
>> additional frames and mappings together for as much complexity as you
>> want. There are many frames and mappings available by default.
>>
> Sure. But what keeps you from associating frames with specific coordinate
> values? In that case, the object that holds both knows how to convert the
> values to another frame.
>

Well, the specific coordinate value is distinct from the frame
definition and from the mappings. The AST approach is to create a
FrameSet object which encapsulates the frames and the associated
mappings and then you would supply a coordinate (or multiple
coordinates) to a conversion method and it would return the translated
coordinates.

You could have a higher level object that held the specific input
coordinate and the frameset but you'd ordinarily want to reuse that
frameset for more than one location.

-- 
Tim Jenness


From jturner at gemini.edu  Wed May  2 18:56:57 2012
From: jturner at gemini.edu (James Turner)
Date: Wed, 2 May 2012 18:56:57 -0400
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
Message-ID: <4FA1BBB9.5050801@gemini.edu>

> Obviously from my point of view there is 20 years of
> experience in coordinate handling inside the pyast library and it
> would be great to leverage that some how. I assume there is a goal of
> only relying on numpy as the only non-pure python library so pyast
> would not be acceptable but you could design a system that used AST
> internally and switched it out at a later date when you wanted to go
> pure python.

That sounds pretty sensible to me and good input for those of us
working with co-ordinates in Python. Perhaps a year ago, I and a
couple of other people (including Perry) separately recognized some
important concepts for handling co-ordinates that are missing from
FITS but that will be needed in Python software, such as combining
mappings as I think Tim is describing. After a little discussion,
Paul Hirst pointed me to AST, which had already incorporated the
same ideas N years previously :-). However, there is indeed some
reluctance to pull another C library into the equation, for multiple
good reasons. Although there's bound to be some variation on how to
approach things, the problems are sufficiently non-trivial that a
working model and/or prior experience seem valuable things to have...

Not sure where things stand regarding the GPL etc. though? I think
the decision was to use BSD in AstroPy. (If you reply just to this
question I'd suggest changing the subject.)

Cheers,

James.

> Even if you don't want to use AST I feel strongly that the idea of
> separating frames from mappings and allowing frames and mappings to be
> stacked together is incredibly powerful. It's a very flexible approach
> that allows specific class knowledge to be added incrementally; time
> support was not in the original AST release and neither was support
> for spectral coordinates or IFUs.
>
> If you want to see AST in use, the new version of DS9 relies entirely
> upon AST for coordinate plotting and transformations.
>
>>
>> P.S.: I should also apologize as this was meant for the astropy-dev list and not for astropy (but I guess everyone who's on dev is on astropy as well).
>
> I'll sign up. I had missed the dev list.


From Christoph.Deil at mpi-hd.mpg.de  Wed May  2 20:44:57 2012
From: Christoph.Deil at mpi-hd.mpg.de (Christoph Deil)
Date: Thu, 3 May 2012 01:44:57 +0100
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <4FA1BBB9.5050801@gemini.edu>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
Message-ID: <5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>


On May 2, 2012, at 11:56 PM, James Turner wrote:

>> Obviously from my point of view there is 20 years of
>> experience in coordinate handling inside the pyast library and it
>> would be great to leverage that some how. I assume there is a goal of
>> only relying on numpy as the only non-pure python library so pyast
>> would not be acceptable but you could design a system that used AST
>> internally and switched it out at a later date when you wanted to go
>> pure python.
> 
> That sounds pretty sensible to me and good input for those of us
> working with co-ordinates in Python. Perhaps a year ago, I and a
> couple of other people (including Perry) separately recognized some
> important concepts for handling co-ordinates that are missing from
> FITS but that will be needed in Python software, such as combining
> mappings as I think Tim is describing. After a little discussion,
> Paul Hirst pointed me to AST, which had already incorporated the
> same ideas N years previously :-). However, there is indeed some
> reluctance to pull another C library into the equation, for multiple
> good reasons. Although there's bound to be some variation on how to
> approach things, the problems are sufficiently non-trivial that a
> working model and/or prior experience seem valuable things to have...
> 
> Not sure where things stand regarding the GPL etc. though? I think
> the decision was to use BSD in AstroPy. (If you reply just to this
> question I'd suggest changing the subject.)


I have been using the celestial module in the Kapteyn package and liked it a lot:

http://www.astro.rug.nl/software/kapteyn/
http://www.astro.rug.nl/software/kapteyn/celestial.html
http://www.astro.rug.nl/software/kapteyn/celestialbackground.html

kapteyn.celestial is 3500 lines of well-documented python + numpy code and has a BSD license.
Some other parts of kapteyn are Cython-wrapped C-code.

Probably it would be better to base astropy.coordinates on PyAST or kapteyn or some other package instead of starting from scratch?
Does anyone have experience with both packages and can comment on their API strengths / weaknesses and performance (i.e. speed and precision)?
(I have CC'ed the kapteyn developers in case they are not aware of this discussion.)

One more question:
Is it planned to also have Alt-Az to RA-Dec coordinate transformations in astropy?
If we want such "observer coordinates" as well,  http://phn.github.com/pytpm/ might be a good starting point.

Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120503/9f528b21/attachment.html>

From erik.tollerud at gmail.com  Wed May  2 22:41:34 2012
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Wed, 2 May 2012 19:41:34 -0700
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
Message-ID: <CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>

My perspective here is that there a huge set of options for coordinate
system libraries to build from.  They are a shining example of the
vision behind astropy: there are order 10 coordinate libraries out
there that all have slightly different APIs, various parts that work a
bit better than others, and a range of different easy-of-installation
factors.  So the astropy coordinate system will not simply take one of
these and use it as the core, but rather try to build an API that can
be used as a base to connect these schemes together. My hope is that
PyAST, kapteyn, pyephem, astropysics.coords, pytpm, etc. will all
eventually sign on as affiliated packages, and provide e.g. a
"to_astropy" and "from_astropy" method, or even be re-worked to
subclass from astropy.coords base classes. Then, users can choose
whichever package is best suited to their needs, and trust that they
can always convert to astropy.coords classes, and from there, to any
of the other packages.

Of course, that still requires a sensible API... so I think we want to
focus on a user-friendly API that is properly documented first (that's
in the works - give it just a bit more time and there will be
something for review), and use all this expertise we have in the
community to make the implementation function around that API in a
readable and maintainable way.

One further note: astropy.coords cannot require external libraries
other than numpy (at least not for primary functionality). One of the
key design components of the astropy core is that this is so - that
has been discussed at length, and widely agreed on, given all the
distribution challenges involved.  But affiliated packages are free to
have whatever dependencies they want.




On Wed, May 2, 2012 at 5:44 PM, Christoph Deil
<Christoph.Deil at mpi-hd.mpg.de> wrote:
>
> On May 2, 2012, at 11:56 PM, James Turner wrote:
>
> Obviously from my point of view there is 20 years of
>
> experience in coordinate handling inside the pyast library and it
>
> would be great to leverage that some how. I assume there is a goal of
>
> only relying on numpy as the only non-pure python library so pyast
>
> would not be acceptable but you could design a system that used AST
>
> internally and switched it out at a later date when you wanted to go
>
> pure python.
>
>
> That sounds pretty sensible to me and good input for those of us
> working with co-ordinates in Python. Perhaps a year ago, I and a
> couple of other people (including Perry) separately recognized some
> important concepts for handling co-ordinates that are missing from
> FITS but that will be needed in Python software, such as combining
> mappings as I think Tim is describing. After a little discussion,
> Paul Hirst pointed me to AST, which had already incorporated the
> same ideas N years previously :-). However, there is indeed some
> reluctance to pull another C library into the equation, for multiple
> good reasons. Although there's bound to be some variation on how to
> approach things, the problems are sufficiently non-trivial that a
> working model and/or prior experience seem valuable things to have...
>
> Not sure where things stand regarding the GPL etc. though? I think
> the decision was to use BSD in AstroPy. (If you reply just to this
> question I'd suggest changing the subject.)
>
>
> I have been using the celestial module in the Kapteyn package and liked it a
> lot:
>
> http://www.astro.rug.nl/software/kapteyn/
> http://www.astro.rug.nl/software/kapteyn/celestial.html
> http://www.astro.rug.nl/software/kapteyn/celestialbackground.html
>
> kapteyn.celestial is 3500 lines of well-documented python + numpy code and
> has a BSD license.
> Some other parts of kapteyn are Cython-wrapped C-code.
>
> Probably it would be better to base astropy.coordinates on PyAST or kapteyn
> or some other package instead of starting from scratch?
> Does anyone have experience with both packages and can comment on their API
> strengths / weaknesses and performance (i.e. speed and precision)?
> (I have CC'ed the kapteyn developers in case they are not aware of this
> discussion.)
>
> One more question:
> Is it planned to also have Alt-Az to RA-Dec coordinate transformations in
> astropy?
> If we want such "observer coordinates" as well,
> ?http://phn.github.com/pytpm/?might be a good starting point.
>
> Christoph
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 
Erik Tollerud


From adrianmpw at gmail.com  Wed May  2 22:49:44 2012
From: adrianmpw at gmail.com (Adrian Price-Whelan)
Date: Wed, 2 May 2012 22:49:44 -0400
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
Message-ID: <2EC53618-4362-4992-B358-A5819CE0838E@gmail.com>

I completely agree with Erik on this one.

On May 2, 2012, at 10:41 PM, Erik Tollerud wrote:

> My perspective here is that there a huge set of options for coordinate
> system libraries to build from.  They are a shining example of the
> vision behind astropy: there are order 10 coordinate libraries out
> there that all have slightly different APIs, various parts that work a
> bit better than others, and a range of different easy-of-installation
> factors.  So the astropy coordinate system will not simply take one of
> these and use it as the core, but rather try to build an API that can
> be used as a base to connect these schemes together. My hope is that
> PyAST, kapteyn, pyephem, astropysics.coords, pytpm, etc. will all
> eventually sign on as affiliated packages, and provide e.g. a
> "to_astropy" and "from_astropy" method, or even be re-worked to
> subclass from astropy.coords base classes. Then, users can choose
> whichever package is best suited to their needs, and trust that they
> can always convert to astropy.coords classes, and from there, to any
> of the other packages.
> 
> Of course, that still requires a sensible API... so I think we want to
> focus on a user-friendly API that is properly documented first (that's
> in the works - give it just a bit more time and there will be
> something for review), and use all this expertise we have in the
> community to make the implementation function around that API in a
> readable and maintainable way.
> 
> One further note: astropy.coords cannot require external libraries
> other than numpy (at least not for primary functionality). One of the
> key design components of the astropy core is that this is so - that
> has been discussed at length, and widely agreed on, given all the
> distribution challenges involved.  But affiliated packages are free to
> have whatever dependencies they want.
> 
> 
> On Wed, May 2, 2012 at 5:44 PM, Christoph Deil
> <Christoph.Deil at mpi-hd.mpg.de> wrote:
>> 
>> On May 2, 2012, at 11:56 PM, James Turner wrote:
>> 
>> Obviously from my point of view there is 20 years of
>> 
>> experience in coordinate handling inside the pyast library and it
>> 
>> would be great to leverage that some how. I assume there is a goal of
>> 
>> only relying on numpy as the only non-pure python library so pyast
>> 
>> would not be acceptable but you could design a system that used AST
>> 
>> internally and switched it out at a later date when you wanted to go
>> 
>> pure python.
>> 
>> 
>> That sounds pretty sensible to me and good input for those of us
>> working with co-ordinates in Python. Perhaps a year ago, I and a
>> couple of other people (including Perry) separately recognized some
>> important concepts for handling co-ordinates that are missing from
>> FITS but that will be needed in Python software, such as combining
>> mappings as I think Tim is describing. After a little discussion,
>> Paul Hirst pointed me to AST, which had already incorporated the
>> same ideas N years previously :-). However, there is indeed some
>> reluctance to pull another C library into the equation, for multiple
>> good reasons. Although there's bound to be some variation on how to
>> approach things, the problems are sufficiently non-trivial that a
>> working model and/or prior experience seem valuable things to have...
>> 
>> Not sure where things stand regarding the GPL etc. though? I think
>> the decision was to use BSD in AstroPy. (If you reply just to this
>> question I'd suggest changing the subject.)
>> 
>> 
>> I have been using the celestial module in the Kapteyn package and liked it a
>> lot:
>> 
>> http://www.astro.rug.nl/software/kapteyn/
>> http://www.astro.rug.nl/software/kapteyn/celestial.html
>> http://www.astro.rug.nl/software/kapteyn/celestialbackground.html
>> 
>> kapteyn.celestial is 3500 lines of well-documented python + numpy code and
>> has a BSD license.
>> Some other parts of kapteyn are Cython-wrapped C-code.
>> 
>> Probably it would be better to base astropy.coordinates on PyAST or kapteyn
>> or some other package instead of starting from scratch?
>> Does anyone have experience with both packages and can comment on their API
>> strengths / weaknesses and performance (i.e. speed and precision)?
>> (I have CC'ed the kapteyn developers in case they are not aware of this
>> discussion.)
>> 
>> One more question:
>> Is it planned to also have Alt-Az to RA-Dec coordinate transformations in
>> astropy?
>> If we want such "observer coordinates" as well,
>>  http://phn.github.com/pytpm/ might be a good starting point.
>> 
>> Christoph
>> 
>> 
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>> 
> 
> 
> 
> -- 
> Erik Tollerud
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy

--
Adrian Price-Whelan
Department of Astronomy
Columbia University



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120502/e1e1987d/attachment.html>

From jturner at gemini.edu  Wed May  2 23:18:39 2012
From: jturner at gemini.edu (James Turner)
Date: Wed, 2 May 2012 23:18:39 -0400
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
Message-ID: <4FA1F90F.8010100@gemini.edu>

> Of course, that still requires a sensible API... so I think we want to
> focus on a user-friendly API that is properly documented first (that's

Yes, I think that is important (in addition to an API that's flexible
enough for application developers).

> One further note: astropy.coords cannot require external libraries
> other than numpy (at least not for primary functionality). One of the
> key design components of the astropy core is that this is so - that
> has been discussed at length, and widely agreed on, given all the
> distribution challenges involved.  But affiliated packages are free to
> have whatever dependencies they want.

So that's a key point but I think it still leaves the GPL issue
to address... You mention that there are many libraries, but I suspect
(without reviewing them all) that most (perhaps all) of the others
don't contain certain AST functionality that I consider quite
fundamental for the type of thing I want to do and would really like
to see tightly integrated in the Python infrastructure I use. If I sit
down, study AST and implement a Python version of the algorithm, I
will probably still be bound by the GPL (unless I'm only looking at
the manual and not the code), so am I right in thinking you wouldn't
accept that code?

Cheers,

James.


From tim.jenness at gmail.com  Wed May  2 23:58:04 2012
From: tim.jenness at gmail.com (Tim Jenness)
Date: Wed, 2 May 2012 20:58:04 -0700
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <4FA1F90F.8010100@gemini.edu>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
Message-ID: <CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>

On Wed, May 2, 2012 at 8:18 PM, James Turner <jturner at gemini.edu> wrote:
>> Of course, that still requires a sensible API... so I think we want to
>> focus on a user-friendly API that is properly documented first (that's
>
> Yes, I think that is important (in addition to an API that's flexible
> enough for application developers).
>
>> One further note: astropy.coords cannot require external libraries
>> other than numpy (at least not for primary functionality). One of the
>> key design components of the astropy core is that this is so - that
>> has been discussed at length, and widely agreed on, given all the
>> distribution challenges involved. ?But affiliated packages are free to
>> have whatever dependencies they want.
>
> So that's a key point but I think it still leaves the GPL issue
> to address... You mention that there are many libraries, but I suspect
> (without reviewing them all) that most (perhaps all) of the others

For example a modified wcslib is included in AST but the wcslib
functionality is only a minor part of the coordinate handling.

> don't contain certain AST functionality that I consider quite
> fundamental for the type of thing I want to do and would really like
> to see tightly integrated in the Python infrastructure I use. If I sit

That's important because there is a risk you end up with a lowest
common denominator API. You want an API that will stretch the
affiliates.

One part of AST worthy of study is its approach to plotting. It may
seem unrelated to world coordinates but the plotting infrastructure of
AST is very powerful. It supports a plugin system so you can provide
the code that knows how to draw lines and arcs and text but AST
handles where to put the lines and the text (essentially you tell AST
the bounds of your plot and map it to your coordinates in your
frameset). David Berry wrote a matplotlib backend and has demos of it
working

 http://dsberry.github.com/starlink/node5.html

> down, study AST and implement a Python version of the algorithm, I
> will probably still be bound by the GPL (unless I'm only looking at
> the manual and not the code), so am I right in thinking you wouldn't
> accept that code?
>

No-one has ever asked us about AST's license. It was a triumph to
allow it to be shipped with GPL when it first came out (and that was
mainly driven by Mark Calabretta's wcslib being GPL). We can
definitely try to work out how to get it changed to a looser license
(the main issue being to find out which person you have to talk to and
whether they even care) but I assume wcslib would have to change with
it.

-- 
Tim Jenness


From jturner at gemini.edu  Thu May  3 00:28:23 2012
From: jturner at gemini.edu (James Turner)
Date: Thu, 3 May 2012 00:28:23 -0400
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>	<4FA1BBB9.5050801@gemini.edu>	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
Message-ID: <4FA20967.3090604@gemini.edu>

> No-one has ever asked us about AST's license. It was a triumph to
> allow it to be shipped with GPL when it first came out (and that was
> mainly driven by Mark Calabretta's wcslib being GPL). We can
> definitely try to work out how to get it changed to a looser license
> (the main issue being to find out which person you have to talk to and
> whether they even care) but I assume wcslib would have to change with
> it.

Thanks for the info. If it were available under a BSD licence or
similar, that would make things easy :-). I had assumed the GPL
copyleft was a deliberate restriction because, for example, SLALIB
was available at one time under terms that effectively seemed to be
tightened by JAC moving Starlink to GPL (sorry if that's not quite
an accurate statement but it's how I ended up using the version
distributed with IRAF instead of the latest one).

I actually quite like the GPL -- it just becomes a pain when some
project that matters to you decides not to use it for one reason or
another.

I believe WCSLIB was changed quite recently (maybe a couple of years
ago) to LGPL, so I think that should be a non-issue now.

Cheers,

James.


From tim.jenness at gmail.com  Thu May  3 00:41:28 2012
From: tim.jenness at gmail.com (Tim Jenness)
Date: Wed, 2 May 2012 21:41:28 -0700
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <4FA20967.3090604@gemini.edu>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
	<4FA20967.3090604@gemini.edu>
Message-ID: <CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>

On Wed, May 2, 2012 at 9:28 PM, James Turner <jturner at gemini.edu> wrote:
>> No-one has ever asked us about AST's license. It was a triumph to
>> allow it to be shipped with GPL when it first came out (and that was
>> mainly driven by Mark Calabretta's wcslib being GPL). We can
>> definitely try to work out how to get it changed to a looser license
>> (the main issue being to find out which person you have to talk to and
>> whether they even care) but I assume wcslib would have to change with
>> it.
>
>
> Thanks for the info. If it were available under a BSD licence or
> similar, that would make things easy :-). I had assumed the GPL
> copyleft was a deliberate restriction because, for example, SLALIB
> was available at one time under terms that effectively seemed to be
> tightened by JAC moving Starlink to GPL (sorry if that's not quite
> an accurate statement but it's how I ended up using the version
> distributed with IRAF instead of the latest one).

At the risk of going off topic... The Starlink software used to be
distributed using the Starlink software licence which was a
restrictive non-commercial use licence that caused lots of trouble. It
was a major effort to convince everyone that we could switch over to
GPL. It's funny how this left a feeling that the software became more
restrictive as we were trying for the complete opposite. AST has
always been GPL because of WCSLIB and because Starlink were really
trying for broad adoption back in 1997.

SLA is a special case since the Fortran was Starlink licence and the C
was a private Pat Wallace licence. I recently wrote an API-compatible
version of SLA (called PAL) in C (using GPL) as a layer on top of SOFA
(which recently got into debian with a licence tweak from the most
recent SOFA release).

>
> I actually quite like the GPL -- it just becomes a pain when some
> project that matters to you decides not to use it for one reason or
> another.
>

I have no objection to change. It's all in the bureaucracy...

> I believe WCSLIB was changed quite recently (maybe a couple of years
> ago) to LGPL, so I think that should be a non-issue now.

AST doesn't link against WCSLIB. It locally modifies it and embeds it
deep in the library.

-- 
Tim Jenness


From d.berry at jach.hawaii.edu  Thu May  3 05:18:56 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Thu, 3 May 2012 10:18:56 +0100
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
	<4FA20967.3090604@gemini.edu>
	<CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>
Message-ID: <CAALafn4iBpPcwOCkrjyaRDZh119FL45xnJaWb060j533SFXxhA@mail.gmail.com>

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


From perry at stsci.edu  Thu May  3 11:24:59 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Thu, 3 May 2012 11:24:59 -0400
Subject: [AstroPy] next astropy coordination meeting
References: <4CDE33A0-C6D8-47D7-886E-1BE0EBBD6E90@stsci.edu>
Message-ID: <FDD42FE0-B5C8-461E-8921-5C25246FE202@stsci.edu>

We would like to hold the second Astropy Coordination meeting in  
October at
STScI (the first was held last October at CFA; the minutes can be  
viewed at:
https://github.com/astropy/astropy/wiki/CfAMeeting2011Minutes.)

The goal for the meeting is to coordinate software efforts in  
improving and
expanding astropy. It is planned as a two-day meeting. Currently these  
three
sets of dates are available:

Tuesday - Wednesday  Oct. 2-3
Tuesday - Wednesday  Oct. 9-10
Tuesday - Wednesday  Oct. 23-24

We'd like to know who is interested in attending the meeting and which  
dates
are acceptable. A doodle poll has been set up; only the first day of  
each
week has been given as a choice to indicate you can make the meeting  
that
week. Please fill out the poll if you are interested in attending the
meeting but can't make any of dates. The poll will be kept open for  
just over
two weeks and will close at the end of Friday, May 18.

The link to the poll is: http://www.doodle.com/auvfbs6f4iiyt9cb

Tentative topics to be addressed at the coordination meeting
(subject to revision depending on interest of attendees):

* The current state of the Astropy core package
- What subpackages need to be improved?
- What new subpackages need to be made?
- How should we phase out stand-alone versions?
* Advocacy and communication to the community
* Highest priorities for additions to astropy
  - who will be the advocate/coordinator for each?
* What existing packages should we target for making affiliated  
packages?
  - What offer will they not be able to refuse?
* Improving interoperability of affiliated packages
  - E.g., supporting standard data objects (ND-datasets, spectra...) and
    metadata conventions




From wkerzendorf at gmail.com  Thu May  3 11:39:40 2012
From: wkerzendorf at gmail.com (Wolfgang Kerzendorf)
Date: Thu, 3 May 2012 11:39:40 -0400
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CAALafn4iBpPcwOCkrjyaRDZh119FL45xnJaWb060j533SFXxhA@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
	<4FA20967.3090604@gemini.edu>
	<CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>
	<CAALafn4iBpPcwOCkrjyaRDZh119FL45xnJaWb060j533SFXxhA@mail.gmail.com>
Message-ID: <70657ED2-F351-424C-A169-1AC58F487F0F@gmail.com>

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. 

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

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



From d.berry at jach.hawaii.edu  Thu May  3 11:45:49 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Thu, 3 May 2012 16:45:49 +0100
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <70657ED2-F351-424C-A169-1AC58F487F0F@gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
	<4FA20967.3090604@gemini.edu>
	<CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>
	<CAALafn4iBpPcwOCkrjyaRDZh119FL45xnJaWb060j533SFXxhA@mail.gmail.com>
	<70657ED2-F351-424C-A169-1AC58F487F0F@gmail.com>
Message-ID: <CAALafn5Cr3OXhMnsHZ3aBERFFaZnOdzUEy5YiLNkbnaiU8Lyvg@mail.gmail.com>

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
>


From perry at stsci.edu  Thu May  3 12:45:19 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Thu, 3 May 2012 12:45:19 -0400
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CAALafn5Cr3OXhMnsHZ3aBERFFaZnOdzUEy5YiLNkbnaiU8Lyvg@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
	<4FA20967.3090604@gemini.edu>
	<CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>
	<CAALafn4iBpPcwOCkrjyaRDZh119FL45xnJaWb060j533SFXxhA@mail.gmail.com>
	<70657ED2-F351-424C-A169-1AC58F487F0F@gmail.com>
	<CAALafn5Cr3OXhMnsHZ3aBERFFaZnOdzUEy5YiLNkbnaiU8Lyvg@mail.gmail.com>
Message-ID: <8F2E78FE-83EB-41BC-9FE0-E0705939F327@stsci.edu>


On May 3, 2012, at 11:45 AM, David Berry wrote:

> 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 agree that they are both identical in some respects (and it is worth  
considering a common api for at least a good part of both). To me the  
main difference is that one is standards focused (dealing with well  
known coordinate  systems and the transformations between them,  
whereas wcs is dealing more with instrumental effects and transforming  
from that to world coordinates (which may be one of the standard  
systems, but it may not). In one most of the transforms are simple, as  
is the geometry. In the other they can be quite complex. The former  
usually transforms few distinct coordinates (yes, you can do big  
catalogs too), and the latter transforms large numbers of pixel  
coordinates in many case.

So I'm not surprised that people come from different directions when  
approaching these two issues.


Perr



From klabrie at gemini.edu  Thu May  3 13:38:41 2012
From: klabrie at gemini.edu (Kathleen Labrie)
Date: Thu, 3 May 2012 07:38:41 -1000
Subject: [AstroPy] next astropy coordination meeting
In-Reply-To: <FDD42FE0-B5C8-461E-8921-5C25246FE202@stsci.edu>
References: <4CDE33A0-C6D8-47D7-886E-1BE0EBBD6E90@stsci.edu>
	<FDD42FE0-B5C8-461E-8921-5C25246FE202@stsci.edu>
Message-ID: <3A0C7DB1-E72E-4300-8E14-28B3A74C1E10@gemini.edu>

Hi Perry,

I am a bit disappointed that there are no slots around ADASS.
For those of us who come from afar, combining trips helps
reduce the cost of travel and makes it a lot easier to participate
to efforts like astropy.

Kathleen

On May 3, 2012, at 5:24 AM, Perry Greenfield wrote:

> We would like to hold the second Astropy Coordination meeting in  
> October at
> STScI (the first was held last October at CFA; the minutes can be  
> viewed at:
> https://github.com/astropy/astropy/wiki/CfAMeeting2011Minutes.)
> 
> The goal for the meeting is to coordinate software efforts in  
> improving and
> expanding astropy. It is planned as a two-day meeting. Currently these  
> three
> sets of dates are available:
> 
> Tuesday - Wednesday  Oct. 2-3
> Tuesday - Wednesday  Oct. 9-10
> Tuesday - Wednesday  Oct. 23-24
> 
> We'd like to know who is interested in attending the meeting and which  
> dates
> are acceptable. A doodle poll has been set up; only the first day of  
> each
> week has been given as a choice to indicate you can make the meeting  
> that
> week. Please fill out the poll if you are interested in attending the
> meeting but can't make any of dates. The poll will be kept open for  
> just over
> two weeks and will close at the end of Friday, May 18.
> 
> The link to the poll is: http://www.doodle.com/auvfbs6f4iiyt9cb
> 
> Tentative topics to be addressed at the coordination meeting
> (subject to revision depending on interest of attendees):
> 
> * The current state of the Astropy core package
> - What subpackages need to be improved?
> - What new subpackages need to be made?
> - How should we phase out stand-alone versions?
> * Advocacy and communication to the community
> * Highest priorities for additions to astropy
>  - who will be the advocate/coordinator for each?
> * What existing packages should we target for making affiliated  
> packages?
>  - What offer will they not be able to refuse?
> * Improving interoperability of affiliated packages
>  - E.g., supporting standard data objects (ND-datasets, spectra...) and
>    metadata conventions
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From d.berry at jach.hawaii.edu  Thu May  3 13:39:56 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Thu, 3 May 2012 18:39:56 +0100
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <8F2E78FE-83EB-41BC-9FE0-E0705939F327@stsci.edu>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
	<4FA20967.3090604@gemini.edu>
	<CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>
	<CAALafn4iBpPcwOCkrjyaRDZh119FL45xnJaWb060j533SFXxhA@mail.gmail.com>
	<70657ED2-F351-424C-A169-1AC58F487F0F@gmail.com>
	<CAALafn5Cr3OXhMnsHZ3aBERFFaZnOdzUEy5YiLNkbnaiU8Lyvg@mail.gmail.com>
	<8F2E78FE-83EB-41BC-9FE0-E0705939F327@stsci.edu>
Message-ID: <CAALafn6DyMC4rFCczUZ7gGaEz05w=OBB==2b9PbWD3WEH+Tv=Q@mail.gmail.com>

What you say is reasonable, but I don't see that it follows that they need
to be handled differently. Considered as a class, coordinate systems have a
lot of common properties and methods no matter what they describe. Getting
a sufficiently generic base class allows you to extend the system easily.
That's why it was so easy to add support for spectral and time to AST. In
practice it all works out very smoothly.

David

On Thursday, 3 May 2012, Perry Greenfield <perry at stsci.edu> wrote:
>
> On May 3, 2012, at 11:45 AM, David Berry wrote:
>
>> 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 agree that they are both identical in some respects (and it is worth
considering a common api for at least a good part of both). To me the main
difference is that one is standards focused (dealing with well known
coordinate  systems and the transformations between them, whereas wcs is
dealing more with instrumental effects and transforming from that to world
coordinates (which may be one of the standard systems, but it may not). In
one most of the transforms are simple, as is the geometry. In the other
they can be quite complex. The former usually transforms few distinct
coordinates (yes, you can do big catalogs too), and the latter transforms
large numbers of pixel coordinates in many case.
>
> So I'm not surprised that people come from different directions when
approaching these two issues.
>
>
> Perr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120503/00e409a4/attachment.html>

From perry at stsci.edu  Thu May  3 14:08:42 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Thu, 3 May 2012 14:08:42 -0400
Subject: [AstroPy] next astropy coordination meeting
In-Reply-To: <3A0C7DB1-E72E-4300-8E14-28B3A74C1E10@gemini.edu>
References: <4CDE33A0-C6D8-47D7-886E-1BE0EBBD6E90@stsci.edu>
	<FDD42FE0-B5C8-461E-8921-5C25246FE202@stsci.edu>
	<3A0C7DB1-E72E-4300-8E14-28B3A74C1E10@gemini.edu>
Message-ID: <5987DA61-C709-40E3-B515-D42D0D8C7F5D@stsci.edu>

Are there many others that would attend if it were near adass? Let me  
know.

On May 3, 2012, at 1:38 PM, Kathleen Labrie wrote:

> Hi Perry,
>
> I am a bit disappointed that there are no slots around ADASS.
> For those of us who come from afar, combining trips helps
> reduce the cost of travel and makes it a lot easier to participate
> to efforts like astropy.
>
> Kathleen
>
> On May 3, 2012, at 5:24 AM, Perry Greenfield wrote:
>
>> We would like to hold the second Astropy Coordination meeting in
>> October at
>> STScI (the first was held last October at CFA; the minutes can be
>> viewed at:
>> https://github.com/astropy/astropy/wiki/CfAMeeting2011Minutes.)
>>
>> The goal for the meeting is to coordinate software efforts in
>> improving and
>> expanding astropy. It is planned as a two-day meeting. Currently  
>> these
>> three
>> sets of dates are available:
>>
>> Tuesday - Wednesday  Oct. 2-3
>> Tuesday - Wednesday  Oct. 9-10
>> Tuesday - Wednesday  Oct. 23-24
>>
>> We'd like to know who is interested in attending the meeting and  
>> which
>> dates
>> are acceptable. A doodle poll has been set up; only the first day of
>> each
>> week has been given as a choice to indicate you can make the meeting
>> that
>> week. Please fill out the poll if you are interested in attending the
>> meeting but can't make any of dates. The poll will be kept open for
>> just over
>> two weeks and will close at the end of Friday, May 18.
>>
>> The link to the poll is: http://www.doodle.com/auvfbs6f4iiyt9cb
>>
>> Tentative topics to be addressed at the coordination meeting
>> (subject to revision depending on interest of attendees):
>>
>> * The current state of the Astropy core package
>> - What subpackages need to be improved?
>> - What new subpackages need to be made?
>> - How should we phase out stand-alone versions?
>> * Advocacy and communication to the community
>> * Highest priorities for additions to astropy
>> - who will be the advocate/coordinator for each?
>> * What existing packages should we target for making affiliated
>> packages?
>> - What offer will they not be able to refuse?
>> * Improving interoperability of affiliated packages
>> - E.g., supporting standard data objects (ND-datasets, spectra...)  
>> and
>>   metadata conventions
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>



From adrianmpw at gmail.com  Thu May  3 14:13:50 2012
From: adrianmpw at gmail.com (Adrian Price-Whelan)
Date: Thu, 3 May 2012 14:13:50 -0400
Subject: [AstroPy] next astropy coordination meeting
In-Reply-To: <5987DA61-C709-40E3-B515-D42D0D8C7F5D@stsci.edu>
References: <4CDE33A0-C6D8-47D7-886E-1BE0EBBD6E90@stsci.edu>
	<FDD42FE0-B5C8-461E-8921-5C25246FE202@stsci.edu>
	<3A0C7DB1-E72E-4300-8E14-28B3A74C1E10@gemini.edu>
	<5987DA61-C709-40E3-B515-D42D0D8C7F5D@stsci.edu>
Message-ID: <BE4D8DFB-C0AB-4C56-B1F6-B61D8480F911@gmail.com>

In time or space?

I could do it at STSCI if it were in November, but probably couldn't make it
to Illinois.

Thanks,
- Adrian

On May 3, 2012, at 2:08 PM, Perry Greenfield wrote:

> Are there many others that would attend if it were near adass? Let me  
> know.
> 
> On May 3, 2012, at 1:38 PM, Kathleen Labrie wrote:
> 
>> Hi Perry,
>> 
>> I am a bit disappointed that there are no slots around ADASS.
>> For those of us who come from afar, combining trips helps
>> reduce the cost of travel and makes it a lot easier to participate
>> to efforts like astropy.
>> 
>> Kathleen
>> 
>> On May 3, 2012, at 5:24 AM, Perry Greenfield wrote:
>> 
>>> We would like to hold the second Astropy Coordination meeting in
>>> October at
>>> STScI (the first was held last October at CFA; the minutes can be
>>> viewed at:
>>> https://github.com/astropy/astropy/wiki/CfAMeeting2011Minutes.)
>>> 
>>> The goal for the meeting is to coordinate software efforts in
>>> improving and
>>> expanding astropy. It is planned as a two-day meeting. Currently  
>>> these
>>> three
>>> sets of dates are available:
>>> 
>>> Tuesday - Wednesday  Oct. 2-3
>>> Tuesday - Wednesday  Oct. 9-10
>>> Tuesday - Wednesday  Oct. 23-24
>>> 
>>> We'd like to know who is interested in attending the meeting and  
>>> which
>>> dates
>>> are acceptable. A doodle poll has been set up; only the first day of
>>> each
>>> week has been given as a choice to indicate you can make the meeting
>>> that
>>> week. Please fill out the poll if you are interested in attending the
>>> meeting but can't make any of dates. The poll will be kept open for
>>> just over
>>> two weeks and will close at the end of Friday, May 18.
>>> 
>>> The link to the poll is: http://www.doodle.com/auvfbs6f4iiyt9cb
>>> 
>>> Tentative topics to be addressed at the coordination meeting
>>> (subject to revision depending on interest of attendees):
>>> 
>>> * The current state of the Astropy core package
>>> - What subpackages need to be improved?
>>> - What new subpackages need to be made?
>>> - How should we phase out stand-alone versions?
>>> * Advocacy and communication to the community
>>> * Highest priorities for additions to astropy
>>> - who will be the advocate/coordinator for each?
>>> * What existing packages should we target for making affiliated
>>> packages?
>>> - What offer will they not be able to refuse?
>>> * Improving interoperability of affiliated packages
>>> - E.g., supporting standard data objects (ND-datasets, spectra...)  
>>> and
>>>  metadata conventions
>>> 
>>> 
>>> _______________________________________________
>>> 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

--
Adrian Price-Whelan
Department of Astronomy
Columbia University



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120503/ac7728a5/attachment.html>

From klabrie at gemini.edu  Thu May  3 14:18:22 2012
From: klabrie at gemini.edu (Kathleen Labrie)
Date: Thu, 3 May 2012 08:18:22 -1000
Subject: [AstroPy] next astropy coordination meeting
In-Reply-To: <BE4D8DFB-C0AB-4C56-B1F6-B61D8480F911@gmail.com>
References: <4CDE33A0-C6D8-47D7-886E-1BE0EBBD6E90@stsci.edu>
	<FDD42FE0-B5C8-461E-8921-5C25246FE202@stsci.edu>
	<3A0C7DB1-E72E-4300-8E14-28B3A74C1E10@gemini.edu>
	<5987DA61-C709-40E3-B515-D42D0D8C7F5D@stsci.edu>
	<BE4D8DFB-C0AB-4C56-B1F6-B61D8480F911@gmail.com>
Message-ID: <EB20DB15-3706-491B-9E8A-56A96E8B5637@gemini.edu>

Personally, I was talking in time.  Like the week before or after ADASS.
Coming from Hawaii, once I'm on the mainland, it's a lot easier to hop around.

Kathleen

On May 3, 2012, at 8:13 AM, Adrian Price-Whelan wrote:

> In time or space?
> 
> I could do it at STSCI if it were in November, but probably couldn't make it
> to Illinois.
> 
> Thanks,
> - Adrian
> 
> On May 3, 2012, at 2:08 PM, Perry Greenfield wrote:
> 
>> Are there many others that would attend if it were near adass? Let me  
>> know.
>> 
>> On May 3, 2012, at 1:38 PM, Kathleen Labrie wrote:
>> 
>>> Hi Perry,
>>> 
>>> I am a bit disappointed that there are no slots around ADASS.
>>> For those of us who come from afar, combining trips helps
>>> reduce the cost of travel and makes it a lot easier to participate
>>> to efforts like astropy.
>>> 
>>> Kathleen
>>> 
>>> On May 3, 2012, at 5:24 AM, Perry Greenfield wrote:
>>> 
>>>> We would like to hold the second Astropy Coordination meeting in
>>>> October at
>>>> STScI (the first was held last October at CFA; the minutes can be
>>>> viewed at:
>>>> https://github.com/astropy/astropy/wiki/CfAMeeting2011Minutes.)
>>>> 
>>>> The goal for the meeting is to coordinate software efforts in
>>>> improving and
>>>> expanding astropy. It is planned as a two-day meeting. Currently  
>>>> these
>>>> three
>>>> sets of dates are available:
>>>> 
>>>> Tuesday - Wednesday  Oct. 2-3
>>>> Tuesday - Wednesday  Oct. 9-10
>>>> Tuesday - Wednesday  Oct. 23-24
>>>> 
>>>> We'd like to know who is interested in attending the meeting and  
>>>> which
>>>> dates
>>>> are acceptable. A doodle poll has been set up; only the first day of
>>>> each
>>>> week has been given as a choice to indicate you can make the meeting
>>>> that
>>>> week. Please fill out the poll if you are interested in attending the
>>>> meeting but can't make any of dates. The poll will be kept open for
>>>> just over
>>>> two weeks and will close at the end of Friday, May 18.
>>>> 
>>>> The link to the poll is: http://www.doodle.com/auvfbs6f4iiyt9cb
>>>> 
>>>> Tentative topics to be addressed at the coordination meeting
>>>> (subject to revision depending on interest of attendees):
>>>> 
>>>> * The current state of the Astropy core package
>>>> - What subpackages need to be improved?
>>>> - What new subpackages need to be made?
>>>> - How should we phase out stand-alone versions?
>>>> * Advocacy and communication to the community
>>>> * Highest priorities for additions to astropy
>>>> - who will be the advocate/coordinator for each?
>>>> * What existing packages should we target for making affiliated
>>>> packages?
>>>> - What offer will they not be able to refuse?
>>>> * Improving interoperability of affiliated packages
>>>> - E.g., supporting standard data objects (ND-datasets, spectra...)  
>>>> and
>>>>  metadata conventions
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
> 
> --
> Adrian Price-Whelan
> Department of Astronomy
> Columbia University
> 
> 
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120503/82059d68/attachment.html>

From perry at stsci.edu  Thu May  3 14:19:19 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Thu, 3 May 2012 14:19:19 -0400
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CAALafn6DyMC4rFCczUZ7gGaEz05w=OBB==2b9PbWD3WEH+Tv=Q@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
	<4FA20967.3090604@gemini.edu>
	<CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>
	<CAALafn4iBpPcwOCkrjyaRDZh119FL45xnJaWb060j533SFXxhA@mail.gmail.com>
	<70657ED2-F351-424C-A169-1AC58F487F0F@gmail.com>
	<CAALafn5Cr3OXhMnsHZ3aBERFFaZnOdzUEy5YiLNkbnaiU8Lyvg@mail.gmail.com>
	<8F2E78FE-83EB-41BC-9FE0-E0705939F327@stsci.edu>
	<CAALafn6DyMC4rFCczUZ7gGaEz05w=OBB==2b9PbWD3WEH+Tv=Q@mail.gmail.com>
Message-ID: <FEC2AE19-F53E-4033-B822-2D579C2BC405@stsci.edu>

I didn't mean to say that it should be mostly or entirely different. I  
would like to see  a great deal of commonality actually (preferably  
sharing the same base class for coordinate transformations for example).

I'd like to expand on what I would like to see, but I'm not sure I  
will have time today. Perhaps tomorrow.

Perry

On May 3, 2012, at 1:39 PM, David Berry wrote:

> What you say is reasonable, but I don't see that it follows that  
> they need to be handled differently. Considered as a class,  
> coordinate systems have a lot of common properties and methods no  
> matter what they describe. Getting a sufficiently generic base class  
> allows you to extend the system easily. That's why it was so easy to  
> add support for spectral and time to AST. In practice it all works  
> out very smoothly.
>
> David
>
> On Thursday, 3 May 2012, Perry Greenfield <perry at stsci.edu> wrote:
> >
> > On May 3, 2012, at 11:45 AM, David Berry wrote:
> >
> >> 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 agree that they are both identical in some respects (and it is  
> worth considering a common api for at least a good part of both). To  
> me the main difference is that one is standards focused (dealing  
> with well known coordinate  systems and the transformations between  
> them, whereas wcs is dealing more with instrumental effects and  
> transforming from that to world coordinates (which may be one of the  
> standard systems, but it may not). In one most of the transforms are  
> simple, as is the geometry. In the other they can be quite complex.  
> The former usually transforms few distinct coordinates (yes, you can  
> do big catalogs too), and the latter transforms large numbers of  
> pixel coordinates in many case.
> >
> > So I'm not surprised that people come from different directions  
> when approaching these two issues.
> >
> >
> > Perr
> >
> >



From perry at stsci.edu  Thu May  3 14:20:08 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Thu, 3 May 2012 14:20:08 -0400
Subject: [AstroPy] next astropy coordination meeting
In-Reply-To: <EB20DB15-3706-491B-9E8A-56A96E8B5637@gemini.edu>
References: <4CDE33A0-C6D8-47D7-886E-1BE0EBBD6E90@stsci.edu>
	<FDD42FE0-B5C8-461E-8921-5C25246FE202@stsci.edu>
	<3A0C7DB1-E72E-4300-8E14-28B3A74C1E10@gemini.edu>
	<5987DA61-C709-40E3-B515-D42D0D8C7F5D@stsci.edu>
	<BE4D8DFB-C0AB-4C56-B1F6-B61D8480F911@gmail.com>
	<EB20DB15-3706-491B-9E8A-56A96E8B5637@gemini.edu>
Message-ID: <D8003508-8606-4FC0-BB5F-459ED616A041@stsci.edu>

I meant time as well. It will be here (STScI) regardless.

On May 3, 2012, at 2:18 PM, Kathleen Labrie wrote:

> Personally, I was talking in time.  Like the week before or after  
> ADASS.
> Coming from Hawaii, once I'm on the mainland, it's a lot easier to  
> hop around.
>
> Kathleen
>
> On May 3, 2012, at 8:13 AM, Adrian Price-Whelan wrote:
>
>> In time or space?
>>
>> I could do it at STSCI if it were in November, but probably  
>> couldn't make it
>> to Illinois.
>>
>> Thanks,
>> - Adrian
>>
>> On May 3, 2012, at 2:08 PM, Perry Greenfield wrote:
>>
>>> Are there many others that would attend if it were near adass? Let  
>>> me
>>> know.
>>>
>>> On May 3, 2012, at 1:38 PM, Kathleen Labrie wrote:
>>>
>>>> Hi Perry,
>>>>
>>>> I am a bit disappointed that there are no slots around ADASS.
>>>> For those of us who come from afar, combining trips helps
>>>> reduce the cost of travel and makes it a lot easier to participate
>>>> to efforts like astropy.
>>>>
>>>> Kathleen
>>>>
>>>> On May 3, 2012, at 5:24 AM, Perry Greenfield wrote:
>>>>
>>>>> We would like to hold the second Astropy Coordination meeting in
>>>>> October at
>>>>> STScI (the first was held last October at CFA; the minutes can be
>>>>> viewed at:
>>>>> https://github.com/astropy/astropy/wiki/CfAMeeting2011Minutes.)
>>>>>
>>>>> The goal for the meeting is to coordinate software efforts in
>>>>> improving and
>>>>> expanding astropy. It is planned as a two-day meeting. Currently
>>>>> these
>>>>> three
>>>>> sets of dates are available:
>>>>>
>>>>> Tuesday - Wednesday  Oct. 2-3
>>>>> Tuesday - Wednesday  Oct. 9-10
>>>>> Tuesday - Wednesday  Oct. 23-24
>>>>>
>>>>> We'd like to know who is interested in attending the meeting and
>>>>> which
>>>>> dates
>>>>> are acceptable. A doodle poll has been set up; only the first  
>>>>> day of
>>>>> each
>>>>> week has been given as a choice to indicate you can make the  
>>>>> meeting
>>>>> that
>>>>> week. Please fill out the poll if you are interested in  
>>>>> attending the
>>>>> meeting but can't make any of dates. The poll will be kept open  
>>>>> for
>>>>> just over
>>>>> two weeks and will close at the end of Friday, May 18.
>>>>>
>>>>> The link to the poll is: http://www.doodle.com/auvfbs6f4iiyt9cb
>>>>>
>>>>> Tentative topics to be addressed at the coordination meeting
>>>>> (subject to revision depending on interest of attendees):
>>>>>
>>>>> * The current state of the Astropy core package
>>>>> - What subpackages need to be improved?
>>>>> - What new subpackages need to be made?
>>>>> - How should we phase out stand-alone versions?
>>>>> * Advocacy and communication to the community
>>>>> * Highest priorities for additions to astropy
>>>>> - who will be the advocate/coordinator for each?
>>>>> * What existing packages should we target for making affiliated
>>>>> packages?
>>>>> - What offer will they not be able to refuse?
>>>>> * Improving interoperability of affiliated packages
>>>>> - E.g., supporting standard data objects (ND-datasets, spectra...)
>>>>> and
>>>>>  metadata conventions
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>> --
>> Adrian Price-Whelan
>> Department of Astronomy
>> Columbia University
>>
>>
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>



From aldcroft at head.cfa.harvard.edu  Thu May  3 14:21:42 2012
From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft)
Date: Thu, 3 May 2012 14:21:42 -0400
Subject: [AstroPy] next astropy coordination meeting
In-Reply-To: <D8003508-8606-4FC0-BB5F-459ED616A041@stsci.edu>
References: <4CDE33A0-C6D8-47D7-886E-1BE0EBBD6E90@stsci.edu>
	<FDD42FE0-B5C8-461E-8921-5C25246FE202@stsci.edu>
	<3A0C7DB1-E72E-4300-8E14-28B3A74C1E10@gemini.edu>
	<5987DA61-C709-40E3-B515-D42D0D8C7F5D@stsci.edu>
	<BE4D8DFB-C0AB-4C56-B1F6-B61D8480F911@gmail.com>
	<EB20DB15-3706-491B-9E8A-56A96E8B5637@gemini.edu>
	<D8003508-8606-4FC0-BB5F-459ED616A041@stsci.edu>
Message-ID: <CAGsQ-NvM9jJoTOaRvguZOdGG+ng9+z2m+h52NYcWcHbXRiLYAQ@mail.gmail.com>

I'm on travel Oct 28 - Nov 11, so time alignment with ADASS would be bad for me.

- Tom

On Thu, May 3, 2012 at 2:20 PM, Perry Greenfield <perry at stsci.edu> wrote:
> I meant time as well. It will be here (STScI) regardless.
>
> On May 3, 2012, at 2:18 PM, Kathleen Labrie wrote:
>
>> Personally, I was talking in time. ?Like the week before or after
>> ADASS.
>> Coming from Hawaii, once I'm on the mainland, it's a lot easier to
>> hop around.
>>
>> Kathleen
>>
>> On May 3, 2012, at 8:13 AM, Adrian Price-Whelan wrote:
>>
>>> In time or space?
>>>
>>> I could do it at STSCI if it were in November, but probably
>>> couldn't make it
>>> to Illinois.
>>>
>>> Thanks,
>>> - Adrian
>>>
>>> On May 3, 2012, at 2:08 PM, Perry Greenfield wrote:
>>>
>>>> Are there many others that would attend if it were near adass? Let
>>>> me
>>>> know.
>>>>
>>>> On May 3, 2012, at 1:38 PM, Kathleen Labrie wrote:
>>>>
>>>>> Hi Perry,
>>>>>
>>>>> I am a bit disappointed that there are no slots around ADASS.
>>>>> For those of us who come from afar, combining trips helps
>>>>> reduce the cost of travel and makes it a lot easier to participate
>>>>> to efforts like astropy.
>>>>>
>>>>> Kathleen
>>>>>
>>>>> On May 3, 2012, at 5:24 AM, Perry Greenfield wrote:
>>>>>
>>>>>> We would like to hold the second Astropy Coordination meeting in
>>>>>> October at
>>>>>> STScI (the first was held last October at CFA; the minutes can be
>>>>>> viewed at:
>>>>>> https://github.com/astropy/astropy/wiki/CfAMeeting2011Minutes.)
>>>>>>
>>>>>> The goal for the meeting is to coordinate software efforts in
>>>>>> improving and
>>>>>> expanding astropy. It is planned as a two-day meeting. Currently
>>>>>> these
>>>>>> three
>>>>>> sets of dates are available:
>>>>>>
>>>>>> Tuesday - Wednesday ?Oct. 2-3
>>>>>> Tuesday - Wednesday ?Oct. 9-10
>>>>>> Tuesday - Wednesday ?Oct. 23-24
>>>>>>
>>>>>> We'd like to know who is interested in attending the meeting and
>>>>>> which
>>>>>> dates
>>>>>> are acceptable. A doodle poll has been set up; only the first
>>>>>> day of
>>>>>> each
>>>>>> week has been given as a choice to indicate you can make the
>>>>>> meeting
>>>>>> that
>>>>>> week. Please fill out the poll if you are interested in
>>>>>> attending the
>>>>>> meeting but can't make any of dates. The poll will be kept open
>>>>>> for
>>>>>> just over
>>>>>> two weeks and will close at the end of Friday, May 18.
>>>>>>
>>>>>> The link to the poll is: http://www.doodle.com/auvfbs6f4iiyt9cb
>>>>>>
>>>>>> Tentative topics to be addressed at the coordination meeting
>>>>>> (subject to revision depending on interest of attendees):
>>>>>>
>>>>>> * The current state of the Astropy core package
>>>>>> - What subpackages need to be improved?
>>>>>> - What new subpackages need to be made?
>>>>>> - How should we phase out stand-alone versions?
>>>>>> * Advocacy and communication to the community
>>>>>> * Highest priorities for additions to astropy
>>>>>> - who will be the advocate/coordinator for each?
>>>>>> * What existing packages should we target for making affiliated
>>>>>> packages?
>>>>>> - What offer will they not be able to refuse?
>>>>>> * Improving interoperability of affiliated packages
>>>>>> - E.g., supporting standard data objects (ND-datasets, spectra...)
>>>>>> and
>>>>>> ?metadata conventions
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>> --
>>> Adrian Price-Whelan
>>> Department of Astronomy
>>> Columbia University
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>


From klabrie at gemini.edu  Thu May  3 14:26:24 2012
From: klabrie at gemini.edu (Kathleen Labrie)
Date: Thu, 3 May 2012 08:26:24 -1000
Subject: [AstroPy] next astropy coordination meeting
In-Reply-To: <CAGsQ-NvM9jJoTOaRvguZOdGG+ng9+z2m+h52NYcWcHbXRiLYAQ@mail.gmail.com>
References: <4CDE33A0-C6D8-47D7-886E-1BE0EBBD6E90@stsci.edu>
	<FDD42FE0-B5C8-461E-8921-5C25246FE202@stsci.edu>
	<3A0C7DB1-E72E-4300-8E14-28B3A74C1E10@gemini.edu>
	<5987DA61-C709-40E3-B515-D42D0D8C7F5D@stsci.edu>
	<BE4D8DFB-C0AB-4C56-B1F6-B61D8480F911@gmail.com>
	<EB20DB15-3706-491B-9E8A-56A96E8B5637@gemini.edu>
	<D8003508-8606-4FC0-BB5F-459ED616A041@stsci.edu>
	<CAGsQ-NvM9jJoTOaRvguZOdGG+ng9+z2m+h52NYcWcHbXRiLYAQ@mail.gmail.com>
Message-ID: <0BB1D63E-805E-46EC-8509-39DFC9B98D3C@gemini.edu>

Alright then.  It was just a thought.   Tom's presence is probably a lot more
important than mine.   :)

Kathleen

On May 3, 2012, at 8:21 AM, Tom Aldcroft wrote:

> I'm on travel Oct 28 - Nov 11, so time alignment with ADASS would be bad for me.
> 
> - Tom
> 
> On Thu, May 3, 2012 at 2:20 PM, Perry Greenfield <perry at stsci.edu> wrote:
>> I meant time as well. It will be here (STScI) regardless.
>> 
>> On May 3, 2012, at 2:18 PM, Kathleen Labrie wrote:
>> 
>>> Personally, I was talking in time.  Like the week before or after
>>> ADASS.
>>> Coming from Hawaii, once I'm on the mainland, it's a lot easier to
>>> hop around.
>>> 
>>> Kathleen
>>> 
>>> On May 3, 2012, at 8:13 AM, Adrian Price-Whelan wrote:
>>> 
>>>> In time or space?
>>>> 
>>>> I could do it at STSCI if it were in November, but probably
>>>> couldn't make it
>>>> to Illinois.
>>>> 
>>>> Thanks,
>>>> - Adrian
>>>> 
>>>> On May 3, 2012, at 2:08 PM, Perry Greenfield wrote:
>>>> 
>>>>> Are there many others that would attend if it were near adass? Let
>>>>> me
>>>>> know.
>>>>> 
>>>>> On May 3, 2012, at 1:38 PM, Kathleen Labrie wrote:
>>>>> 
>>>>>> Hi Perry,
>>>>>> 
>>>>>> I am a bit disappointed that there are no slots around ADASS.
>>>>>> For those of us who come from afar, combining trips helps
>>>>>> reduce the cost of travel and makes it a lot easier to participate
>>>>>> to efforts like astropy.
>>>>>> 
>>>>>> Kathleen
>>>>>> 
>>>>>> On May 3, 2012, at 5:24 AM, Perry Greenfield wrote:
>>>>>> 
>>>>>>> We would like to hold the second Astropy Coordination meeting in
>>>>>>> October at
>>>>>>> STScI (the first was held last October at CFA; the minutes can be
>>>>>>> viewed at:
>>>>>>> https://github.com/astropy/astropy/wiki/CfAMeeting2011Minutes.)
>>>>>>> 
>>>>>>> The goal for the meeting is to coordinate software efforts in
>>>>>>> improving and
>>>>>>> expanding astropy. It is planned as a two-day meeting. Currently
>>>>>>> these
>>>>>>> three
>>>>>>> sets of dates are available:
>>>>>>> 
>>>>>>> Tuesday - Wednesday  Oct. 2-3
>>>>>>> Tuesday - Wednesday  Oct. 9-10
>>>>>>> Tuesday - Wednesday  Oct. 23-24
>>>>>>> 
>>>>>>> We'd like to know who is interested in attending the meeting and
>>>>>>> which
>>>>>>> dates
>>>>>>> are acceptable. A doodle poll has been set up; only the first
>>>>>>> day of
>>>>>>> each
>>>>>>> week has been given as a choice to indicate you can make the
>>>>>>> meeting
>>>>>>> that
>>>>>>> week. Please fill out the poll if you are interested in
>>>>>>> attending the
>>>>>>> meeting but can't make any of dates. The poll will be kept open
>>>>>>> for
>>>>>>> just over
>>>>>>> two weeks and will close at the end of Friday, May 18.
>>>>>>> 
>>>>>>> The link to the poll is: http://www.doodle.com/auvfbs6f4iiyt9cb
>>>>>>> 
>>>>>>> Tentative topics to be addressed at the coordination meeting
>>>>>>> (subject to revision depending on interest of attendees):
>>>>>>> 
>>>>>>> * The current state of the Astropy core package
>>>>>>> - What subpackages need to be improved?
>>>>>>> - What new subpackages need to be made?
>>>>>>> - How should we phase out stand-alone versions?
>>>>>>> * Advocacy and communication to the community
>>>>>>> * Highest priorities for additions to astropy
>>>>>>> - who will be the advocate/coordinator for each?
>>>>>>> * What existing packages should we target for making affiliated
>>>>>>> packages?
>>>>>>> - What offer will they not be able to refuse?
>>>>>>> * Improving interoperability of affiliated packages
>>>>>>> - E.g., supporting standard data objects (ND-datasets, spectra...)
>>>>>>> and
>>>>>>>  metadata conventions
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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
>>>> 
>>>> --
>>>> Adrian Price-Whelan
>>>> Department of Astronomy
>>>> Columbia University
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
>> 



From d.berry at jach.hawaii.edu  Thu May  3 14:44:34 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Thu, 3 May 2012 19:44:34 +0100
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <FEC2AE19-F53E-4033-B822-2D579C2BC405@stsci.edu>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
	<4FA20967.3090604@gemini.edu>
	<CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>
	<CAALafn4iBpPcwOCkrjyaRDZh119FL45xnJaWb060j533SFXxhA@mail.gmail.com>
	<70657ED2-F351-424C-A169-1AC58F487F0F@gmail.com>
	<CAALafn5Cr3OXhMnsHZ3aBERFFaZnOdzUEy5YiLNkbnaiU8Lyvg@mail.gmail.com>
	<8F2E78FE-83EB-41BC-9FE0-E0705939F327@stsci.edu>
	<CAALafn6DyMC4rFCczUZ7gGaEz05w=OBB==2b9PbWD3WEH+Tv=Q@mail.gmail.com>
	<FEC2AE19-F53E-4033-B822-2D579C2BC405@stsci.edu>
Message-ID: <CAALafn4vEXDrnyBMPpgha6A=v1CtG8eQk37fnOC28CcOhvQsuQ@mail.gmail.com>

For illustration I've attached the AST class hierarchy. There are a
few idiosyncrasies, like "why does Frame inherits from Mapping?", and
"what on earth is a "NormMap"?", but it should give a general feel for
the facilities.

David



On 3 May 2012 19:19, Perry Greenfield <perry at stsci.edu> wrote:
> I didn't mean to say that it should be mostly or entirely different. I would
> like to see ?a great deal of commonality actually (preferably sharing the
> same base class for coordinate transformations for example).
>
> I'd like to expand on what I would like to see, but I'm not sure I will have
> time today. Perhaps tomorrow.
>
> Perry
>
>
> On May 3, 2012, at 1:39 PM, David Berry wrote:
>
>> What you say is reasonable, but I don't see that it follows that they need
>> to be handled differently. Considered as a class, coordinate systems have a
>> lot of common properties and methods no matter what they describe. Getting a
>> sufficiently generic base class allows you to extend the system easily.
>> That's why it was so easy to add support for spectral and time to AST. In
>> practice it all works out very smoothly.
>>
>> David
>>
>> On Thursday, 3 May 2012, Perry Greenfield <perry at stsci.edu> wrote:
>> >
>> > On May 3, 2012, at 11:45 AM, David Berry wrote:
>> >
>> >> 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 agree that they are both identical in some respects (and it is worth
>> > considering a common api for at least a good part of both). To me the main
>> > difference is that one is standards focused (dealing with well known
>> > coordinate ?systems and the transformations between them, whereas wcs is
>> > dealing more with instrumental effects and transforming from that to world
>> > coordinates (which may be one of the standard systems, but it may not). In
>> > one most of the transforms are simple, as is the geometry. In the other they
>> > can be quite complex. The former usually transforms few distinct coordinates
>> > (yes, you can do big catalogs too), and the latter transforms large numbers
>> > of pixel coordinates in many case.
>> >
>> > So I'm not surprised that people come from different directions when
>> > approaching these two issues.
>> >
>> >
>> > Perr
>> >
>> >
>
>
-------------- next part --------------
Object             - Base class for all AST Objects
   Axis            - Store axis information
      SkyAxis      - Store celestial axis information
   Channel         - Basic (textual) I/O channel
      FitsChan     - I/O Channel using FITS header cards
      XmlChan      - I/O Channel using XML
      StcsChan     - I/O Channel using IVOA STC-S descriptions
   KeyMap          - Store a set of key/value pairs
      Table        - Store a 2-dimensional table of values
   Mapping         - Inter-relate two coordinate systems
      CmpMap       - Compound Mapping
      DssMap       - Map points using Digitised Sky Survey plate solution
      Frame        - Coordinate system description
         CmpFrame  - Compound Frame
            SpecFluxFrame - Observed value versus spectral position
         FluxFrame - Observed value at a given fixed spectral position
         FrameSet  - Set of inter-related coordinate systems
            Plot   - Provide facilities for graphical output
         Region    - Specify areas within a coordinate system
            Box    - A box region with sides parallel to the axes of a Frame
            Circle - A circular or spherical region within a Frame
            CmpRegion  - A combination of two regions within a single Frame
            Ellipse    - An elliptical region within a 2-dimensional Frame
            Interval   - Intervals on one or more axes of a Frame.
            NullRegion - A boundless region within a Frame
            PointList  - A collection of points in a Frame
            Polygon    - A polygonal region within a 2-dimensional Frame
            Prism  - An extrusion of a Region into orthogonal dimensions
            Stc    - Represents an generic instance of an IVOA STC-X description
               StcResourceProfile - Represents an an IVOA STC-X ResourceProfile
               StcSearchLocation  - Represents an an IVOA STC-X SearchLocation
               StcCatalogEntryLocation - Represents an an IVOA STC-X CatalogEntryLocation
               StcObsDataLocation - Represents an an IVOA STC-X ObsDataLocation
         SkyFrame  - Celestial coordinate system description
         SpecFrame - Spectral coordinate system description
            DSBSpecFrame - Dual sideband spectral coordinate system description
         TimeFrame - Time coordinate system description
      GrismMap     - Models the spectral dispersion produced by a grism
      IntraMap     - Map points using a private transformation function
      LutMap       - Transform 1-dimensional coordinates using a lookup table
      MathMap      - Transform coordinates using mathematical expressions
      MatrixMap    - Map positions by multiplying them by a matrix
      NormMap      - Normalise coordinates using a supplied Frame
      PcdMap       - Apply 2-dimensional pincushion/barrel distortion
      PermMap      - Coordinate permutation Mapping
      PolyMap      - General N-dimensional polynomial Mapping
      RateMap      - Calculates an element of a Mapping's Jacobian matrix
      SelectorMap  - Locates positions within a set of Regions
      ShiftMap     - Shifts each axis by a constant amount
      SlaMap       - Sequence of celestial coordinate conversions
      SpecMap      - Sequence of spectral coordinate conversions
      SphMap       - Map 3-d Cartesian to 2-d spherical coordinates
      SwitchMap    - Encapuslates a set of alternate Mappings
      TimeMap      - Sequence of time coordinate conversions
      TranMap      - Combine fwd. and inv. transformations from two Mappings
      UnitMap      - Unit (null) Mapping
      WcsMap       - Implement a FITS-WCS sky projection
      WinMap       - Match windows by scaling and shifting each axis
      ZoomMap      - Zoom coordinates about the origin

From wkerzendorf at gmail.com  Thu May  3 14:53:13 2012
From: wkerzendorf at gmail.com (Wolfgang Kerzendorf)
Date: Thu, 3 May 2012 14:53:13 -0400
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CAALafn6DyMC4rFCczUZ7gGaEz05w=OBB==2b9PbWD3WEH+Tv=Q@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
	<4FA20967.3090604@gemini.edu>
	<CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>
	<CAALafn4iBpPcwOCkrjyaRDZh119FL45xnJaWb060j533SFXxhA@mail.gmail.com>
	<70657ED2-F351-424C-A169-1AC58F487F0F@gmail.com>
	<CAALafn5Cr3OXhMnsHZ3aBERFFaZnOdzUEy5YiLNkbnaiU8Lyvg@mail.gmail.com>
	<8F2E78FE-83EB-41BC-9FE0-E0705939F327@stsci.edu>
	<CAALafn6DyMC4rFCczUZ7gGaEz05w=OBB==2b9PbWD3WEH+Tv=Q@mail.gmail.com>
Message-ID: <2A604821-BFD7-433A-A93C-A2D4A8304242@gmail.com>

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

mycoord.to_galactic() will return the galactic coordinates.

As I said it would be easiest to show your implementation on an example:

One way we plan to do it is:

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

How would this work in AST (pseudo code).


Cheers
  Wolfgang




The world coordinate system is meant to not specifically be designed for 2D/3D arrays

On 2012-05-03, at 1:39 PM, David Berry wrote:

> What you say is reasonable, but I don't see that it follows that they need to be handled differently. Considered as a class, coordinate systems have a lot of common properties and methods no matter what they describe. Getting a sufficiently generic base class allows you to extend the system easily. That's why it was so easy to add support for spectral and time to AST. In practice it all works out very smoothly.
> 
> David
> 
> On Thursday, 3 May 2012, Perry Greenfield <perry at stsci.edu> wrote:
> >
> > On May 3, 2012, at 11:45 AM, David Berry wrote:
> >
> >> 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 agree that they are both identical in some respects (and it is worth considering a common api for at least a good part of both). To me the main difference is that one is standards focused (dealing with well known coordinate  systems and the transformations between them, whereas wcs is dealing more with instrumental effects and transforming from that to world coordinates (which may be one of the standard systems, but it may not). In one most of the transforms are simple, as is the geometry. In the other they can be quite complex. The former usually transforms few distinct coordinates (yes, you can do big catalogs too), and the latter transforms large numbers of pixel coordinates in many case.
> >
> > So I'm not surprised that people come from different directions when approaching these two issues.
> >
> >
> > Perr
> >
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120503/689a5d87/attachment.html>

From d.berry at jach.hawaii.edu  Thu May  3 16:16:13 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Thu, 3 May 2012 21:16:13 +0100
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <2A604821-BFD7-433A-A93C-A2D4A8304242@gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
	<4FA20967.3090604@gemini.edu>
	<CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>
	<CAALafn4iBpPcwOCkrjyaRDZh119FL45xnJaWb060j533SFXxhA@mail.gmail.com>
	<70657ED2-F351-424C-A169-1AC58F487F0F@gmail.com>
	<CAALafn5Cr3OXhMnsHZ3aBERFFaZnOdzUEy5YiLNkbnaiU8Lyvg@mail.gmail.com>
	<8F2E78FE-83EB-41BC-9FE0-E0705939F327@stsci.edu>
	<CAALafn6DyMC4rFCczUZ7gGaEz05w=OBB==2b9PbWD3WEH+Tv=Q@mail.gmail.com>
	<2A604821-BFD7-433A-A93C-A2D4A8304242@gmail.com>
Message-ID: <CAALafn5AQx2Ai+oUzjvESFDkXn58aEGvBEtDUZwiZGYsbft3=g@mail.gmail.com>

On 3 May 2012 19:53, Wolfgang Kerzendorf <wkerzendorf at gmail.com> wrote:
> But AST doesn't handle unit conversion (e.g. from Kelvin to eV)

Glad you raised that, because AST *does* actually take account of
differences in units between two Frames.  See
http://www.starlink.rl.ac.uk/docs/sun210.htx/node81.html .

> which are
> also coordinate transformations, because it has a different focus (namely
> astronomical images and now spectra).

It handles all the units defined in FITS WCS paper II (or is it paper
III ?) including Kelvin and eV, both of which are useful astronomical
units (antenna temperature and spectral energy). As you say, they are
just another form of coordinate system and so follow many of the same
rules as other coordinate systems.

> For now, we have made the
> distinctions: time, celestial coordinates, SI units, world coordinate
> systems for array based data.

What about spectral coordinates? And compound coordinate systems for
spectral cubes, etc?

> 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
>
> mycoord.to_galactic() will return the galactic coordinates.
>
> As I said it would be easiest to show your implementation on an example:
>
> One way we plan to do it is:
>
> 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
>
> How would this work in AST (pseudo code).

Don't forget, I agree I have gone well off the original topic, in that
AST is more aimed at people developing application code than at end
users. So what follows is maybe more verbose than a  user would like.

Firstly, I'm not 100% sure what your example is supposed to do. I'm
presuming you have a Julian Date in some unspecified time scale, and
convert it to something (another Julian Date?) in the UTC time scale.
Filling in the missing details,  to convert a Julian Date in (say) the
TT (Terrestrial Time) time scale to (say) an MJD in UTC time scale, it
would be like this:

frame_1 = new timeframe( system=JD, timescale=TT )
frame_2 = new timeframe( system=MJD, timescale=UTC )
mapping = frame_1.convert_to( frame_2 )
mjd = mapping.transform( 245423423423 )

So, create Frames (TimeFrames in this case) describing the two
coordinate systems, then get a Mapping that describes how to convert
between them, then use this mapping to transform the required axis
values. In this simple example, you may then delete the objects. But
in more complex cases, you would probably want to keep them around to
use for other purposes. TimeFrame has lots of other properties in
addition to System and Timescale, like units (days, year, seconds,
whatever), zero-points, local-time offset, etc. You can set as many of
these as you like when creating the TimeFrames (any unspecified
properties take default values), and the "convert_to" method will take
them all into account when working out the returned mapping. The
beauty is that the "convert_to" method is applicable to all classes of
Frame, and so is generic.

Your second example takes an (RA,Dec) position and converts to a
galactic position. The AST equivalent is basically the same as above,
here I've added some other properties for illustration like the
reference frame and equinox for the (RA,Dec):

frame_1 = new skyframe( system=FK4, equinox=1950, epoch=1967.34)
frame_2 = new skyframe( system=galactic )
mapping = frame_1.convert_to( frame_2 )
(l,b) = mapping.transform( 200, 20 )

Strictly, the "epoch" value could be omitted since it defaults to 1950
for FK4. AST supports sky coord in AZEL, ICRS, FK4 (with or without
E-terms), FK5, Galactic, super-galactic, Ecliptic, HelioEcliptic and
Geocentric apparent. All knowledge of these coordinate systems is
encapsulated in the one class "SkyFrame". Update your skyframe class
to support a new coordinate system, and - hey-presto - all your
application code supports the new system.

The same thing can be done for spectral coordinates in any common
system (wavelength, frequency, radio velocity, optical velocity,
energy, etc), in any common rest frame, in any common units (automatic
unit conversion is supported as I mentioned above). It even handles
dual-sideband spectral coordinate systems (i.e. two interrelated
spectral systems).

And it can be done for any combination of the above types of coordinates.

Another little nicety is that each sub-class of Frame knows how to
format axis values in a way that makes sense to the user. So for
instance, you could take the (ra,dec) values and convert them into
"h:m:s"/"d:m:s" format   for display as follows:

hms_string = frame_1.format( 200, axis=1 )
dms_string = frame_1.format( 20, axis=2 )

Similarly, the implementation of the Format method provided by the
TimeFrame class can format a numerical time value as a calendar date
string.

And here's a trick. Say you read WCS from two FITS files and want to
find the pixel coords in the second FITS file that has the same
position on the sky as pixel (100,230) in the first FITS file (i.e.
align the FITS files on the sky):

frameset_1 = fits1.read_wcs()
frameset_2 = fits2.read_wcs()
mapping = frameset_1.convert_to( frameset_2 )
(px,py) = mapping.transform( 100, 230 )

Notice it's the same basic pattern as before - create objects
describing your coordinate systems, use the convert_to method to get a
mapping between them, then use the mapping to convert axis values. In
this case we use two FrameSets rather than two SkyFrames or
TimeFrames. A FrameSet is a collection of Frames connected together by
mappings, and includes a "pixel Frame" and all the WCS Frames included
in the FITS file, with appropriate mappings between them. The
convert_to method then searches the two FrameSets for any frames that
can be interrelated (like two SkyFrames or two TimeFrames etc), and
works out the total mapping from input pixel coords to output pixel
coord (this is a bit simplified - there are ways of controlling
exactly how the convert_to method aligns the two FrameSets).

But you see that handling WCS is the same basic pattern as for single
coordinates.

Hope this is not too long-winded or unclear!

David


From d.berry at jach.hawaii.edu  Thu May  3 16:19:32 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Thu, 3 May 2012 21:19:32 +0100
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <CAALafn5AQx2Ai+oUzjvESFDkXn58aEGvBEtDUZwiZGYsbft3=g@mail.gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
	<4FA20967.3090604@gemini.edu>
	<CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>
	<CAALafn4iBpPcwOCkrjyaRDZh119FL45xnJaWb060j533SFXxhA@mail.gmail.com>
	<70657ED2-F351-424C-A169-1AC58F487F0F@gmail.com>
	<CAALafn5Cr3OXhMnsHZ3aBERFFaZnOdzUEy5YiLNkbnaiU8Lyvg@mail.gmail.com>
	<8F2E78FE-83EB-41BC-9FE0-E0705939F327@stsci.edu>
	<CAALafn6DyMC4rFCczUZ7gGaEz05w=OBB==2b9PbWD3WEH+Tv=Q@mail.gmail.com>
	<2A604821-BFD7-433A-A93C-A2D4A8304242@gmail.com>
	<CAALafn5AQx2Ai+oUzjvESFDkXn58aEGvBEtDUZwiZGYsbft3=g@mail.gmail.com>
Message-ID: <CAALafn6k9CUVkbfa36ccTrjzmVy=E8SivxKCupJH5s9otUo21Q@mail.gmail.com>

On 3 May 2012 21:16, David Berry <d.berry at jach.hawaii.edu> wrote:

> frame_1 = new skyframe( system=FK4, equinox=1950, epoch=1967.34)
> frame_2 = new skyframe( system=galactic )
> mapping = frame_1.convert_to( frame_2 )
> (l,b) = mapping.transform( 200, 20 )
>
> Strictly, the "epoch" value could be omitted since it defaults to 1950
> for FK4.

Doh! Obvious mistake - I meant "equinox" not "epoch"...

David


From tim.jenness at gmail.com  Thu May  3 17:17:43 2012
From: tim.jenness at gmail.com (Tim Jenness)
Date: Thu, 3 May 2012 14:17:43 -0700
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <2A604821-BFD7-433A-A93C-A2D4A8304242@gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
	<4FA20967.3090604@gemini.edu>
	<CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>
	<CAALafn4iBpPcwOCkrjyaRDZh119FL45xnJaWb060j533SFXxhA@mail.gmail.com>
	<70657ED2-F351-424C-A169-1AC58F487F0F@gmail.com>
	<CAALafn5Cr3OXhMnsHZ3aBERFFaZnOdzUEy5YiLNkbnaiU8Lyvg@mail.gmail.com>
	<8F2E78FE-83EB-41BC-9FE0-E0705939F327@stsci.edu>
	<CAALafn6DyMC4rFCczUZ7gGaEz05w=OBB==2b9PbWD3WEH+Tv=Q@mail.gmail.com>
	<2A604821-BFD7-433A-A93C-A2D4A8304242@gmail.com>
Message-ID: <CA+G92RfvrDob_QvwtZozmXw=DYOPePSP-_m3-x6f9zS5LJPHew@mail.gmail.com>

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?


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

-- 
Tim Jenness
Joint Astronomy Centre


From tim.jenness at gmail.com  Fri May  4 12:07:19 2012
From: tim.jenness at gmail.com (Tim Jenness)
Date: Fri, 4 May 2012 09:07:19 -0700
Subject: [AstroPy] API question: Instantiating of time/coord and similar
In-Reply-To: <B20B0BD2-8B94-49AF-B68C-CF016324D69E@gmail.com>
References: <2630EF46-8730-4FF6-906C-7616C493F7C1@gmail.com>
	<CAALafn7y8H2j=iQcVj36yNPeD7zobuGVrr5qR9YOQ7J3d84BxQ@mail.gmail.com>
	<CAARXUwUJ8VNbMG+ZKhL_jxX+CxY=Mn_fhj1sjHDu7ebNUB6e-Q@mail.gmail.com>
	<CAALafn4i_wWrS2+WVuGhZmG1-t2JF2Ga=xFXdusWwLbZn+v7GQ@mail.gmail.com>
	<766B1386-33F1-435D-8B74-114EC41F2F52@stsci.edu>
	<CA+G92Rc0rnTxDTd=E+DTVj53tGaWksHQxm5W5nHsViyB7d4rrw@mail.gmail.com>
	<50101C26-3A92-4F52-97E4-9DCF0E85FC81@stsci.edu>
	<CA+G92RdTCtJH-Sk-3Q6xyPoDhKKMQWsM1dd9bhE-bj+7zCe9mg@mail.gmail.com>
	<034C1EF9-3EDA-4919-A71E-FFA197761AAD@gmail.com>
	<CA+G92Rf8FrhcBsGX1g_x0N6L86+qp9Qn415Q4QeW0hM0HjScXw@mail.gmail.com>
	<4FA1BBB9.5050801@gemini.edu>
	<5D69DF95-0A60-4329-A696-3BB0D92B82B6@mpi-hd.mpg.de>
	<CAARXUwWJQ50420tRLghGnZgWv+Qymp8d9VqPWMHgC9Xk-sUBAw@mail.gmail.com>
	<4FA1F90F.8010100@gemini.edu>
	<CA+G92ReOHULe1wGQbziaHp7Dj5aS2OUp=6gT-cUevCynXAQ_9A@mail.gmail.com>
	<4FA20967.3090604@gemini.edu>
	<CA+G92RefoB3LTFP-MWS_AunreRqDLvp7cL9SyhEQnvTNy+w=QA@mail.gmail.com>
	<CAALafn4iBpPcwOCkrjyaRDZh119FL45xnJaWb060j533SFXxhA@mail.gmail.com>
	<70657ED2-F351-424C-A169-1AC58F487F0F@gmail.com>
	<CAALafn5Cr3OXhMnsHZ3aBERFFaZnOdzUEy5YiLNkbnaiU8Lyvg@mail.gmail.com>
	<8F2E78FE-83EB-41BC-9FE0-E0705939F327@stsci.edu>
	<CAALafn6DyMC4rFCczUZ7gGaEz05w=OBB==2b9PbWD3WEH+Tv=Q@mail.gmail.com>
	<2A604821-BFD7-433A-A93C-A2D4A8304242@gmail.com>
	<CA+G92RfvrDob_QvwtZozmXw=DYOPePSP-_m3-x6f9zS5LJPHew@mail.gmail.com>
	<B20B0BD2-8B94-49AF-B68C-CF016324D69E@gmail.com>
Message-ID: <CA+G92RfiMKQEmVg2TVLqbiF_x=Fi0W9hS=YqQYsq=kP-HnjKpA@mail.gmail.com>

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


From perry at stsci.edu  Fri May  4 13:34:37 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Fri, 4 May 2012 13:34:37 -0400
Subject: [AstroPy] comments on coordinate system and wcs packages
References: <403BC71D-D1D2-4589-8566-30AC23F4D611@stsci.edu>
Message-ID: <2F2F9515-9103-4AB0-8135-41FCA5461BC9@stsci.edu>


To add to the discussion a bit.

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

To start, I'd like to say that the AST design is far more flexible  
than most of the other libraries out there (that I'm aware of anyway).  
Yet, I would like some different approaches for astropy (I only speak  
for myself here, by the way).

I'll only mention a few reasons why today. I think the primary general  
one is that I think AST bundles together a number of things that  
should have separate and distinct functionality within astropy. This  
is both an implementation and an interface issue. I'll call out a few  
examples.

The first is units. Unit handling appears to be embedded within AST.  
Yet units have many other uses outside this framework. So at the very  
least, a units module has to be separate.

The second is that coordinate systems are an intrinsic part of the  
system (essentially everything derives from frame). Again, the mapping  
aspect doesn't necessarily need to be tied to any particular  
coordinate system. It's not uncommon for WCS definitions to be  
essentially agnostic about what coordinate system they are using since  
the most important problem is regarding relative coordinates. Arguably  
any sky coordinate system would do. Sure, one could then pick any and  
use it consistently. But why involve that machinery if it isn't  
necessary?

So I would see mapping as a distinct entity from frames. Frames use  
mappings, but mappings don't inherit from frames. (We've been calling  
them transforms locally.) I tend to see the equivalent of frames as  
using units and mappings for various operations (but again, is the  
intrinsic definition of a frame unit based? Aren't units only for  
input and output of coordinates? Arguably the intrinsic sky coordinate  
is unitless, or at least a consistent internal system should be used  
for sky coordinates (e.g, degrees or radians; or perhaps even better;  
unit sphere vector coordinates).

Another reason to keep mappings separate is that they have more  
general applicability than do frames. Our goal is to have a mapping  
framework that integrates well with fitting tools, and at the same  
time is as decoupled from fitting tools as possible. I don't see that  
this is currently in the AST framework. For WCS, fitting is a big  
issue, and pretty intertwined with how WCS models are determined.

Finally, there are various complexities of how to interact with FITS  
files as regards WCS models. There is no single approach that  
satisfies all needs. I don't think the AST approach solves this issue  
well enough either. A lot could be written on this single point, which  
I won't here, but I won't be surprised if I'll be required to. ;-)

We have been working here at STScI on dealing with WCS aspect of this  
approach (particularly with regards to mappings, fitting, and how to  
deal with FITS). We haven't done much with the coordinate frame issues  
(they aren't as urgent). Integrating the two in a flexible way would  
be great.

Perry



From jturner at gemini.edu  Fri May  4 14:22:23 2012
From: jturner at gemini.edu (James Turner)
Date: Fri, 4 May 2012 14:22:23 -0400
Subject: [AstroPy] comments on coordinate system and wcs packages
In-Reply-To: <2F2F9515-9103-4AB0-8135-41FCA5461BC9@stsci.edu>
References: <403BC71D-D1D2-4589-8566-30AC23F4D611@stsci.edu>
	<2F2F9515-9103-4AB0-8135-41FCA5461BC9@stsci.edu>
Message-ID: <4FA41E5F.8040401@gemini.edu>

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


From laidler at stsci.edu  Fri May  4 14:32:35 2012
From: laidler at stsci.edu (Victoria G. Laidler)
Date: Fri, 4 May 2012 14:32:35 -0400
Subject: [AstroPy] comments on coordinate system and wcs packages
In-Reply-To: <4FA41E5F.8040401@gemini.edu>
References: <403BC71D-D1D2-4589-8566-30AC23F4D611@stsci.edu>
	<2F2F9515-9103-4AB0-8135-41FCA5461BC9@stsci.edu>
	<4FA41E5F.8040401@gemini.edu>
Message-ID: <4FA420C3.6050408@stsci.edu>

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



From wkerzendorf at gmail.com  Fri May  4 15:58:37 2012
From: wkerzendorf at gmail.com (Wolfgang Kerzendorf)
Date: Fri, 4 May 2012 15:58:37 -0400
Subject: [AstroPy] comments on coordinate system and wcs packages
In-Reply-To: <4FA420C3.6050408@stsci.edu>
References: <403BC71D-D1D2-4589-8566-30AC23F4D611@stsci.edu>
	<2F2F9515-9103-4AB0-8135-41FCA5461BC9@stsci.edu>
	<4FA41E5F.8040401@gemini.edu> <4FA420C3.6050408@stsci.edu>
Message-ID: <87BF7EBD-BC6A-4C4C-A7ED-35A8FA9CB011@gmail.com>

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



From sransom at nrao.edu  Fri May  4 17:01:59 2012
From: sransom at nrao.edu (Scott Ransom)
Date: Fri, 04 May 2012 17:01:59 -0400
Subject: [AstroPy] comments on coordinate system and wcs packages
In-Reply-To: <4FA420C3.6050408@stsci.edu>
References: <403BC71D-D1D2-4589-8566-30AC23F4D611@stsci.edu>
	<2F2F9515-9103-4AB0-8135-41FCA5461BC9@stsci.edu>
	<4FA41E5F.8040401@gemini.edu> <4FA420C3.6050408@stsci.edu>
Message-ID: <4FA443C7.4070208@nrao.edu>

On 05/04/2012 02: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.

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

Scott

-- 
Scott M. Ransom            Address:  NRAO
Phone:  (434) 296-0320               520 Edgemont Rd.
email:  sransom at nrao.edu             Charlottesville, VA 22903 USA
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989


From jerome_caron_astro at ymail.com  Fri May  4 17:58:55 2012
From: jerome_caron_astro at ymail.com (Jerome Caron)
Date: Fri, 4 May 2012 22:58:55 +0100 (BST)
Subject: [AstroPy] problem with vo.table library and VOtable file from Vizier
Message-ID: <1336168735.17887.YahooMailNeo@web28804.mail.ir2.yahoo.com>

Dear list
I cannot correctly open a VOtable created by Vizier with the vo.table library.
The concerned xml file can be found here:
http://www.aspylib.com/bazar/vizier.xml
?
What happens is that, by chance, there are exactly?256 stars in the file (it's a field in Auriga, about 2deg*2deg with stars up to magnitude 11).
The following instructions in python return an array with 512 rows. The first 256 rows are occupied by the stars, and the next 256 rows contain only zeros. But the Python code should return a 256 rows array with only the stars ! I am not sure if something is wrong in the file or if that's a bug in the python module ?
Any help would be greatly appreciated... :-)
Many thanks
Jerome Caron
?
from vo.table import parse_single_table
cat = parse_single_table("vizier.xml")
data = cat.array
print data['RAJ2000']????#print alpha --> 512 lines
print data['DEJ2000']????#print delta --> 512 lines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120504/c7db25a7/attachment.html>

From jerome_caron_astro at ymail.com  Fri May  4 18:04:06 2012
From: jerome_caron_astro at ymail.com (Jerome Caron)
Date: Fri, 4 May 2012 23:04:06 +0100 (BST)
Subject: [AstroPy] Tr : problem with vo.table library and VOtable file from
	Vizier
In-Reply-To: <1336168735.17887.YahooMailNeo@web28804.mail.ir2.yahoo.com>
References: <1336168735.17887.YahooMailNeo@web28804.mail.ir2.yahoo.com>
Message-ID: <1336169046.94067.YahooMailNeo@web28805.mail.ir2.yahoo.com>

Sorry I forgot something in the code.. But the problem is still there..
?

----- Mail transf?r? -----
De?: Jerome Caron <jerome_caron_astro at ymail.com>
??: "astropy at scipy.org" <astropy at scipy.org> 
Envoy? le : Vendredi 4 mai 2012 23h58
Objet?: [AstroPy] problem with vo.table library and VOtable file from Vizier


Dear list
I cannot correctly open a VOtable created by Vizier with the vo.table library.
The concerned xml file can be found here:
http://www.aspylib.com/bazar/vizier.xml

What happens is that, by chance, there are exactly?256 stars in the file (it's a field in Auriga, about 2deg*2deg with stars up to magnitude 11).
The following instructions in python return an array with 512 rows. The first 256 rows are occupied by the stars, and the next 256 rows contain only zeros. But the Python code should return a 256 rows array with only the stars ! I am not sure if something is wrong in the file or if that's a bug in the python module ?
Any help would be greatly appreciated... :-)
Many thanks
Jerome Caron

from vo.table import parse_single_table
cat = parse_single_table("vizier.xml")
data = cat.array
print data['RAJ2000']????#print alpha --> 512 lines
print data['DEJ2000']????#print delta --> 512 lines
?
?
_______________________________________________
AstroPy mailing list
AstroPy at scipy.org
http://mail.scipy.org/mailman/listinfo/astropy



from vo.table import parse_single_table
cat = parse_single_table("vizier.xml", pedantic=False)
data = cat.array
print data['RAJ2000']????#print alpha --> 512 lines
print data['DEJ2000']????#print delta --> 512 lines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120504/3dcbc87c/attachment.html>

From thomas.boch at astro.unistra.fr  Fri May  4 18:30:17 2012
From: thomas.boch at astro.unistra.fr (Thomas Boch)
Date: Sat, 05 May 2012 00:30:17 +0200
Subject: [AstroPy] Tr : problem with vo.table library and VOtable file
 from Vizier
In-Reply-To: <1336169046.94067.YahooMailNeo@web28805.mail.ir2.yahoo.com>
References: <1336168735.17887.YahooMailNeo@web28804.mail.ir2.yahoo.com>
	<1336169046.94067.YahooMailNeo@web28805.mail.ir2.yahoo.com>
Message-ID: <4FA45879.2080706@astro.unistra.fr>

Dear Jerome,

the VOTable outputted by VizieR looks valid.
Moreover, if you remove one row from the XML file, the Python code 
returns 255 lines, as expected. Thus, I'd suspect a side-effect bug in 
the vo.table package.
Cheers,

Thomas

Le 05/05/12 00:04, Jerome Caron a ?crit :
> Sorry I forgot something in the code.. But the problem is still there..
> from vo.table import parse_single_table
> cat = parse_single_table("vizier.xml", pedantic=False)
> data = cat.array
> print data['RAJ2000']    #print alpha --> 512 lines
> print data['DEJ2000']    #print delta --> 512 lines
>
> ----- Mail transf?r? -----
> *De :* Jerome Caron <jerome_caron_astro at ymail.com>
> *? :* "astropy at scipy.org" <astropy at scipy.org>
> *Envoy? le :* Vendredi 4 mai 2012 23h58
> *Objet :* [AstroPy] problem with vo.table library and VOtable file 
> from Vizier
>
> Dear list
> I cannot correctly open a VOtable created by Vizier with the vo.table 
> library.
> The concerned xml file can be found here:
> http://www.aspylib.com/bazar/vizier.xml
> What happens is that, by chance, there are exactly 256 stars in the 
> file (it's a field in Auriga, about 2deg*2deg with stars up to 
> magnitude 11).
> The following instructions in python return an array with 512 rows. 
> The first 256 rows are occupied by the stars, and the next 256 rows 
> contain only zeros. But the Python code should return a 256 rows array 
> with only the stars ! I am not sure if something is wrong in the file 
> or if that's a bug in the python module ?
> Any help would be greatly appreciated... :-)
> Many thanks
> Jerome Caron
> from vo.table import parse_single_table
> cat = parse_single_table("vizier.xml")
> data = cat.array
> print data['RAJ2000']    #print alpha --> 512 lines
> print data['DEJ2000']    #print delta --> 512 lines
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120505/7a7fbd77/attachment.html>

From mperrin at stsci.edu  Fri May  4 19:08:24 2012
From: mperrin at stsci.edu (Marshall Perrin)
Date: Fri, 4 May 2012 23:08:24 +0000
Subject: [AstroPy] comments on coordinate system and wcs packages
In-Reply-To: <87BF7EBD-BC6A-4C4C-A7ED-35A8FA9CB011@gmail.com>
References: <403BC71D-D1D2-4589-8566-30AC23F4D611@stsci.edu>
	<2F2F9515-9103-4AB0-8135-41FCA5461BC9@stsci.edu>
	<4FA41E5F.8040401@gemini.edu> <4FA420C3.6050408@stsci.edu>
	<87BF7EBD-BC6A-4C4C-A7ED-35A8FA9CB011@gmail.com>
Message-ID: <50778EE0-F26F-4B24-8633-A1E045EADAB4@stsci.edu>

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



From d.berry at jach.hawaii.edu  Fri May  4 19:12:03 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Sat, 5 May 2012 00:12:03 +0100
Subject: [AstroPy] comments on coordinate system and wcs packages
In-Reply-To: <4FA443C7.4070208@nrao.edu>
References: <403BC71D-D1D2-4589-8566-30AC23F4D611@stsci.edu>
	<2F2F9515-9103-4AB0-8135-41FCA5461BC9@stsci.edu>
	<4FA41E5F.8040401@gemini.edu> <4FA420C3.6050408@stsci.edu>
	<4FA443C7.4070208@nrao.edu>
Message-ID: <CAALafn4hJjU4V3rv57REpvSaGFXjNABzw1DRB=A8Q6bB179V5Q@mail.gmail.com>

Hi All,
         I've probably done most of what's useful now in terms of
presenting the AST model as a tried and tested, very flexible and
easily extended coordinate handling paradigm. Obviously it's up to you
guys to make the decisions since I'm only an interested bystander.

There's an awful lot more that could be said about the things AST
does, and why. The one big problem with it is that for historical
reasons it is a monolithic system. When we first started on AST about
20 years ago, object-oriented languages were not common in astronomy.
There was a bit of C++ around, but the main author (Rodney
Warren-Smith) decided that to promote it's take up, we would write it
in pure ANSI C. This meant he first had to write an entire OO
infrastructure system to support inheritance, encapsulation,
polymorphism etc. which he did quite effectively. But that has meant
that the only way to extend AST is by adding new classes to AST
itself. Which is why AST gives the impression of doing "everything".

Nowadays, with Python, Java, etc being so common, we would have done
it differently. And indeed I think it's a good idea to look at Mapping
as a separate and more fundamental thing. Then have Unit as a class
that can do things like returning a Mapping between two unit strings.
Then have a hierarchy of Frame classes, each with built-in knowledge
of the various specific coordinate systems that can be used to
describe a single physical or mathematical space, and with the ability
to return a Mapping between any two such coordinate systems. And then
have a FrameSet which represents a collection of Frames connected
together by Mappings.

The only reason we made Frame inherit from Mapping within AST is that
we did not have any way of doing multiple inheritance or Java-like
interfaces using the OO infrastructure Rodney had written. We wanted
FrameSet to inherit from both Frame and Mapping so a FrameSet could be
used either as a Frame - it's "current" Frame, or as a Mapping - the
Mapping from its "base" Frame to its "current" Frame. With modern OO
languages there is no real reason to make Frame inherit from Mapping.

On the issue of units though, I must have a blind spot. Surely units
are a fundamental part of coordinate handling? Every axis within a
coordinate system has some units, so how can you work out mappings
between frames without taking the axis units into account? If you have
a frequency axis in GHz and a velocity axis in km/s, then in order to
get a Mapping between them you need to know what "GHz" and "km/s"
means, and how to transform them into other things. It's an implicit
part of coordinate handling. That's not to say that the Frame class
could not call out to a separate Unit class to get the required
transformations though.

Regarding FITS WCS, I've long held that it's unnecessarily
restrictive. AST is much more flexible, and has it's own textual
format for storing and retrieving WCS in data files that can handle a
much wider range of transformations that FITS-WCS. But obviously
everyone wants to use FITS, so AST contains a translator class
(FitsChan - it's what DS9 uses for reading FITS-WCS . The problem is
that many of the FrameSets that AST can create and handle cannot be
represented in FITS. Perry - I'd be interested to hear what your
concerns are about FITS-WCS.

Anyway, as I said at the beginning, I've probably said as much as (or
more than) is useful on the subject of why AST is a good model for
coordinate handling. In summary, it just works!

David


BTW - RA and Dec are tied together into a single Frame because you
wouldn't otherwise be able to  move around in a (RA,Dec) coordinate
system or transform an (RA,Fec) position into (e.g) galactic coords
without knowing about the spherical nature of these coordinate
systems.


From tim.jenness at gmail.com  Fri May  4 19:15:28 2012
From: tim.jenness at gmail.com (Tim Jenness)
Date: Fri, 4 May 2012 16:15:28 -0700
Subject: [AstroPy] comments on coordinate system and wcs packages
In-Reply-To: <50778EE0-F26F-4B24-8633-A1E045EADAB4@stsci.edu>
References: <403BC71D-D1D2-4589-8566-30AC23F4D611@stsci.edu>
	<2F2F9515-9103-4AB0-8135-41FCA5461BC9@stsci.edu>
	<4FA41E5F.8040401@gemini.edu> <4FA420C3.6050408@stsci.edu>
	<87BF7EBD-BC6A-4C4C-A7ED-35A8FA9CB011@gmail.com>
	<50778EE0-F26F-4B24-8633-A1E045EADAB4@stsci.edu>
Message-ID: <CA+G92RfZFK53qSb+WwXYsnVUGOqnhn-xxNcWdifopqigMnCNaw@mail.gmail.com>

On Fri, May 4, 2012 at 4:08 PM, Marshall Perrin <mperrin at stsci.edu> 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.
>

Exactly

>>>> mycoord = myifu.pixel2world(500, 500, 500)
> <SpectralCelestialCoord object>

This would be a CmpFrame in AST made up of a SkyFrame and SpecFrame.

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

Exactly. Look at the attributes associated with a SpecFrame

http://www.starlink.rl.ac.uk/docs/sun211.htx/node680.html

-- 
Tim Jenness
Joint Astronomy Centre


From sransom at nrao.edu  Fri May  4 19:22:40 2012
From: sransom at nrao.edu (Scott Ransom)
Date: Fri, 04 May 2012 19:22:40 -0400
Subject: [AstroPy] comments on coordinate system and wcs packages
In-Reply-To: <50778EE0-F26F-4B24-8633-A1E045EADAB4@stsci.edu>
References: <403BC71D-D1D2-4589-8566-30AC23F4D611@stsci.edu>
	<2F2F9515-9103-4AB0-8135-41FCA5461BC9@stsci.edu>
	<4FA41E5F.8040401@gemini.edu> <4FA420C3.6050408@stsci.edu>
	<87BF7EBD-BC6A-4C4C-A7ED-35A8FA9CB011@gmail.com>
	<50778EE0-F26F-4B24-8633-A1E045EADAB4@stsci.edu>
Message-ID: <4FA464C0.5090908@nrao.edu>

On 05/04/2012 07:08 PM, Marshall Perrin wrote:

> 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

I'd love to do this, but I really have no clue!  I've never even run it 
-- I work on pulsars and we have all of our own custom software (much of 
it in python).  I'll forward your query to some of the CASA folks, though.

Scott

-- 
Scott M. Ransom            Address:  NRAO
Phone:  (434) 296-0320               520 Edgemont Rd.
email:  sransom at nrao.edu             Charlottesville, VA 22903 USA
GPG Fingerprint: 06A9 9553 78BE 16DB 407B  FFCA 9BFA B6FF FFD3 2989


From thomas.robitaille at gmail.com  Sat May  5 04:14:56 2012
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Sat, 5 May 2012 10:14:56 +0200
Subject: [AstroPy] comments on coordinate system and wcs packages
In-Reply-To: <4FA464C0.5090908@nrao.edu>
References: <403BC71D-D1D2-4589-8566-30AC23F4D611@stsci.edu>
	<2F2F9515-9103-4AB0-8135-41FCA5461BC9@stsci.edu>
	<4FA41E5F.8040401@gemini.edu> <4FA420C3.6050408@stsci.edu>
	<87BF7EBD-BC6A-4C4C-A7ED-35A8FA9CB011@gmail.com>
	<50778EE0-F26F-4B24-8633-A1E045EADAB4@stsci.edu>
	<4FA464C0.5090908@nrao.edu>
Message-ID: <CAGMHX_1o12D7B2vc1QVyU0=zWdd7Yq+bHzbODSfL_dOWorL+2A@mail.gmail.com>

I think we should move the conversation back to astropy-dev, as it
would be good to have these discussions there for future record (this
is meant to be more of a user-list). I have some comments to make
about some of the points raised in this thread, so I'll start a new
thread there.

Tom

On 5 May 2012 01:22, Scott Ransom <sransom at nrao.edu> wrote:
> On 05/04/2012 07:08 PM, Marshall Perrin wrote:
>
>> 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
>
> I'd love to do this, but I really have no clue! ?I've never even run it
> -- I work on pulsars and we have all of our own custom software (much of
> it in python). ?I'll forward your query to some of the CASA folks, though.
>
> Scott
>
> --
> Scott M. Ransom ? ? ? ? ? ?Address: ?NRAO
> Phone: ?(434) 296-0320 ? ? ? ? ? ? ? 520 Edgemont Rd.
> email: ?sransom at nrao.edu ? ? ? ? ? ? Charlottesville, VA 22903 USA
> GPG Fingerprint: 06A9 9553 78BE 16DB 407B ?FFCA 9BFA B6FF FFD3 2989
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From perry at stsci.edu  Sat May  5 11:25:57 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Sat, 5 May 2012 11:25:57 -0400
Subject: [AstroPy] comments on coordinate system and wcs packages
In-Reply-To: <50778EE0-F26F-4B24-8633-A1E045EADAB4@stsci.edu>
References: <403BC71D-D1D2-4589-8566-30AC23F4D611@stsci.edu>
	<2F2F9515-9103-4AB0-8135-41FCA5461BC9@stsci.edu>
	<4FA41E5F.8040401@gemini.edu> <4FA420C3.6050408@stsci.edu>
	<87BF7EBD-BC6A-4C4C-A7ED-35A8FA9CB011@gmail.com>
	<50778EE0-F26F-4B24-8633-A1E045EADAB4@stsci.edu>
Message-ID: <056B351A-4491-4440-A1B0-FC77F86CF294@stsci.edu>

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



From mdroe at stsci.edu  Mon May  7 10:25:38 2012
From: mdroe at stsci.edu (Michael Droettboom)
Date: Mon, 7 May 2012 10:25:38 -0400
Subject: [AstroPy] Tr : problem with vo.table library and VOtable file
 from Vizier
In-Reply-To: <1336169046.94067.YahooMailNeo@web28805.mail.ir2.yahoo.com>
References: <1336168735.17887.YahooMailNeo@web28804.mail.ir2.yahoo.com>
	<1336169046.94067.YahooMailNeo@web28805.mail.ir2.yahoo.com>
Message-ID: <4FA7DB62.9030901@stsci.edu>

Indeed, this is a bug that exhibits only when the number of rows in the 
table is exactly equal to 256.

I've attached a patch that fixes the bug that is now in SVN.

As a workaround until the next release, you can either install the SVN 
version from source, or pass "chunk_size=1" to the parse_single_table or 
parse functions (with a loss of performance).

Mike

On 05/04/2012 06:04 PM, Jerome Caron wrote:
> Sorry I forgot something in the code.. But the problem is still there..
> from vo.table import parse_single_table
> cat = parse_single_table("vizier.xml", pedantic=False)
> data = cat.array
> print data['RAJ2000']    #print alpha --> 512 lines
> print data['DEJ2000']    #print delta --> 512 lines
>
> ----- Mail transf?r? -----
> *De :* Jerome Caron <jerome_caron_astro at ymail.com>
> *? :* "astropy at scipy.org" <astropy at scipy.org>
> *Envoy? le :* Vendredi 4 mai 2012 23h58
> *Objet :* [AstroPy] problem with vo.table library and VOtable file 
> from Vizier
>
> Dear list
> I cannot correctly open a VOtable created by Vizier with the vo.table 
> library.
> The concerned xml file can be found here:
> http://www.aspylib.com/bazar/vizier.xml
> What happens is that, by chance, there are exactly 256 stars in the 
> file (it's a field in Auriga, about 2deg*2deg with stars up to 
> magnitude 11).
> The following instructions in python return an array with 512 rows. 
> The first 256 rows are occupied by the stars, and the next 256 rows 
> contain only zeros. But the Python code should return a 256 rows array 
> with only the stars ! I am not sure if something is wrong in the file 
> or if that's a bug in the python module ?
> Any help would be greatly appreciated... :-)
> Many thanks
> Jerome Caron
> from vo.table import parse_single_table
> cat = parse_single_table("vizier.xml")
> data = cat.array
> print data['RAJ2000']    #print alpha --> 512 lines
> print data['DEJ2000']    #print delta --> 512 lines
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120507/744b6e67/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 256rows.diff
Type: text/x-patch
Size: 977 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/astropy/attachments/20120507/744b6e67/attachment.bin>

From jim.vickroy at noaa.gov  Tue May  8 12:59:25 2012
From: jim.vickroy at noaa.gov (Jim Vickroy)
Date: Tue, 08 May 2012 10:59:25 -0600
Subject: [AstroPy] unexpected pyfits behavior float32 converted to float64
Message-ID: <4FA950ED.2090103@noaa.gov>

Hi Pyfits users,

Consider:

 >>> import pyfits
 >>> pyfits.__version__
'3.0.5'
 >>> path = ...
 >>> HDUs = pyfits.open (path,mode='readonly')
 >>> HDUs['primary'].header['bitpix']
32
 >>> HDUs['primary'].data.dtype
dtype('float64')
 >>> HDUs['primary'].header['bitpix']
-64
 >>>

Why is the conversion from 32 to 64 bit floats silently occurring?  How 
can I prevent it?

Thanks,
-- jv



From jim.vickroy at noaa.gov  Tue May  8 14:14:14 2012
From: jim.vickroy at noaa.gov (Jim Vickroy)
Date: Tue, 08 May 2012 12:14:14 -0600
Subject: [AstroPy] unexpected pyfits behavior float32 converted to
	float64
In-Reply-To: <4fa953d2.4574b60a.76bc.ffffc485@mx.google.com>
References: <4fa953d2.4574b60a.76bc.ffffc485@mx.google.com>
Message-ID: <4FA96276.6060506@noaa.gov>

On 5/8/2012 11:11 AM, Philip Tait wrote:
> Isn't this a known issue, fixed in 3.0.7?

Thanks for the quick reply.  It is embarrassing to post a problem and 
not be using the latest release.  So I've downloaded/installed 3.0.7.  
Unfortunately, the same behavior persists (i.e., unwanted, silent 
conversion from 32 to 64 bit floats) as illustrated below:

 >>> import os
 >>> import sys
 >>> import pyfits
 >>> sys.version
'2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'
 >>> pyfits.__version__
'3.0.7'
 >>> path = ...
 >>> HDUs = pyfits.open (path,mode='readonly')
 >>> HDUs['primary'].header['bitpix']
32
 >>> HDUs['primary'].data.dtype
dtype('float64')
 >>> HDUs['primary'].header['bitpix']
-64
 >>>

Is this a bug that should be reported?

Thanks,
-- jv






>
>
>
> -- Sent from my HP Pre3
>
> ------------------------------------------------------------------------
> On May 8, 2012 6:59, Jim Vickroy <jim.vickroy at noaa.gov> wrote:
>
> Hi Pyfits users,
>
> Consider:
>
> >>> import pyfits
> >>> pyfits.__version__
> '3.0.5'
> >>> path = ...
> >>> HDUs = pyfits.open (path,mode='readonly')
> >>> HDUs['primary'].header['bitpix']
> 32
> >>> HDUs['primary'].data.dtype
> dtype('float64')
> >>> HDUs['primary'].header['bitpix']
> -64
> >>>
>
> Why is the conversion from 32 to 64 bit floats silently occurring? How
> can I prevent it?
>
> Thanks,
> -- jv
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120508/93ab0939/attachment.html>

From mdroe at stsci.edu  Tue May  8 23:05:46 2012
From: mdroe at stsci.edu (Michael Droettboom)
Date: Tue, 8 May 2012 23:05:46 -0400
Subject: [AstroPy] unexpected pyfits behavior float32 converted to
	float64
In-Reply-To: <4FA96276.6060506@noaa.gov>
References: <4fa953d2.4574b60a.76bc.ffffc485@mx.google.com>
	<4FA96276.6060506@noaa.gov>
Message-ID: <4FA9DF0A.1080600@stsci.edu>

It actually appears that this is converting 32-bit integers to 64-bit 
floats.  Does the file have BZERO or BSCALE specified?  If so, it is 
normal behavior to convert to 64-bit floats so that user code doesn't 
have to deal with offset and scaling issues.

Mike

On 05/08/2012 02:14 PM, Jim Vickroy wrote:
> On 5/8/2012 11:11 AM, Philip Tait wrote:
>> Isn't this a known issue, fixed in 3.0.7?
>
> Thanks for the quick reply.  It is embarrassing to post a problem and 
> not be using the latest release.  So I've downloaded/installed 3.0.7.  
> Unfortunately, the same behavior persists (i.e., unwanted, silent 
> conversion from 32 to 64 bit floats) as illustrated below:
>
> >>> import os
> >>> import sys
> >>> import pyfits
> >>> sys.version
> '2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'
> >>> pyfits.__version__
> '3.0.7'
> >>> path = ...
> >>> HDUs = pyfits.open (path,mode='readonly')
> >>> HDUs['primary'].header['bitpix']
> 32
> >>> HDUs['primary'].data.dtype
> dtype('float64')
> >>> HDUs['primary'].header['bitpix']
> -64
> >>>
>
> Is this a bug that should be reported?
>
> Thanks,
> -- jv
>
>
>
>
>
>
>>
>>
>>
>> -- Sent from my HP Pre3
>>
>> ------------------------------------------------------------------------
>> On May 8, 2012 6:59, Jim Vickroy <jim.vickroy at noaa.gov> wrote:
>>
>> Hi Pyfits users,
>>
>> Consider:
>>
>> >>> import pyfits
>> >>> pyfits.__version__
>> '3.0.5'
>> >>> path = ...
>> >>> HDUs = pyfits.open (path,mode='readonly')
>> >>> HDUs['primary'].header['bitpix']
>> 32
>> >>> HDUs['primary'].data.dtype
>> dtype('float64')
>> >>> HDUs['primary'].header['bitpix']
>> -64
>> >>>
>>
>> Why is the conversion from 32 to 64 bit floats silently occurring? How
>> can I prevent it?
>>
>> Thanks,
>> -- jv
>>
>> _______________________________________________
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120508/71f9c082/attachment.html>

From jim.vickroy at noaa.gov  Wed May  9 10:18:46 2012
From: jim.vickroy at noaa.gov (Jim Vickroy)
Date: Wed, 09 May 2012 08:18:46 -0600
Subject: [AstroPy] unexpected pyfits behavior float32 converted to
	float64
In-Reply-To: <4FA9DF0A.1080600@stsci.edu>
References: <4fa953d2.4574b60a.76bc.ffffc485@mx.google.com>
	<4FA96276.6060506@noaa.gov> <4FA9DF0A.1080600@stsci.edu>
Message-ID: <4FAA7CC6.6040801@noaa.gov>

On 5/8/2012 9:05 PM, Michael Droettboom wrote:
> It actually appears that this is converting 32-bit integers to 64-bit 
> floats.  Does the file have BZERO or BSCALE specified?  If so, it is 
> normal behavior to convert to 64-bit floats so that user code doesn't 
> have to deal with offset and scaling issues.
>
> Mike

Thanks Mike.

The FITS files do have BZERO and BSCALE defined.  My mistake (twice) 
saying 32-bit float since BITPIX=+32.  I was expecting conversion to 
32-bit floats.  Since converting 32-bit integers to 64-bit floats is the 
standard Pyfits behavior, I will perform the conversion explicitly 
(numpy astype).

-- jv





>
> On 05/08/2012 02:14 PM, Jim Vickroy wrote:
>> On 5/8/2012 11:11 AM, Philip Tait wrote:
>>> Isn't this a known issue, fixed in 3.0.7?
>>
>> Thanks for the quick reply.  It is embarrassing to post a problem and 
>> not be using the latest release.  So I've downloaded/installed 
>> 3.0.7.  Unfortunately, the same behavior persists (i.e., unwanted, 
>> silent conversion from 32 to 64 bit floats) as illustrated below:
>>
>> >>> import os
>> >>> import sys
>> >>> import pyfits
>> >>> sys.version
>> '2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]'
>> >>> pyfits.__version__
>> '3.0.7'
>> >>> path = ...
>> >>> HDUs = pyfits.open (path,mode='readonly')
>> >>> HDUs['primary'].header['bitpix']
>> 32
>> >>> HDUs['primary'].data.dtype
>> dtype('float64')
>> >>> HDUs['primary'].header['bitpix']
>> -64
>> >>>
>>
>> Is this a bug that should be reported?
>>
>> Thanks,
>> -- jv
>>
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>> -- Sent from my HP Pre3
>>>
>>> ------------------------------------------------------------------------
>>> On May 8, 2012 6:59, Jim Vickroy <jim.vickroy at noaa.gov> wrote:
>>>
>>> Hi Pyfits users,
>>>
>>> Consider:
>>>
>>> >>> import pyfits
>>> >>> pyfits.__version__
>>> '3.0.5'
>>> >>> path = ...
>>> >>> HDUs = pyfits.open (path,mode='readonly')
>>> >>> HDUs['primary'].header['bitpix']
>>> 32
>>> >>> HDUs['primary'].data.dtype
>>> dtype('float64')
>>> >>> HDUs['primary'].header['bitpix']
>>> -64
>>> >>>
>>>
>>> Why is the conversion from 32 to 64 bit floats silently occurring? How
>>> can I prevent it?
>>>
>>> Thanks,
>>> -- jv
>>>
>>> _______________________________________________
>>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120509/ce7fb303/attachment.html>

From embray at stsci.edu  Wed May  9 11:22:24 2012
From: embray at stsci.edu (Erik Bray)
Date: Wed, 9 May 2012 11:22:24 -0400
Subject: [AstroPy] unexpected pyfits behavior float32 converted to
	float64
In-Reply-To: <4FAA7CC6.6040801@noaa.gov>
References: <4fa953d2.4574b60a.76bc.ffffc485@mx.google.com>
	<4FA96276.6060506@noaa.gov> <4FA9DF0A.1080600@stsci.edu>
	<4FAA7CC6.6040801@noaa.gov>
Message-ID: <4FAA8BB0.8070608@stsci.edu>

On 05/09/2012 10:18 AM, Jim Vickroy wrote:
> On 5/8/2012 9:05 PM, Michael Droettboom wrote:
>> It actually appears that this is converting 32-bit integers to 64-bit
>> floats. Does the file have BZERO or BSCALE specified? If so, it is
>> normal behavior to convert to 64-bit floats so that user code doesn't
>> have to deal with offset and scaling issues.
>>
>> Mike
>
> Thanks Mike.
>
> The FITS files do have BZERO and BSCALE defined. My mistake (twice)
> saying 32-bit float since BITPIX=+32. I was expecting conversion to
> 32-bit floats. Since converting 32-bit integers to 64-bit floats is the
> standard Pyfits behavior, I will perform the conversion explicitly
> (numpy astype).
>
> -- jv

The conversion from ints to floats is definitely the intended (albeit 
understandably surprising) behavior.

Interestingly, the PyFITS documentation is lying about this:

http://packages.python.org/pyfits/users_guide/users_image.html#reading-scaled-image-data

"For floating point storage data, the scaled data will have the same 
data type. For integer data type, the scaled data will always be single 
precision floating point (numpy.float32)."

I don't know what the reason is for this though.

Should PyFITS default to lower precision and lower memory use, or higher 
precision and higher memory use?  For the average image, scaling up to 
float64 should not be an issue for older systems.  Though on larger 
images it might start to be a problem.  Perhaps there should be an 
option for this?

Erik


From embray at stsci.edu  Wed May  9 11:35:33 2012
From: embray at stsci.edu (Erik Bray)
Date: Wed, 9 May 2012 11:35:33 -0400
Subject: [AstroPy] Possible PyFITS behavior change with scaled data
Message-ID: <4FAA8EC5.4040201@stsci.edu>

Hi all,

Speaking of conversion of scaled image data to floats, I have a question 
to put out there regarding the upcoming 3.0.8 release of PyFITS.

PyFITS 3.0.8 will fix a long-standing bug that's been around long enough 
that I'm worried that some people might have workarounds for it in place 
that will break now that the bug is fixed.

This specifically pertains to support for scaled images in image "sections".

For some background, PyFITS has a feature called "sections" that allows 
accessing small portions of an image without reading the entire image 
into memory at once.  For example:

 >>> hdul = pyfits.open('jb1f98q1q_raw.fits')
 >>> hdul.info()
Filename: jb1f98q1q_raw.fits
No.    Name         Type      Cards   Dimensions   Format
0    PRIMARY     PrimaryHDU     205   ()           int16
1    SCI         ImageHDU        95   (4144, 2068)   int16
...
 >>> hdul['SCI',1].header['BZERO']
32768.0
 >>> hdul['SCI',1].section[:100,:100]
array([[ 2278.,  2252.,  2248., ...,  2252.,  2252.,  2253.],
        [ 2277.,  2252.,  2250., ...,  2255.,  2253.,  2258.],
        [ 2277.,  2257.,  2250., ...,  2260.,  2255.,  2257.],
        ..., dtype=float32)

This reads the file in portions so that just the first 100x100 block of 
pixels is read from disk.

This feature used to have very spotty/broken support for scaled image 
data, but now that's been fixed.

Is that fact that this is now fixed likely to break anybody's code? 
Just curious.

Erik


From embray at stsci.edu  Wed May  9 11:49:51 2012
From: embray at stsci.edu (Erik Bray)
Date: Wed, 9 May 2012 11:49:51 -0400
Subject: [AstroPy] unexpected pyfits behavior float32 converted to
	float64
In-Reply-To: <4FAA8BB0.8070608@stsci.edu>
References: <4fa953d2.4574b60a.76bc.ffffc485@mx.google.com>
	<4FA96276.6060506@noaa.gov> <4FA9DF0A.1080600@stsci.edu>
	<4FAA7CC6.6040801@noaa.gov> <4FAA8BB0.8070608@stsci.edu>
Message-ID: <4FAA921F.5080502@stsci.edu>

On 05/09/2012 11:22 AM, Erik Bray wrote:
> On 05/09/2012 10:18 AM, Jim Vickroy wrote:
>> On 5/8/2012 9:05 PM, Michael Droettboom wrote:
>>> It actually appears that this is converting 32-bit integers to 64-bit
>>> floats. Does the file have BZERO or BSCALE specified? If so, it is
>>> normal behavior to convert to 64-bit floats so that user code doesn't
>>> have to deal with offset and scaling issues.
>>>
>>> Mike
>>
>> Thanks Mike.
>>
>> The FITS files do have BZERO and BSCALE defined. My mistake (twice)
>> saying 32-bit float since BITPIX=+32. I was expecting conversion to
>> 32-bit floats. Since converting 32-bit integers to 64-bit floats is the
>> standard Pyfits behavior, I will perform the conversion explicitly
>> (numpy astype).
>>
>> -- jv
>
> The conversion from ints to floats is definitely the intended (albeit
> understandably surprising) behavior.
>
> Interestingly, the PyFITS documentation is lying about this:
>
> http://packages.python.org/pyfits/users_guide/users_image.html#reading-scaled-image-data
>
> "For floating point storage data, the scaled data will have the same
> data type. For integer data type, the scaled data will always be single
> precision floating point (numpy.float32)."
>
> I don't know what the reason is for this though.
>
> Should PyFITS default to lower precision and lower memory use, or higher
> precision and higher memory use?  For the average image, scaling up to
> float64 should not be an issue for older systems.  Though on larger
> images it might start to be a problem.  Perhaps there should be an
> option for this?

As a followup: I did a little more digging on this issue, and found out 
that despite the deceptive documentation, this has actually been the 
behavior of PyFITS for quite a long time:

If the raw data is 16-bit ints they are scaled up to 32-bit floats.  And 
if they're 32-bit ints (or 64-bit I think) they're scaled to 64-bit 
floats.  I think this is so that one can generally expect the size of 
their data to double when reading scaled data.

Erik


From astropy at pzzlr.org  Wed May  9 12:14:06 2012
From: astropy at pzzlr.org (Rodney Barnett)
Date: Wed, 09 May 2012 11:14:06 -0500
Subject: [AstroPy] Simple vo.table bug
Message-ID: <4FAA97CE.1020000@pzzlr.org>

Hi,

I've just started using the vo.table package and ran into a problem.  I 
can't find any other place to report the problem and don't see a ticket 
for it, so here it is.

Looks like tree.py should import E06 along with the other warnings and 
exceptions.

Rodney


From hodge at stsci.edu  Wed May  9 12:38:59 2012
From: hodge at stsci.edu (Phil Hodge)
Date: Wed, 9 May 2012 12:38:59 -0400
Subject: [AstroPy] unexpected pyfits behavior float32 converted to
	float64
In-Reply-To: <4FAA921F.5080502@stsci.edu>
References: <4fa953d2.4574b60a.76bc.ffffc485@mx.google.com>
	<4FA96276.6060506@noaa.gov> <4FA9DF0A.1080600@stsci.edu>
	<4FAA7CC6.6040801@noaa.gov> <4FAA8BB0.8070608@stsci.edu>
	<4FAA921F.5080502@stsci.edu>
Message-ID: <4FAA9DA3.7090003@stsci.edu>

Erik,

On 05/09/2012 11:49 AM, Erik Bray wrote:
> As a followup: I did a little more digging on this issue, and found out
> that despite the deceptive documentation, this has actually been the
> behavior of PyFITS for quite a long time:
>
> If the raw data is 16-bit ints they are scaled up to 32-bit floats.  And
> if they're 32-bit ints (or 64-bit I think) they're scaled to 64-bit
> floats.  I think this is so that one can generally expect the size of
> their data to double when reading scaled data.

No, this is so you don't lose any precision.  A 32-bit float has 
something like 22 bits of precision, which is fine for a 16-bit integer, 
but you would lose around 10 bits if you converted a 32-bit integer to 
32-bit float.

Phil


From mdroe at stsci.edu  Wed May  9 13:00:55 2012
From: mdroe at stsci.edu (Michael Droettboom)
Date: Wed, 9 May 2012 13:00:55 -0400
Subject: [AstroPy] Simple vo.table bug
In-Reply-To: <4FAA97CE.1020000@pzzlr.org>
References: <4FAA97CE.1020000@pzzlr.org>
Message-ID: <4FAAA2C7.1000407@stsci.edu>

Indeed.  Thanks for the report.  This has been fixed in SVN w2737 and 
will make it into the next release.

Mike

On 05/09/2012 12:14 PM, Rodney Barnett wrote:
> Hi,
>
> I've just started using the vo.table package and ran into a problem.  I
> can't find any other place to report the problem and don't see a ticket
> for it, so here it is.
>
> Looks like tree.py should import E06 along with the other warnings and
> exceptions.
>
> Rodney
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From astropy at pzzlr.org  Wed May  9 13:31:50 2012
From: astropy at pzzlr.org (Rodney Barnett)
Date: Wed, 09 May 2012 12:31:50 -0500
Subject: [AstroPy] Leading/trailing space in PARAM value in vo.table
Message-ID: <4FAAAA06.6030309@pzzlr.org>

Hi,

I've encountered another problem though I don't see it explicitly 
addressed in the VOTable specs.  Maybe someone can tell me whether the 
problem is in the data files I'm working with or the vo.table package.

My data files have tags like this:
<PARAM name="XYZ" datatype="double" arraysize="2" ucd="pos;obs.param" 
value="    734.90     -23.799" unit="pix"/>

vo.table interprets the array as having three entries and complains 
since the stated size is two.

I made a change in converters.py to strip the value before splitting it 
and the problem was resolved.  However, I'm uncertain whether the value 
should be interpreted as having some sort of empty value as the first 
element instead.

Rodney


From embray at stsci.edu  Wed May  9 13:41:42 2012
From: embray at stsci.edu (Erik Bray)
Date: Wed, 9 May 2012 13:41:42 -0400
Subject: [AstroPy] unexpected pyfits behavior float32 converted to
	float64
In-Reply-To: <4FAA9DA3.7090003@stsci.edu>
References: <4fa953d2.4574b60a.76bc.ffffc485@mx.google.com>
	<4FA96276.6060506@noaa.gov> <4FA9DF0A.1080600@stsci.edu>
	<4FAA7CC6.6040801@noaa.gov> <4FAA8BB0.8070608@stsci.edu>
	<4FAA921F.5080502@stsci.edu> <4FAA9DA3.7090003@stsci.edu>
Message-ID: <4FAAAC56.5070502@stsci.edu>

On 05/09/2012 12:38 PM, Phil Hodge wrote:
> Erik,
>
> On 05/09/2012 11:49 AM, Erik Bray wrote:
>> As a followup: I did a little more digging on this issue, and found out
>> that despite the deceptive documentation, this has actually been the
>> behavior of PyFITS for quite a long time:
>>
>> If the raw data is 16-bit ints they are scaled up to 32-bit floats.  And
>> if they're 32-bit ints (or 64-bit I think) they're scaled to 64-bit
>> floats.  I think this is so that one can generally expect the size of
>> their data to double when reading scaled data.
>
> No, this is so you don't lose any precision.  A 32-bit float has
> something like 22 bits of precision, which is fine for a 16-bit integer,
> but you would lose around 10 bits if you converted a 32-bit integer to
> 32-bit float.
>
> Phil

Okay, that makes sense.  I didn't realize a 32-bit int was so poorly 
represented by a single float.

I think that if nothing else the PyFITS documentation should be updated 
to clarify this point.

Erik


From mdroe at stsci.edu  Wed May  9 13:50:38 2012
From: mdroe at stsci.edu (Michael Droettboom)
Date: Wed, 9 May 2012 13:50:38 -0400
Subject: [AstroPy] Leading/trailing space in PARAM value in vo.table
In-Reply-To: <4FAAAA06.6030309@pzzlr.org>
References: <4FAAAA06.6030309@pzzlr.org>
Message-ID: <4FAAAE6E.9070501@stsci.edu>

I don't think the spec specifically addresses this, but I'm inclined to 
see this as a bug in vo.table.

A better fix is to put a strip in the PARAM value setter, as text 
stripping is already done in XML text elements and it's redundant to put 
it at the lower level in converters.py.

I've committed a fix for this in SVN r2738.

Mike

On 05/09/2012 01:31 PM, Rodney Barnett wrote:
> Hi,
>
> I've encountered another problem though I don't see it explicitly
> addressed in the VOTable specs.  Maybe someone can tell me whether the
> problem is in the data files I'm working with or the vo.table package.
>
> My data files have tags like this:
> <PARAM name="XYZ" datatype="double" arraysize="2" ucd="pos;obs.param"
> value="    734.90     -23.799" unit="pix"/>
>
> vo.table interprets the array as having three entries and complains
> since the stated size is two.
>
> I made a change in converters.py to strip the value before splitting it
> and the problem was resolved.  However, I'm uncertain whether the value
> should be interpreted as having some sort of empty value as the first
> element instead.
>
> Rodney
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From astropy at pzzlr.org  Wed May  9 14:07:32 2012
From: astropy at pzzlr.org (Rodney Barnett)
Date: Wed, 09 May 2012 13:07:32 -0500
Subject: [AstroPy]  Leading/trailing space in PARAM value in vo.table
References: 4FAAAA06.6030309@pzzlr.org
Message-ID: <4FAAB264.1070509@pzzlr.org>

Michael Droettboom wrote:
> I don't think the spec specifically addresses this, but I'm inclined to
> see this as a bug in vo.table.
>
> A better fix is to put a strip in the PARAM value setter, as text
> stripping is already done in XML text elements and it's redundant to put
> it at the lower level in converters.py.
>
> I've committed a fix for this in SVN r2738.
>
> Mike

Thanks for the quick response to this and the other problem I reported.

Rodney


From astropy at pzzlr.org  Thu May 10 12:59:18 2012
From: astropy at pzzlr.org (Rodney Barnett)
Date: Thu, 10 May 2012 11:59:18 -0500
Subject: [AstroPy] Empty char value for PARAM with vo.table
Message-ID: <4FABF3E6.7040203@pzzlr.org>

I'm working with some VOTable files that have tags like this:

<PARAM name="XYZ" datatype="char" arraysize="*" ucd="meta.id;meta.file" 
value=""/>

vo.table.parse reports:

vo.voexceptions.E14: file.xml:213:3: E14: value attribute is required 
for all PARAM elements

The spec is clear that the value attribute is required, but isn't clear 
about whether the value must be non-empty.  Is there a consensus on this?

Thanks.

Rodney


From thomas.robitaille at gmail.com  Fri May 11 04:03:18 2012
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Fri, 11 May 2012 10:03:18 +0200
Subject: [AstroPy] Cross matching two source lists
Message-ID: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>

Hi everyone,

I am looking for a Python package that can do arbitrary and efficient
cross-matching of source lists, i.e. some kind of kd-tree that uses
spherical rather than euclidean distances. Is anyone aware of such a
package?

Thanks,
Tom


From sergiopr at fis.ucm.es  Fri May 11 05:10:08 2012
From: sergiopr at fis.ucm.es (Sergio Pascual)
Date: Fri, 11 May 2012 11:10:08 +0200
Subject: [AstroPy] Cross matching two source lists
In-Reply-To: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>
References: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>
Message-ID: <CACta-KZaoapeV46FqKXOs+JxJKmcnDAKxu+styjSOkSUDg=Oow@mail.gmail.com>

Well, I don't know if it's exactly what you are looking for, but,
after some discussion in this list I created a package that
implementsthe Groth algorithm for catalogue matching:

A Pattern-Matching Algorithm for Two-Dimensional Coordinate Lists
Eduard J. Groth 1986 AJ 19, 5
http://adsabs.harvard.edu/abs/1986AJ.....91.1244G

The code is here: https://bitbucket.org/sergiopr/gmatch

Regards

2012/5/11 Thomas Robitaille <thomas.robitaille at gmail.com>:
> Hi everyone,
>
> I am looking for a Python package that can do arbitrary and efficient
> cross-matching of source lists, i.e. some kind of kd-tree that uses
> spherical rather than euclidean distances. Is anyone aware of such a
> package?
>
> Thanks,
> Tom
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



-- 
Sergio Pascual ? ? http://guaix.fis.ucm.es/~spr ? ?+34 91 394 5018
gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC
Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain)


From thomas.robitaille at gmail.com  Fri May 11 06:04:23 2012
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Fri, 11 May 2012 12:04:23 +0200
Subject: [AstroPy] Cross matching two source lists
In-Reply-To: <CACta-KZaoapeV46FqKXOs+JxJKmcnDAKxu+styjSOkSUDg=Oow@mail.gmail.com>
References: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>
	<CACta-KZaoapeV46FqKXOs+JxJKmcnDAKxu+styjSOkSUDg=Oow@mail.gmail.com>
Message-ID: <CAGMHX_39YH=WCi0fYJUDhv2=VtSVP4ih3T5_WQOwYW8tCiV9cw@mail.gmail.com>

Hi Sergio,

Thanks for your reply! So it looks like your algorithm only works for
e.g pixel or arcsec coordinates, not e.g. longitude/latitude or
ra/dec, correct? (since for spherical coordinates, even for a small
field of view, the spherical angular distance is not the same as the
euclidean distance, i.e. 1 second of RA is not 15 arcseconds except at
the equator).

For a small field of view, one could do a KDTree using (RA * cos(Dec),
Dec), but I'm interested in finding an algorithm that works for large
areas of sky.

Cheers,
Tom

On 11 May 2012 11:10, Sergio Pascual <sergiopr at fis.ucm.es> wrote:
> Well, I don't know if it's exactly what you are looking for, but,
> after some discussion in this list I created a package that
> implementsthe Groth algorithm for catalogue matching:
>
> A Pattern-Matching Algorithm for Two-Dimensional Coordinate Lists
> Eduard J. Groth 1986 AJ 19, 5
> http://adsabs.harvard.edu/abs/1986AJ.....91.1244G
>
> The code is here: https://bitbucket.org/sergiopr/gmatch
>
> Regards
>
> 2012/5/11 Thomas Robitaille <thomas.robitaille at gmail.com>:
>> Hi everyone,
>>
>> I am looking for a Python package that can do arbitrary and efficient
>> cross-matching of source lists, i.e. some kind of kd-tree that uses
>> spherical rather than euclidean distances. Is anyone aware of such a
>> package?
>>
>> Thanks,
>> Tom
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> --
> Sergio Pascual ? ? http://guaix.fis.ucm.es/~spr ? ?+34 91 394 5018
> gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC
> Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain)


From neilcrighton at gmail.com  Fri May 11 06:11:01 2012
From: neilcrighton at gmail.com (Neil Crighton)
Date: Fri, 11 May 2012 12:11:01 +0200
Subject: [AstroPy] Cross matching two source lists
In-Reply-To: <CAGMHX_39YH=WCi0fYJUDhv2=VtSVP4ih3T5_WQOwYW8tCiV9cw@mail.gmail.com>
References: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>
	<CACta-KZaoapeV46FqKXOs+JxJKmcnDAKxu+styjSOkSUDg=Oow@mail.gmail.com>
	<CAGMHX_39YH=WCi0fYJUDhv2=VtSVP4ih3T5_WQOwYW8tCiV9cw@mail.gmail.com>
Message-ID: <CAFDPQ54neHVaHLakoyfssk+8T8WTJ34o8gO0-wugWwpECO25fg@mail.gmail.com>

There is this:  http://code.google.com/p/astro-stomp/

It's apparently c++ code with a python interface via swig.  I
haven't used it though.

Neil

On 11 May 2012 12:04, Thomas Robitaille <thomas.robitaille at gmail.com> wrote:
> Hi Sergio,
>
> Thanks for your reply! So it looks like your algorithm only works for
> e.g pixel or arcsec coordinates, not e.g. longitude/latitude or
> ra/dec, correct? (since for spherical coordinates, even for a small
> field of view, the spherical angular distance is not the same as the
> euclidean distance, i.e. 1 second of RA is not 15 arcseconds except at
> the equator).
>
> For a small field of view, one could do a KDTree using (RA * cos(Dec),
> Dec), but I'm interested in finding an algorithm that works for large
> areas of sky.
>
> Cheers,
> Tom
>
> On 11 May 2012 11:10, Sergio Pascual <sergiopr at fis.ucm.es> wrote:
>> Well, I don't know if it's exactly what you are looking for, but,
>> after some discussion in this list I created a package that
>> implementsthe Groth algorithm for catalogue matching:
>>
>> A Pattern-Matching Algorithm for Two-Dimensional Coordinate Lists
>> Eduard J. Groth 1986 AJ 19, 5
>> http://adsabs.harvard.edu/abs/1986AJ.....91.1244G
>>
>> The code is here: https://bitbucket.org/sergiopr/gmatch
>>
>> Regards
>>
>> 2012/5/11 Thomas Robitaille <thomas.robitaille at gmail.com>:
>>> Hi everyone,
>>>
>>> I am looking for a Python package that can do arbitrary and efficient
>>> cross-matching of source lists, i.e. some kind of kd-tree that uses
>>> spherical rather than euclidean distances. Is anyone aware of such a
>>> package?
>>>
>>> Thanks,
>>> Tom
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>> --
>> Sergio Pascual ? ? http://guaix.fis.ucm.es/~spr ? ?+34 91 394 5018
>> gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC
>> Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain)
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy


From jerome_caron_astro at ymail.com  Fri May 11 06:32:01 2012
From: jerome_caron_astro at ymail.com (Jerome Caron)
Date: Fri, 11 May 2012 11:32:01 +0100 (BST)
Subject: [AstroPy] Re :  Cross matching two source lists
In-Reply-To: <1336731684.56364.YahooMailNeo@web28802.mail.ir2.yahoo.com>
References: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>
	<CACta-KZaoapeV46FqKXOs+JxJKmcnDAKxu+styjSOkSUDg=Oow@mail.gmail.com>
	<CAGMHX_39YH=WCi0fYJUDhv2=VtSVP4ih3T5_WQOwYW8tCiV9cw@mail.gmail.com>
	<1336731684.56364.YahooMailNeo@web28802.mail.ir2.yahoo.com>
Message-ID: <1336732321.33080.YahooMailNeo@web28803.mail.ir2.yahoo.com>

One option could be to transform the (alpha,delta) with the projection law described here, pp5-6
http://lanl.arxiv.org/pdf/astro-ph/9907229v1.pdf
Jerome

PS: my apologies Thomas, I sent the email too fast to you but not to the list.
?

________________________________
De?: Thomas Robitaille <thomas.robitaille at gmail.com>
??: Sergio Pascual <sergiopr at fis.ucm.es> 
Cc?: astropy mailing list <astropy at scipy.org> 
Envoy? le : Vendredi 11 mai 2012 12h04
Objet?: Re: [AstroPy] Cross matching two source lists

Hi Sergio,

Thanks for your reply! So it looks like your algorithm only works for
e.g pixel or arcsec coordinates, not e.g. longitude/latitude or
ra/dec, correct? (since for spherical coordinates, even for a small
field of view, the spherical angular distance is not the same as the
euclidean distance, i.e. 1 second of RA is not 15 arcseconds except at
the equator).

For a small field of view, one could do a KDTree using (RA * cos(Dec),
Dec), but I'm interested in finding an algorithm that works for large
areas of sky.

Cheers,
Tom

On 11 May 2012 11:10, Sergio Pascual <sergiopr at fis.ucm.es> wrote:
> Well, I don't know if it's exactly what you are looking for, but,
> after some discussion in this list I created a package that
> implementsthe Groth algorithm for catalogue matching:
>
> A Pattern-Matching Algorithm for Two-Dimensional Coordinate Lists
> Eduard J. Groth 1986 AJ 19, 5
> http://adsabs.harvard.edu/abs/1986AJ.....91.1244G
>
> The code is here: https://bitbucket.org/sergiopr/gmatch
>
> Regards
>
> 2012/5/11 Thomas Robitaille <thomas.robitaille at gmail.com>:
>> Hi everyone,
>>
>> I am looking for a Python package that can do arbitrary and efficient
>> cross-matching of source lists, i.e. some kind of kd-tree that uses
>> spherical rather than euclidean distances. Is anyone aware of such a
>> package?
>>
>> Thanks,
>> Tom
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> --
> Sergio Pascual ? ? http://guaix.fis.ucm.es/~spr ? ?+34 91 394 5018
> gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC
> Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain)
_______________________________________________
AstroPy mailing list
AstroPy at scipy.org
http://mail.scipy.org/mailman/listinfo/astropy




It is shape-preserving, and I understand size distorsions are small even for large fields.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120511/21a25aab/attachment.html>

From aldcroft at head.cfa.harvard.edu  Fri May 11 07:05:27 2012
From: aldcroft at head.cfa.harvard.edu (Tom Aldcroft)
Date: Fri, 11 May 2012 07:05:27 -0400
Subject: [AstroPy] Re : Cross matching two source lists
In-Reply-To: <1336732321.33080.YahooMailNeo@web28803.mail.ir2.yahoo.com>
References: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>
	<CACta-KZaoapeV46FqKXOs+JxJKmcnDAKxu+styjSOkSUDg=Oow@mail.gmail.com>
	<CAGMHX_39YH=WCi0fYJUDhv2=VtSVP4ih3T5_WQOwYW8tCiV9cw@mail.gmail.com>
	<1336731684.56364.YahooMailNeo@web28802.mail.ir2.yahoo.com>
	<1336732321.33080.YahooMailNeo@web28803.mail.ir2.yahoo.com>
Message-ID: <CAGsQ-NvgnJLNvAVi3uwmhQFKRiwe3GTps+zF_2KLZV+Q0N=ZQw@mail.gmail.com>

What about using a KDTree with the sources represented as unit vectors
in 3-space (i.e. on the surface of a sphere).  Then the metric is
(roughly) Euclidean over the whole sky as long as you are correlating
sources that are relatively close.  Once you have a matched source
list you could post-filter using exact spherical computations if
needed since this method slightly underestimates the distance.  Just a
thought.  :-)

- Tom

On Fri, May 11, 2012 at 6:32 AM, Jerome Caron
<jerome_caron_astro at ymail.com> wrote:
> One option could be to transform the (alpha,delta) with the projection law
> described here, pp5-6
> http://lanl.arxiv.org/pdf/astro-ph/9907229v1.pdf
> It is shape-preserving, and I understand size distorsions are small even for
> large fields.
> Jerome
>
> PS: my apologies Thomas, I sent the email too fast to you but not to the
> list.
>
> De?: Thomas Robitaille <thomas.robitaille at gmail.com>
> ??: Sergio Pascual <sergiopr at fis.ucm.es>
> Cc?: astropy mailing list <astropy at scipy.org>
> Envoy? le : Vendredi 11 mai 2012 12h04
> Objet?: Re: [AstroPy] Cross matching two source lists
>
> Hi Sergio,
>
> Thanks for your reply! So it looks like your algorithm only works for
> e.g pixel or arcsec coordinates, not e.g. longitude/latitude or
> ra/dec, correct? (since for spherical coordinates, even for a small
> field of view, the spherical angular distance is not the same as the
> euclidean distance, i.e. 1 second of RA is not 15 arcseconds except at
> the equator).
>
> For a small field of view, one could do a KDTree using (RA * cos(Dec),
> Dec), but I'm interested in finding an algorithm that works for large
> areas of sky.
>
> Cheers,
> Tom
>
> On 11 May 2012 11:10, Sergio Pascual <sergiopr at fis.ucm.es> wrote:
>> Well, I don't know if it's exactly what you are looking for, but,
>> after some discussion in this list I created a package that
>> implementsthe Groth algorithm for catalogue matching:
>>
>> A Pattern-Matching Algorithm for Two-Dimensional Coordinate Lists
>> Eduard J. Groth 1986 AJ 19, 5
>> http://adsabs.harvard.edu/abs/1986AJ.....91.1244G
>>
>> The code is here: https://bitbucket.org/sergiopr/gmatch
>>
>> Regards
>>
>> 2012/5/11 Thomas Robitaille <thomas.robitaille at gmail.com>:
>>> Hi everyone,
>>>
>>> I am looking for a Python package that can do arbitrary and efficient
>>> cross-matching of source lists, i.e. some kind of kd-tree that uses
>>> spherical rather than euclidean distances. Is anyone aware of such a
>>> package?
>>>
>>> Thanks,
>>> Tom
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>> --
>> Sergio Pascual ? ? http://guaix.fis.ucm.es/~spr ? ?+34 91 394 5018
>> gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC
>> Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain)
> _______________________________________________
> 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
>


From sergiopr at fis.ucm.es  Fri May 11 07:16:42 2012
From: sergiopr at fis.ucm.es (Sergio Pascual)
Date: Fri, 11 May 2012 13:16:42 +0200
Subject: [AstroPy] Cross matching two source lists
In-Reply-To: <CAGMHX_39YH=WCi0fYJUDhv2=VtSVP4ih3T5_WQOwYW8tCiV9cw@mail.gmail.com>
References: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>
	<CACta-KZaoapeV46FqKXOs+JxJKmcnDAKxu+styjSOkSUDg=Oow@mail.gmail.com>
	<CAGMHX_39YH=WCi0fYJUDhv2=VtSVP4ih3T5_WQOwYW8tCiV9cw@mail.gmail.com>
Message-ID: <CACta-KbXMYB07=bNVeg8TVeDwxJ5LdBLEcGZFgCw_0Pc+a8wMw@mail.gmail.com>

Hi Thomas,

the algorithm, as described by Groth, tries to find similar triangles,
so it won't work well
in large fields where the triangles are not very approximately "flat".

2012/5/11 Thomas Robitaille <thomas.robitaille at gmail.com>:
> Hi Sergio,
>
> Thanks for your reply! So it looks like your algorithm only works for
> e.g pixel or arcsec coordinates, not e.g. longitude/latitude or
> ra/dec, correct? (since for spherical coordinates, even for a small
> field of view, the spherical angular distance is not the same as the
> euclidean distance, i.e. 1 second of RA is not 15 arcseconds except at
> the equator).
>
> For a small field of view, one could do a KDTree using (RA * cos(Dec),
> Dec), but I'm interested in finding an algorithm that works for large
> areas of sky.
>
> Cheers,
> Tom
>
> On 11 May 2012 11:10, Sergio Pascual <sergiopr at fis.ucm.es> wrote:
>> Well, I don't know if it's exactly what you are looking for, but,
>> after some discussion in this list I created a package that
>> implementsthe Groth algorithm for catalogue matching:
>>
>> A Pattern-Matching Algorithm for Two-Dimensional Coordinate Lists
>> Eduard J. Groth 1986 AJ 19, 5
>> http://adsabs.harvard.edu/abs/1986AJ.....91.1244G
>>
>> The code is here: https://bitbucket.org/sergiopr/gmatch
>>
>> Regards
>>
>> 2012/5/11 Thomas Robitaille <thomas.robitaille at gmail.com>:
>>> Hi everyone,
>>>
>>> I am looking for a Python package that can do arbitrary and efficient
>>> cross-matching of source lists, i.e. some kind of kd-tree that uses
>>> spherical rather than euclidean distances. Is anyone aware of such a
>>> package?
>>>
>>> Thanks,
>>> Tom
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>> --
>> Sergio Pascual ? ? http://guaix.fis.ucm.es/~spr ? ?+34 91 394 5018
>> gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC
>> Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain)



-- 
Sergio Pascual ? ? http://guaix.fis.ucm.es/~spr ? ?+34 91 394 5018
gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC
Departamento de Astrof?sica -- Universidad Complutense de Madrid (Spain)


From Christoph.Deil at mpi-hd.mpg.de  Fri May 11 08:30:38 2012
From: Christoph.Deil at mpi-hd.mpg.de (Christoph Deil)
Date: Fri, 11 May 2012 13:30:38 +0100
Subject: [AstroPy] Cross matching two source lists
In-Reply-To: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>
References: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>
Message-ID: <9E5B32B8-8358-43BF-8DC2-CC7340CCBBD6@mpi-hd.mpg.de>

Hi Tom,

STILTS [1] and TOPCAT [2] have excellent cross-matching functionality, provided via the STIL [3] library.
You can browse the code online [4].

Unfortunately it's all Java and can only be accessed from Jython, not CPython [5].

Because all my analysis scripts are CPython I am saving my source lists to FITS files and make an external call to stilts for the cross-matching at the moment.

Having similar functionality in astropy would be great!

Christoph

[1] http://www.star.bris.ac.uk/~mbt/stilts
[2] http://www.star.bris.ac.uk/~mbt/topcat/
[3] http://www.star.bris.ac.uk/~mbt/stil/
[4] http://www.star.bristol.ac.uk/~mbt/stil/javadocs/uk/ac/starlink/table/join/package-summary.html
[5] http://www.star.bris.ac.uk/~mbt/stilts/sun256/sun256.html#jystilts

On May 11, 2012, at 9:03 AM, Thomas Robitaille wrote:

> Hi everyone,
> 
> I am looking for a Python package that can do arbitrary and efficient
> cross-matching of source lists, i.e. some kind of kd-tree that uses
> spherical rather than euclidean distances. Is anyone aware of such a
> package?
> 
> Thanks,
> Tom
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120511/312a229c/attachment.html>

From erin.sheldon at gmail.com  Fri May 11 09:08:27 2012
From: erin.sheldon at gmail.com (Erin Sheldon)
Date: Fri, 11 May 2012 09:08:27 -0400
Subject: [AstroPy] Cross matching two source lists
In-Reply-To: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>
References: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>
Message-ID: <1336741356-sup-102@rohan>

Excerpts from Thomas Robitaille's message of Fri May 11 04:03:18 -0400 2012:
> Hi everyone,
> 
> I am looking for a Python package that can do arbitrary and efficient
> cross-matching of source lists, i.e. some kind of kd-tree that uses
> spherical rather than euclidean distances. Is anyone aware of such a
> package?

Hi Thomas-

The HTM module in esutil does this.

    http://code.google.com/p/esutil/

    http://code.google.com/p/esutil/source/browse/trunk/esutil/htm/__init__.py

It indexes the sky using a Hierarchical Triangular Mesh, which is a
quaternary tree.

Example to find the closest match between two lists within an arcsecond:

    from esutil import htm

    h = htm.HTM()
    maxrad=1.0/3600.0
    m1,m2,radius = h.match(ra1,dec1,ra2,dec2,maxrad)

m1 and m2 are index arrays for the matched pairs and radius is the
match distance.  You can also allow more than one match.

I hope this helps,
-e
-- 
Erin Scott Sheldon
Brookhaven National Laboratory


From eebanado at uc.cl  Fri May 11 09:57:01 2012
From: eebanado at uc.cl (=?ISO-8859-1?Q?Eduardo_Ba=F1ados_Torres?=)
Date: Fri, 11 May 2012 15:57:01 +0200
Subject: [AstroPy] Cross matching two source lists
In-Reply-To: <1336741356-sup-102@rohan>
References: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>
	<1336741356-sup-102@rohan>
Message-ID: <CAE_d_sCo7TY3kXx5bXAGXY7JvPQ10fdDPR24RX5kKT=9n6bWPA@mail.gmail.com>

Hi Thomas,

I'm not sure if this is what you want, but I'm using LSD to
cross-match huge catalogs (3pi of the sky), LSD is written in python
and is multi-thread! so is very fast (though the installation is not
that trivial).

The first line of the documentation is:

The Large Survey Database (LSD) is a framework for storing,
cross-matching, querying, and rapidly iterating through large survey
datasets (catalogs of >109 rows, >1 TB) on multi-core machines. It is
implemented in Python, written and maintained by Mario Juric
(mjuric@?).

all the information is here:
http://mwscience.net/trac/wiki/LargeSurveyDatabase

Well if you need more help or examples you can contact me

and yes.. I also think it would be nice to have a cross-matching
algorithm in astropy

Cheers,


On Fri, May 11, 2012 at 3:08 PM, Erin Sheldon <erin.sheldon at gmail.com> wrote:
> Excerpts from Thomas Robitaille's message of Fri May 11 04:03:18 -0400 2012:
>> Hi everyone,
>>
>> I am looking for a Python package that can do arbitrary and efficient
>> cross-matching of source lists, i.e. some kind of kd-tree that uses
>> spherical rather than euclidean distances. Is anyone aware of such a
>> package?
>
> Hi Thomas-
>
> The HTM module in esutil does this.
>
> ? ?http://code.google.com/p/esutil/
>
> ? ?http://code.google.com/p/esutil/source/browse/trunk/esutil/htm/__init__.py
>
> It indexes the sky using a Hierarchical Triangular Mesh, which is a
> quaternary tree.
>
> Example to find the closest match between two lists within an arcsecond:
>
> ? ?from esutil import htm
>
> ? ?h = htm.HTM()
> ? ?maxrad=1.0/3600.0
> ? ?m1,m2,radius = h.match(ra1,dec1,ra2,dec2,maxrad)
>
> m1 and m2 are index arrays for the matched pairs and radius is the
> match distance. ?You can also allow more than one match.
>
> I hope this helps,
> -e
> --
> Erin Scott Sheldon
> Brookhaven National Laboratory
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



-- 
Eduardo Ba?ados Torres


From jerome_caron_astro at ymail.com  Fri May 11 10:12:10 2012
From: jerome_caron_astro at ymail.com (Jerome Caron)
Date: Fri, 11 May 2012 15:12:10 +0100 (BST)
Subject: [AstroPy] Re :  Cross matching two source lists
References: <CAGMHX_1XTfJy=rjLw5VFaw9eKksVdNo0VQBu=hMEWk9BGFcwOw@mail.gmail.com>
Message-ID: <1336745530.78488.YahooMailNeo@web28802.mail.ir2.yahoo.com>

A side-question linked to matching two lists..
If the coordinate systems between the two lists are already matched, then the most simple algorithm is probably- remove the duplicates, i.e. the same (x2,y2) being paired with two different (x1,y1), and keep the closest pair.
- for each (x1,y1) find the closest (x2,y2) such that dist((x1,y1),(x2,y2))<=criterium
I think t
This occurs for instance with
list1?= (0,0), (3,0)
list2 = (1,0), (2,2)
Then 
findpairs(x1, y1, x2, y2, criterium) -> 1 pair
findpairs(x2, y2, x1, y1, criterium) -> 2 pairs
Sorry for distracting the discussion from the initial thread..
Thankshis algorithm has the feature that findpairs(x1, y1, x2, y2, criterium) and findpairs(x2, y2, x1, y1, criterium) (reversed arguments) may not always return the same results. Is there?any solution to this ?
Jerome


________________________________
De?: Thomas Robitaille <thomas.robitaille at gmail.com>
??: astropy mailing list <astropy at scipy.org> 
Envoy? le : Vendredi 11 mai 2012 10h03
Objet?: [AstroPy] Cross matching two source lists

Hi everyone,

I am looking for a Python package that can do arbitrary and efficient
cross-matching of source lists, i.e. some kind of kd-tree that uses
spherical rather than euclidean distances. Is anyone aware of such a
package?

Thanks,
Tom
_______________________________________________
AstroPy mailing list
AstroPy at scipy.org
http://mail.scipy.org/mailman/listinfo/astropy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120511/a905617e/attachment.html>

From sebas0 at gmail.com  Fri May 11 13:18:53 2012
From: sebas0 at gmail.com (Sebastian)
Date: Fri, 11 May 2012 14:18:53 -0300
Subject: [AstroPy] AstroPy Digest, Vol 69, Issue 19
In-Reply-To: <mailman.1.1336755601.5063.astropy@scipy.org>
References: <mailman.1.1336755601.5063.astropy@scipy.org>
Message-ID: <CAPx0h+kuVZ1E31c1HrfrcdEYcDLLk8xL5y8VRPVoprraBMZUgw@mail.gmail.com>

Response to Message: 1

I have python code I developed with Eric Tollerud and his astropysics that
uses a KD-Tree
for this.

It is very quick. I can pass it to you if you like.

regards,
- Sebastian


On Fri, May 11, 2012 at 2:00 PM, <astropy-request at scipy.org> wrote:

> Send AstroPy mailing list submissions to
>        astropy at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://mail.scipy.org/mailman/listinfo/astropy
> or, via email, send a message with subject or body 'help' to
>        astropy-request at scipy.org
>
> You can reach the person managing the list at
>        astropy-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AstroPy digest..."
>
>
> Today's Topics:
>
>   1. Re: Cross matching two source lists (Christoph Deil)
>   2. Re: Cross matching two source lists (Erin Sheldon)
>   3. Re: Cross matching two source lists (Eduardo Ba?ados Torres)
>   4. Re :  Cross matching two source lists (Jerome Caron)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 11 May 2012 13:30:38 +0100
> From: Christoph Deil <Christoph.Deil at mpi-hd.mpg.de>
> Subject: Re: [AstroPy] Cross matching two source lists
> To: Thomas Robitaille <thomas.robitaille at gmail.com>
> Cc: astropy mailing list <astropy at scipy.org>
> Message-ID: <9E5B32B8-8358-43BF-8DC2-CC7340CCBBD6 at mpi-hd.mpg.de>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Tom,
>
> STILTS [1] and TOPCAT [2] have excellent cross-matching functionality,
> provided via the STIL [3] library.
> You can browse the code online [4].
>
> Unfortunately it's all Java and can only be accessed from Jython, not
> CPython [5].
>
> Because all my analysis scripts are CPython I am saving my source lists to
> FITS files and make an external call to stilts for the cross-matching at
> the moment.
>
> Having similar functionality in astropy would be great!
>
> Christoph
>
> [1] http://www.star.bris.ac.uk/~mbt/stilts
> [2] http://www.star.bris.ac.uk/~mbt/topcat/
> [3] http://www.star.bris.ac.uk/~mbt/stil/
> [4]
> http://www.star.bristol.ac.uk/~mbt/stil/javadocs/uk/ac/starlink/table/join/package-summary.html
> [5] http://www.star.bris.ac.uk/~mbt/stilts/sun256/sun256.html#jystilts
>
> On May 11, 2012, at 9:03 AM, Thomas Robitaille wrote:
>
> > Hi everyone,
> >
> > I am looking for a Python package that can do arbitrary and efficient
> > cross-matching of source lists, i.e. some kind of kd-tree that uses
> > spherical rather than euclidean distances. Is anyone aware of such a
> > package?
> >
> > Thanks,
> > Tom
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/astropy/attachments/20120511/312a229c/attachment-0001.html
>
> ------------------------------
>
> Message: 2
> Date: Fri, 11 May 2012 09:08:27 -0400
> From: Erin Sheldon <erin.sheldon at gmail.com>
> Subject: Re: [AstroPy] Cross matching two source lists
> To: Thomas Robitaille <thomas.robitaille at gmail.com>
> Cc: astropy mailing list <astropy at scipy.org>
> Message-ID: <1336741356-sup-102 at rohan>
> Content-Type: text/plain; charset=UTF-8
>
> Excerpts from Thomas Robitaille's message of Fri May 11 04:03:18 -0400
> 2012:
> > Hi everyone,
> >
> > I am looking for a Python package that can do arbitrary and efficient
> > cross-matching of source lists, i.e. some kind of kd-tree that uses
> > spherical rather than euclidean distances. Is anyone aware of such a
> > package?
>
> Hi Thomas-
>
> The HTM module in esutil does this.
>
>    http://code.google.com/p/esutil/
>
>
> http://code.google.com/p/esutil/source/browse/trunk/esutil/htm/__init__.py
>
> It indexes the sky using a Hierarchical Triangular Mesh, which is a
> quaternary tree.
>
> Example to find the closest match between two lists within an arcsecond:
>
>    from esutil import htm
>
>    h = htm.HTM()
>    maxrad=1.0/3600.0
>    m1,m2,radius = h.match(ra1,dec1,ra2,dec2,maxrad)
>
> m1 and m2 are index arrays for the matched pairs and radius is the
> match distance.  You can also allow more than one match.
>
> I hope this helps,
> -e
> --
> Erin Scott Sheldon
> Brookhaven National Laboratory
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 11 May 2012 15:57:01 +0200
> From: Eduardo Ba?ados Torres <eebanado at uc.cl>
> Subject: Re: [AstroPy] Cross matching two source lists
> To: Erin Sheldon <erin.sheldon at gmail.com>
> Cc: astropy mailing list <astropy at scipy.org>
> Message-ID:
>        <CAE_d_sCo7TY3kXx5bXAGXY7JvPQ10fdDPR24RX5kKT=9n6bWPA at mail.gmail.com
> >
> Content-Type: text/plain; charset=windows-1252
>
> Hi Thomas,
>
> I'm not sure if this is what you want, but I'm using LSD to
> cross-match huge catalogs (3pi of the sky), LSD is written in python
> and is multi-thread! so is very fast (though the installation is not
> that trivial).
>
> The first line of the documentation is:
>
> The Large Survey Database (LSD) is a framework for storing,
> cross-matching, querying, and rapidly iterating through large survey
> datasets (catalogs of >109 rows, >1 TB) on multi-core machines. It is
> implemented in Python, written and maintained by Mario Juric
> (mjuric@?).
>
> all the information is here:
> http://mwscience.net/trac/wiki/LargeSurveyDatabase
>
> Well if you need more help or examples you can contact me
>
> and yes.. I also think it would be nice to have a cross-matching
> algorithm in astropy
>
> Cheers,
>
>
> On Fri, May 11, 2012 at 3:08 PM, Erin Sheldon <erin.sheldon at gmail.com>
> wrote:
> > Excerpts from Thomas Robitaille's message of Fri May 11 04:03:18 -0400
> 2012:
> >> Hi everyone,
> >>
> >> I am looking for a Python package that can do arbitrary and efficient
> >> cross-matching of source lists, i.e. some kind of kd-tree that uses
> >> spherical rather than euclidean distances. Is anyone aware of such a
> >> package?
> >
> > Hi Thomas-
> >
> > The HTM module in esutil does this.
> >
> > ? ?http://code.google.com/p/esutil/
> >
> > ? ?
> http://code.google.com/p/esutil/source/browse/trunk/esutil/htm/__init__.py
> >
> > It indexes the sky using a Hierarchical Triangular Mesh, which is a
> > quaternary tree.
> >
> > Example to find the closest match between two lists within an arcsecond:
> >
> > ? ?from esutil import htm
> >
> > ? ?h = htm.HTM()
> > ? ?maxrad=1.0/3600.0
> > ? ?m1,m2,radius = h.match(ra1,dec1,ra2,dec2,maxrad)
> >
> > m1 and m2 are index arrays for the matched pairs and radius is the
> > match distance. ?You can also allow more than one match.
> >
> > I hope this helps,
> > -e
> > --
> > Erin Scott Sheldon
> > Brookhaven National Laboratory
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > http://mail.scipy.org/mailman/listinfo/astropy
>
>
>
> --
> Eduardo Ba?ados Torres
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 11 May 2012 15:12:10 +0100 (BST)
> From: Jerome Caron <jerome_caron_astro at ymail.com>
> Subject: [AstroPy] Re :  Cross matching two source lists
> To: "astropy at scipy.org" <astropy at scipy.org>
> Message-ID:
>        <1336745530.78488.YahooMailNeo at web28802.mail.ir2.yahoo.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> A side-question linked to matching two lists..
> If the coordinate systems between the two lists are already matched, then
> the most simple algorithm is probably- remove the duplicates, i.e. the same
> (x2,y2) being paired with two different (x1,y1), and keep the closest pair.
> - for each (x1,y1) find the closest (x2,y2) such that
> dist((x1,y1),(x2,y2))<=criterium
> I think t
> This occurs for instance with
> list1?= (0,0), (3,0)
> list2 = (1,0), (2,2)
> Then
> findpairs(x1, y1, x2, y2, criterium) -> 1 pair
> findpairs(x2, y2, x1, y1, criterium) -> 2 pairs
> Sorry for distracting the discussion from the initial thread..
> Thankshis algorithm has the feature that findpairs(x1, y1, x2, y2,
> criterium) and findpairs(x2, y2, x1, y1, criterium) (reversed arguments)
> may not always return the same results. Is there?any solution to this ?
> Jerome
>
>
> ________________________________
> De?: Thomas Robitaille <thomas.robitaille at gmail.com>
> ??: astropy mailing list <astropy at scipy.org>
> Envoy? le : Vendredi 11 mai 2012 10h03
> Objet?: [AstroPy] Cross matching two source lists
>
> Hi everyone,
>
> I am looking for a Python package that can do arbitrary and efficient
> cross-matching of source lists, i.e. some kind of kd-tree that uses
> spherical rather than euclidean distances. Is anyone aware of such a
> package?
>
> Thanks,
> Tom
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.scipy.org/pipermail/astropy/attachments/20120511/a905617e/attachment-0001.html
>
> ------------------------------
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>
>
> End of AstroPy Digest, Vol 69, Issue 19
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120511/f2e72052/attachment.html>

From bkloppenborg at gmail.com  Sat May 12 23:47:29 2012
From: bkloppenborg at gmail.com (Brian Kloppenborg)
Date: Sat, 12 May 2012 21:47:29 -0600
Subject: [AstroPy] astropy.io.fits documentation, suggested rewording
Message-ID: <4FAF2ED1.20703@du.edu>

Greetings,

I was reading over the astropy.io.fits documentation 
(http://astropy.readthedocs.org/en/latest/fits/users_guide/users_tutorial.html) 
today and found the following phrase in the "Working with image data" 
section to be confusing:

> "Note that, like C (and unlike FORTRAN), Python is 0-indexed and the 
> indices have the slowest axis first and fast axis last, i.e. for a 2-D 
> image, the fast axis (X-axis) which corresponds to the FITS NAXIS1 
> keyword, is the second index. Similarly, the 1-indexed sub-section of 
> x=11 to 20 (inclusive) and y=31 to 40 (inclusive) would be given in 
> Python as:"

Perhaps we could rewrite this to refer to the indexing by it's name, 
"row-major order," instead?  This would give interested parties a name 
by which to look it up.

A drop-in replacement for the text and code sections could be:

"""
"Note that Python, like C, is zero-indexed.  The indicies follow 
row-major order (unlike FORTRAN and IDL which use column-major 
indexing).  To access the ith row (FITS NAXIS0) and jth column (FITS 
NAXIS1) one specifies

[code]
 >>> scidata[i,j]
[\code]

When accessing a subarray of pixel data, rows =31 to 40 (inclusive) and 
columns = 11 to 10 (inclusive) it would be done by decrementing the 
starting index by one (to account for the zero-indexed nature of Python) 
and accessing the subarray using a range of rows and columns thusly:

[code]
 >>> scidata[30:40, 10:20]
[\code]
"""

We could also include a link to documentation for interested parties:
http://en.wikipedia.org/wiki/Row-major_order

I don't think the following bit is required, but if someone wanted to, 
we could write this too:

"""
The index of the [i,j] entry of a 2D array of width 'w' is computed by:

index = i * w + j
"""

or something similar.

Regards,
Brian Kloppenborg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120512/b0095df4/attachment.html>

From mdroe at stsci.edu  Mon May 14 10:27:36 2012
From: mdroe at stsci.edu (Michael Droettboom)
Date: Mon, 14 May 2012 10:27:36 -0400
Subject: [AstroPy] Empty char value for PARAM with vo.table
In-Reply-To: <4FABF3E6.7040203@pzzlr.org>
References: <4FABF3E6.7040203@pzzlr.org>
Message-ID: <4FB11658.8080809@stsci.edu>

On 05/10/2012 12:59 PM, Rodney Barnett wrote:
> I'm working with some VOTable files that have tags like this:
>
> <PARAM name="XYZ" datatype="char" arraysize="*" ucd="meta.id;meta.file"
> value=""/>
>
> vo.table.parse reports:
>
> vo.voexceptions.E14: file.xml:213:3: E14: value attribute is required
> for all PARAM elements
>
> The spec is clear that the value attribute is required, but isn't clear
> about whether the value must be non-empty.  Is there a consensus on this?
I think you're right -- it should probably be acceptable to have the 
value attribute provided but empty.

It turns out this is trickier than it sounds -- the expat XML parser 
vo.table uses treats an attribute with an empty value as if the 
attribute doesn't appear at all.  So it's impossible to distinguish 
between the two cases.  I've changed this to a missing attribute will be 
treated as an empty string, which is not strictly correct wrt the 
VOTable spec, but it accepts a class of documents (such as yours) that 
is correct.

The fix is in SVN r2748.

Mike


From embray at stsci.edu  Mon May 14 11:46:06 2012
From: embray at stsci.edu (Erik Bray)
Date: Mon, 14 May 2012 11:46:06 -0400
Subject: [AstroPy] astropy.io.fits documentation, suggested rewording
In-Reply-To: <4FAF2ED1.20703@du.edu>
References: <4FAF2ED1.20703@du.edu>
Message-ID: <4FB128BE.1070503@stsci.edu>

Agreed.  I actually have a bit in the recently added PyFITS FAQ that 
mentions that C/Python, and hence PyFITS use row-major order: 
https://github.com/iguananaut/PyFITS/blob/master/FAQ.txt

It should certainly read that way in the actual docs too.

On 05/12/2012 11:47 PM, Brian Kloppenborg wrote:
> Greetings,
>
> I was reading over the astropy.io.fits documentation
> (http://astropy.readthedocs.org/en/latest/fits/users_guide/users_tutorial.html)
> today and found the following phrase in the "Working with image data"
> section to be confusing:
>
>> "Note that, like C (and unlike FORTRAN), Python is 0-indexed and the
>> indices have the slowest axis first and fast axis last, i.e. for a 2-D
>> image, the fast axis (X-axis) which corresponds to the FITS NAXIS1
>> keyword, is the second index. Similarly, the 1-indexed sub-section of
>> x=11 to 20 (inclusive) and y=31 to 40 (inclusive) would be given in
>> Python as:"
>
> Perhaps we could rewrite this to refer to the indexing by it's name,
> "row-major order," instead? This would give interested parties a name by
> which to look it up.
>
> A drop-in replacement for the text and code sections could be:
>
> """
> "Note that Python, like C, is zero-indexed. The indicies follow
> row-major order (unlike FORTRAN and IDL which use column-major
> indexing). To access the ith row (FITS NAXIS0) and jth column (FITS
> NAXIS1) one specifies
>
> [code]
>  >>> scidata[i,j]
> [\code]
>
> When accessing a subarray of pixel data, rows =31 to 40 (inclusive) and
> columns = 11 to 10 (inclusive) it would be done by decrementing the
> starting index by one (to account for the zero-indexed nature of Python)
> and accessing the subarray using a range of rows and columns thusly:
>
> [code]
>  >>> scidata[30:40, 10:20]
> [\code]
> """
>
> We could also include a link to documentation for interested parties:
> http://en.wikipedia.org/wiki/Row-major_order
>
> I don't think the following bit is required, but if someone wanted to,
> we could write this too:
>
> """
> The index of the [i,j] entry of a 2D array of width 'w' is computed by:
>
> index = i * w + j
> """
>
> or something similar.
>
> Regards,
> Brian Kloppenborg
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From astropy at pzzlr.org  Tue May 15 16:46:00 2012
From: astropy at pzzlr.org (Rodney Barnett)
Date: Tue, 15 May 2012 15:46:00 -0500
Subject: [AstroPy]  Empty char value for PARAM with vo.table
References: 4FABF3E6.7040203@pzzlr.org
Message-ID: <4FB2C088.3070200@pzzlr.org>

Thanks for the change.  Is there a release on the horizon?

Rodney


From mdroe at stsci.edu  Tue May 15 17:49:49 2012
From: mdroe at stsci.edu (Michael Droettboom)
Date: Tue, 15 May 2012 17:49:49 -0400
Subject: [AstroPy] Empty char value for PARAM with vo.table
In-Reply-To: <4FB2C088.3070200@pzzlr.org>
References: 4FABF3E6.7040203@pzzlr.org <4FB2C088.3070200@pzzlr.org>
Message-ID: <4FB2CF7D.6070201@stsci.edu>

It's probably overdue.  There aren't a lot of changes since the last 
version, but I will make a 0.8 release later today.

Mike

On 05/15/2012 04:46 PM, Rodney Barnett wrote:
> Thanks for the change.  Is there a release on the horizon?
>
> Rodney
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy



From astropy at pzzlr.org  Wed May 16 15:47:57 2012
From: astropy at pzzlr.org (Rodney Barnett)
Date: Wed, 16 May 2012 14:47:57 -0500
Subject: [AstroPy]  Empty char value for PARAM with vo.table
References: 4FB2C088.3070200@pzzlr.org
Message-ID: <4FB4046D.5060400@pzzlr.org>

Michael Droettboom wrote:
> It's probably overdue.  There aren't a lot of changes since the last
> version, but I will make a 0.8 release later today.
>
> Mike
> On 05/15/2012 04:46 PM, Rodney Barnett wrote:
>> Thanks for the change.  Is there a release on the horizon?
>>
>> Rodney

Cool!  Thanks much.

Rodney


From erik.tollerud at gmail.com  Wed May 16 18:52:25 2012
From: erik.tollerud at gmail.com (Erik Tollerud)
Date: Wed, 16 May 2012 15:52:25 -0700
Subject: [AstroPy] AstroPy Digest, Vol 69, Issue 19
In-Reply-To: <CAPx0h+kuVZ1E31c1HrfrcdEYcDLLk8xL5y8VRPVoprraBMZUgw@mail.gmail.com>
References: <mailman.1.1336755601.5063.astropy@scipy.org>
	<CAPx0h+kuVZ1E31c1HrfrcdEYcDLLk8xL5y8VRPVoprraBMZUgw@mail.gmail.com>
Message-ID: <CAARXUwUyaYaaFFsisgPL7pzphyeX0z8nW_Oey8t5tinVBMuA2Q@mail.gmail.com>

As an FYI, I'm planning to try to get this added to the Astropy core
package in the near future, as well.

On Fri, May 11, 2012 at 10:18 AM, Sebastian <sebas0 at gmail.com> wrote:
> Response to Message: 1
>
> I have python code I developed with Eric Tollerud and his astropysics that
> uses a KD-Tree
> for this.
>
> It is very quick. I can pass it to you if you like.
>
> regards,
> - Sebastian
>
>
> On Fri, May 11, 2012 at 2:00 PM, <astropy-request at scipy.org> wrote:
>>
>> Send AstroPy mailing list submissions to
>> ? ? ? ?astropy at scipy.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> ? ? ? ?http://mail.scipy.org/mailman/listinfo/astropy
>> or, via email, send a message with subject or body 'help' to
>> ? ? ? ?astropy-request at scipy.org
>>
>> You can reach the person managing the list at
>> ? ? ? ?astropy-owner at scipy.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of AstroPy digest..."
>>
>>
>> Today's Topics:
>>
>> ? 1. Re: Cross matching two source lists (Christoph Deil)
>> ? 2. Re: Cross matching two source lists (Erin Sheldon)
>> ? 3. Re: Cross matching two source lists (Eduardo Ba?ados Torres)
>> ? 4. Re : ?Cross matching two source lists (Jerome Caron)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 11 May 2012 13:30:38 +0100
>> From: Christoph Deil <Christoph.Deil at mpi-hd.mpg.de>
>> Subject: Re: [AstroPy] Cross matching two source lists
>> To: Thomas Robitaille <thomas.robitaille at gmail.com>
>> Cc: astropy mailing list <astropy at scipy.org>
>> Message-ID: <9E5B32B8-8358-43BF-8DC2-CC7340CCBBD6 at mpi-hd.mpg.de>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Hi Tom,
>>
>> STILTS [1] and TOPCAT [2] have excellent cross-matching functionality,
>> provided via the STIL [3] library.
>> You can browse the code online [4].
>>
>> Unfortunately it's all Java and can only be accessed from Jython, not
>> CPython [5].
>>
>> Because all my analysis scripts are CPython I am saving my source lists to
>> FITS files and make an external call to stilts for the cross-matching at the
>> moment.
>>
>> Having similar functionality in astropy would be great!
>>
>> Christoph
>>
>> [1] http://www.star.bris.ac.uk/~mbt/stilts
>> [2] http://www.star.bris.ac.uk/~mbt/topcat/
>> [3] http://www.star.bris.ac.uk/~mbt/stil/
>> [4]
>> http://www.star.bristol.ac.uk/~mbt/stil/javadocs/uk/ac/starlink/table/join/package-summary.html
>> [5] http://www.star.bris.ac.uk/~mbt/stilts/sun256/sun256.html#jystilts
>>
>> On May 11, 2012, at 9:03 AM, Thomas Robitaille wrote:
>>
>> > Hi everyone,
>> >
>> > I am looking for a Python package that can do arbitrary and efficient
>> > cross-matching of source lists, i.e. some kind of kd-tree that uses
>> > spherical rather than euclidean distances. Is anyone aware of such a
>> > package?
>> >
>> > Thanks,
>> > Tom
>> > _______________________________________________
>> > AstroPy mailing list
>> > AstroPy at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/astropy
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://mail.scipy.org/pipermail/astropy/attachments/20120511/312a229c/attachment-0001.html
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Fri, 11 May 2012 09:08:27 -0400
>> From: Erin Sheldon <erin.sheldon at gmail.com>
>> Subject: Re: [AstroPy] Cross matching two source lists
>> To: Thomas Robitaille <thomas.robitaille at gmail.com>
>> Cc: astropy mailing list <astropy at scipy.org>
>> Message-ID: <1336741356-sup-102 at rohan>
>> Content-Type: text/plain; charset=UTF-8
>>
>> Excerpts from Thomas Robitaille's message of Fri May 11 04:03:18 -0400
>> 2012:
>> > Hi everyone,
>> >
>> > I am looking for a Python package that can do arbitrary and efficient
>> > cross-matching of source lists, i.e. some kind of kd-tree that uses
>> > spherical rather than euclidean distances. Is anyone aware of such a
>> > package?
>>
>> Hi Thomas-
>>
>> The HTM module in esutil does this.
>>
>> ? ?http://code.google.com/p/esutil/
>>
>>
>> ?http://code.google.com/p/esutil/source/browse/trunk/esutil/htm/__init__.py
>>
>> It indexes the sky using a Hierarchical Triangular Mesh, which is a
>> quaternary tree.
>>
>> Example to find the closest match between two lists within an arcsecond:
>>
>> ? ?from esutil import htm
>>
>> ? ?h = htm.HTM()
>> ? ?maxrad=1.0/3600.0
>> ? ?m1,m2,radius = h.match(ra1,dec1,ra2,dec2,maxrad)
>>
>> m1 and m2 are index arrays for the matched pairs and radius is the
>> match distance. ?You can also allow more than one match.
>>
>> I hope this helps,
>> -e
>> --
>> Erin Scott Sheldon
>> Brookhaven National Laboratory
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Fri, 11 May 2012 15:57:01 +0200
>> From: Eduardo Ba?ados Torres <eebanado at uc.cl>
>> Subject: Re: [AstroPy] Cross matching two source lists
>> To: Erin Sheldon <erin.sheldon at gmail.com>
>> Cc: astropy mailing list <astropy at scipy.org>
>> Message-ID:
>>
>> ?<CAE_d_sCo7TY3kXx5bXAGXY7JvPQ10fdDPR24RX5kKT=9n6bWPA at mail.gmail.com>
>> Content-Type: text/plain; charset=windows-1252
>>
>> Hi Thomas,
>>
>> I'm not sure if this is what you want, but I'm using LSD to
>> cross-match huge catalogs (3pi of the sky), LSD is written in python
>> and is multi-thread! so is very fast (though the installation is not
>> that trivial).
>>
>> The first line of the documentation is:
>>
>> The Large Survey Database (LSD) is a framework for storing,
>> cross-matching, querying, and rapidly iterating through large survey
>> datasets (catalogs of >109 rows, >1 TB) on multi-core machines. It is
>> implemented in Python, written and maintained by Mario Juric
>> (mjuric@?).
>>
>> all the information is here:
>> http://mwscience.net/trac/wiki/LargeSurveyDatabase
>>
>> Well if you need more help or examples you can contact me
>>
>> and yes.. I also think it would be nice to have a cross-matching
>> algorithm in astropy
>>
>> Cheers,
>>
>>
>> On Fri, May 11, 2012 at 3:08 PM, Erin Sheldon <erin.sheldon at gmail.com>
>> wrote:
>> > Excerpts from Thomas Robitaille's message of Fri May 11 04:03:18 -0400
>> > 2012:
>> >> Hi everyone,
>> >>
>> >> I am looking for a Python package that can do arbitrary and efficient
>> >> cross-matching of source lists, i.e. some kind of kd-tree that uses
>> >> spherical rather than euclidean distances. Is anyone aware of such a
>> >> package?
>> >
>> > Hi Thomas-
>> >
>> > The HTM module in esutil does this.
>> >
>> > ? ?http://code.google.com/p/esutil/
>> >
>> > ?
>> > ?http://code.google.com/p/esutil/source/browse/trunk/esutil/htm/__init__.py
>> >
>> > It indexes the sky using a Hierarchical Triangular Mesh, which is a
>> > quaternary tree.
>> >
>> > Example to find the closest match between two lists within an arcsecond:
>> >
>> > ? ?from esutil import htm
>> >
>> > ? ?h = htm.HTM()
>> > ? ?maxrad=1.0/3600.0
>> > ? ?m1,m2,radius = h.match(ra1,dec1,ra2,dec2,maxrad)
>> >
>> > m1 and m2 are index arrays for the matched pairs and radius is the
>> > match distance. ?You can also allow more than one match.
>> >
>> > I hope this helps,
>> > -e
>> > --
>> > Erin Scott Sheldon
>> > Brookhaven National Laboratory
>> > _______________________________________________
>> > AstroPy mailing list
>> > AstroPy at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>>
>> --
>> Eduardo Ba?ados Torres
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Fri, 11 May 2012 15:12:10 +0100 (BST)
>> From: Jerome Caron <jerome_caron_astro at ymail.com>
>> Subject: [AstroPy] Re : ?Cross matching two source lists
>> To: "astropy at scipy.org" <astropy at scipy.org>
>> Message-ID:
>> ? ? ? ?<1336745530.78488.YahooMailNeo at web28802.mail.ir2.yahoo.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> A side-question linked to matching two lists..
>> If the coordinate systems between the two lists are already matched, then
>> the most simple algorithm is probably- remove the duplicates, i.e. the same
>> (x2,y2) being paired with two different (x1,y1), and keep the closest pair.
>> - for each (x1,y1) find the closest (x2,y2) such that
>> dist((x1,y1),(x2,y2))<=criterium
>> I think t
>> This occurs for instance with
>> list1?= (0,0), (3,0)
>> list2 = (1,0), (2,2)
>> Then
>> findpairs(x1, y1, x2, y2, criterium) -> 1 pair
>> findpairs(x2, y2, x1, y1, criterium) -> 2 pairs
>> Sorry for distracting the discussion from the initial thread..
>> Thankshis algorithm has the feature that findpairs(x1, y1, x2, y2,
>> criterium) and findpairs(x2, y2, x1, y1, criterium) (reversed arguments) may
>> not always return the same results. Is there?any solution to this ?
>> Jerome
>>
>>
>> ________________________________
>> De?: Thomas Robitaille <thomas.robitaille at gmail.com>
>> ??: astropy mailing list <astropy at scipy.org>
>> Envoy? le : Vendredi 11 mai 2012 10h03
>> Objet?: [AstroPy] Cross matching two source lists
>>
>> Hi everyone,
>>
>> I am looking for a Python package that can do arbitrary and efficient
>> cross-matching of source lists, i.e. some kind of kd-tree that uses
>> spherical rather than euclidean distances. Is anyone aware of such a
>> package?
>>
>> Thanks,
>> Tom
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://mail.scipy.org/pipermail/astropy/attachments/20120511/a905617e/attachment-0001.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> AstroPy mailing list
>> AstroPy at scipy.org
>> http://mail.scipy.org/mailman/listinfo/astropy
>>
>>
>> End of AstroPy Digest, Vol 69, Issue 19
>> ***************************************
>
>
>
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy
>



-- 
Erik Tollerud


From perry at stsci.edu  Fri May 18 09:23:07 2012
From: perry at stsci.edu (Perry Greenfield)
Date: Fri, 18 May 2012 09:23:07 -0400
Subject: [AstroPy] next astropy coordination meeting
In-Reply-To: <FDD42FE0-B5C8-461E-8921-5C25246FE202@stsci.edu>
References: <4CDE33A0-C6D8-47D7-886E-1BE0EBBD6E90@stsci.edu>
	<FDD42FE0-B5C8-461E-8921-5C25246FE202@stsci.edu>
Message-ID: <76F941C0-F476-44F9-B758-37850441EE30@stsci.edu>

Just a reminder that the poll closes today

On May 3, 2012, at 11:24 AM, Perry Greenfield wrote:

> We would like to hold the second Astropy Coordination meeting in  
> October at
> STScI (the first was held last October at CFA; the minutes can be  
> viewed at:
> https://github.com/astropy/astropy/wiki/CfAMeeting2011Minutes.)
>
> The goal for the meeting is to coordinate software efforts in  
> improving and
> expanding astropy. It is planned as a two-day meeting. Currently  
> these three
> sets of dates are available:
>
> Tuesday - Wednesday  Oct. 2-3
> Tuesday - Wednesday  Oct. 9-10
> Tuesday - Wednesday  Oct. 23-24
>
> We'd like to know who is interested in attending the meeting and  
> which dates
> are acceptable. A doodle poll has been set up; only the first day of  
> each
> week has been given as a choice to indicate you can make the meeting  
> that
> week. Please fill out the poll if you are interested in attending the
> meeting but can't make any of dates. The poll will be kept open for  
> just over
> two weeks and will close at the end of Friday, May 18.
>
> The link to the poll is: http://www.doodle.com/auvfbs6f4iiyt9cb
>
> Tentative topics to be addressed at the coordination meeting
> (subject to revision depending on interest of attendees):
>
> * The current state of the Astropy core package
> - What subpackages need to be improved?
> - What new subpackages need to be made?
> - How should we phase out stand-alone versions?
> * Advocacy and communication to the community
> * Highest priorities for additions to astropy
> - who will be the advocate/coordinator for each?
> * What existing packages should we target for making affiliated  
> packages?
> - What offer will they not be able to refuse?
> * Improving interoperability of affiliated packages
> - E.g., supporting standard data objects (ND-datasets, spectra...) and
>   metadata conventions
>
>



From international.d.egy at gmail.com  Sun May 20 12:11:09 2012
From: international.d.egy at gmail.com (International Distributors)
Date: Sun, 20 May 2012 19:11:09 +0300
Subject: [AstroPy] Sole agent and distribution
In-Reply-To: <CAPogVW9roGTi4eXqATT9EpkdTsS6qJxdLSAvin1GZiggicQm6w@mail.gmail.com>
References: <CAPogVW-G4_67iib2o+OkZ7G-28M-4UDjk97L1NUZ+p5LLRdNkA@mail.gmail.com>
	<CAPogVW9roGTi4eXqATT9EpkdTsS6qJxdLSAvin1GZiggicQm6w@mail.gmail.com>
Message-ID: <CAPogVW-AY_c8bBJedGBFcufcd-c7AOyM5YqjnoASSojXuZNvYw@mail.gmail.com>

*
*
*Dear Sir - Mme,*
*
*
*Great day 2 u,*
*
*
*We have the pleasure 2 introduce our company 2 u,*
*
*
*We r PROMO ACTIVE 2 sister companies from EGYPT,*
*1- Distributor and sole agent for brand names products in Egypt*
*2- Advertising agency ( www.promoactive-pa.com )*
*
*
*We would like to have ur products in the Egyptian market*
*If u r interested plz feel free 2 contact me*
*
*
*Regards,*
*Ahmed ARAFA*
*0020 1001151129*
*international.d.egy at gmail.com*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20120520/42336338/attachment.html>

From thomas.robitaille at gmail.com  Mon May 21 10:12:31 2012
From: thomas.robitaille at gmail.com (Thomas Robitaille)
Date: Mon, 21 May 2012 16:12:31 +0200
Subject: [AstroPy] ATpy 0.9.6 Release
Message-ID: <CAGMHX_1CntB99tmEyYx4edKF2-F9pGdM8h-Vgj_2WRcwPrfp5A@mail.gmail.com>

We are pleased to announce the release of ATpy 0.9.6!

ATpy is a high-level Python package providing a generic Table class that
can contain data and meta-data, and includes column manipulation, row
selection, and sorting methods. In addition, read and write methods are
provided to seamlessly read and write table data to a number of formats,
building on existing Python modules. More information and links to
download the latest version of ATpy can be found at
http://atpy.github.com/

In addition to a number of bug fixes, this version now makes it easy to
open files using http:// and ftp:// URLs as filenames, and to expand
gzip and bzip2-compressed data on-the-fly. In addition, ATpy 0.9.6
should be fully Python 3 compatible!

To update using pip:

  pip install --upgrade atpy

Alternatively, if you use MacPorts to manage your Python installation,
you can do for example:

  sudo port selfupdate
  sudo port upgrade py27-atpy

Please do not hesitate to let us know if you encounter any problems with
this release,

Cheers,

Thomas Robitaille and Eli Bressert


From bertrand.goldman at normalesup.org  Wed May 23 16:54:20 2012
From: bertrand.goldman at normalesup.org (Bertrand Goldman)
Date: Wed, 23 May 2012 22:54:20 +0200
Subject: [AstroPy] UVW conversion
Message-ID: <4FBD4E7C.2030306@normalesup.org>

Hello,

   I'm looking into transformations from UVW galactocentric space 
velocities into proper motions. Is there a python program that does that?

   Thanks in advance,
     Bertrand.