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

Adrian Price-Whelan adrianmpw at gmail.com
Wed May 2 22:49:44 EDT 2012

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>

More information about the AstroPy mailing list