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

[Erik Tollerud]

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