[AstroPy] Co-ordinating Python astronomy libraries?
Fri Jul 16 09:01:56 CDT 2010
On 07/16/2010 09:38 AM, Wolfgang Kerzendorf wrote:
> Looking forward to that. I'm wondering if PyWCS should be able to read
> wavelength solutions (I think they could be considered WCS as well).
I believe it does. As pywcs is just a wrapper around wcslib, it does
most everything wcslib does.
> I have always wrapped wcstools (in a very crude way by calling them on
> the command line) and I found that they could handle nearly anything. I
> know they are under GPL and Mike D. regarded this as a problem. Is it
> still a problem?
Both wcslib is under the LGPL. wcstools appears to be under the GPL,
though its libwcs is under the LGPL. We tend to prefer more open licenses.
> On 16/07/10 2:35 PM, Perry Greenfield wrote:
>> I'd like to tackle the WCS issue first since there are already several
>> flavors out there and I really wonder if that is necessary. Mike
>> Droettboom is going to take a look at the others and see what the
>> differences are in the next week. It would be good to get some
>> convergence on that.
>> But I don't think that can stop others from surveying and comparing
>> what is out there with regard to coordinates or time.
>> As far as the pure python aspect goes, I don't know if I would be so
>> definitive on that. If there is already a good time or coordinates
>> library in C that has been very well tested, it might make sense to
>> use that. It isn't usually a big deal to distribute C code if it has
>> no other dependencies. Fortran is a different issue. And there are
>> many tricky issues with regard to coordinate systems. If reimplemented
>> in pure python I'd suggest that we do a exhaustive test comparison
>> (mostly automatically generated if possible) with a well tested
>> library to make sure that it was well validated.
>> On Jul 16, 2010, at 5:01 AM, Wolfgang Kerzendorf wrote:
>>> Hello guys,
>>> I think astropysics looks like a very good start for the coordinate
>>> As you said we should at the moment focus on having python-only classes
>>> for the base-level. That makes it easy to distribute. Once a good API
>>> has been established and there's complaints about speed, we can switch
>>> over to c or fortran implementations with the same API.
>>> A monolithic distribution is not so good. I think these baselevel
>>> classes should, be very modular. We can probably achieve the best
>>> exceptance when these base classes are lean and mean. Like the unix
>>> tools, each one of them should only provide a very limited set of
>>> functionality. A good start might be pyAstroTime and pyAstroCoords or
>>> so. That's where raiding and plundering the existing code base comes in.
>>> We can use some of Erik's and Brandon's stuff and others. I think we can
>>> easily make a working prototype and the build from there.
>>> As suggested, we need to be careful not to ignore anyone. But I think
>>> that's easily done by making groups from this community, that take care
>>> of a single implementation. Everyone who's interested in contributing,
>>> can join. That way the workload is shared and it is build by the
>>> community for the community.
>>> What do you guys think?
> AstroPy mailing list
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
More information about the AstroPy