[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Survey: utility of packaging Hipparcos star catalog?


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

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

Reply to: