Hi, you're receiving this email because you are either subscribed to debian-science or you maintain a package that was tagged "field::astronomy" and looked like it might be relevant. I'm thinking of packaging the Hipparcos star catalog [1] for Debian. It is already included in the stellarium-data, celestia-common and kstars-data packages [2,3,4] in some form, but it is in a binary format in the first two of these, and it seems to me that it might be useful to have the untouched original version available in a more general-purpose package. Since users can easily download it themselves from [1], the main point would be for use in Depends or Build-Depends(-Indep). Hence this survey. If you reply, please do so to debian-science@lists.debian.org. [1] http://cdsarc.u-strasbg.fr/viz-bin/Cat?I/239 [2] http://packages.debian.org/sid/stellarium-data [3] http://packages.debian.org/sid/celestia-common [4] http://packages.debian.org/sid/kstars-data * Question 0: Does (or can) the astronomy software you maintain make use of the Hipparcos data in any way? (If not, there's no need to reply, although you can of course weigh in anyway. Note, I consider the much larger Tycho catalog [5] to be separate and have no plan to package it.) [5] ftp://cdsarc.u-strasbg.fr/pub/cats/I/239/tyc_main.dat.gz * Question 1: Can your software make use of the Hipparcos catalog exactly in its original format (the original version of the main file is at [6] for instance -- assume it would be gunzipped), with no transformation to a different format? [6] ftp://cdsarc.u-strasbg.fr/pub/cats/I/239/hip_main.dat.gz * Question 2: If "no" to question 1, then is it possible to recreate the file(s) in the format used by your software from the raw Hipparcos data programmatically? For instance, if upstream has written a script that can automatically convert the hip_main.dat file to some_file(s)_your_program_reads.txt, perhaps with the help of some additional auxiliary input files. (I would assume that stellarium and celestia upstreams must have some way of generating /usr/share/stellarium/stars/default/*.cat and /usr/share/celestia/data/stars.dat, respectively, from the Hipparcos files. Unfortunately it looks like the files in kstars-data were edited by hand to a large degree.) * Question 3a: If "yes" to either question 1 or 2, would your software or transformative script/program be able to cope with the hip_main.dat file being split into several smaller files in the Debian-packaged version? (I might do this in order to permit people who are low on disk space to install only the part of the catalog including, say, stars within 30 parsecs of Earth.) * Question 3b: Does your answer to 3a depend on the exact way in which the hip_main.dat file is split up (i.e., which stars go into which piece)? * Question 4: If "yes" to question 2, would it make more sense for you to (a) Build-Depend upon a Hipparcos catalog and generate your own foo-data Debian package, or (b) do the transformation on the user's computer in a postinst script at install-time? The former has the downside of filling ftp.debian.org with multiple copies of the Hipparcos catalog in various formats. The latter has the disadvantage of making the local admin wait, possibly for a long time, while the package-specific version of the catalog is generated. There is support for the latter via the stardata-common package [7,8]. [7] http://packages.debian.org/sid/stardata-common [8] http://alioth.debian.org/plugins/scmcvs/cvsweb.php/stardata-common/doc/policy.txt?rev=1.1;content-type=text%2Fplain;cvsroot=stardata-common;only_with_tag=HEAD You can of course answer (c) "neither" to this question if you want to keep shipping the files that upstream provides in both your source and binary packages -- the Hipparcos catalog is basically public-domain so that's perfectly OK. Thanks very much for your time. best regards, -- Kevin B. McCarty <kmccarty@gmail.com> WWW: http://www.starplot.org/ WWW: http://people.debian.org/~kmccarty/ GPG: public key ID 4F83C751
Attachment:
signature.asc
Description: OpenPGP digital signature