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