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