[Stardata-common-devel] Survey: utility of packaging Hipparcos star catalog?

[Justin Pryzby]

On Thu, Apr 10, 2008 at 04:16:53PM -0700, Kevin B. McCarty wrote:

> I'm thinking of packaging the Hipparcos star catalog [1] for Debian.
That sounds great.

> 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.
I think those packages should (as you said) ultimately Depend on the
data package, and either be patched as needed to use that datafile or
run a postinst transformation script if that's really warrented.

> * Question 0: Does (or can) the astronomy software you maintain make use
> of the Hipparcos data in any way?
I maintain sextractor (for "source extraction", or detecting stars and
galaxies in images) and, until the QA group recently (and justifiably)
orphaned it, the saods9 image viewer.  I hope to continue its
maintenance in the future, but it's a difficult package (for reasons
documented in #465959).

sextractor isn't useful without images, however it can be useful to
combine images with pre-existing astrometric positions for computing
WCS transformation parameters for an image, after running sextractor
on it.  However I don't think hipparcos is anywhere near large enough
to be used as coordinate mapping input (I think USNO-B1 or NOMAD are
currently preferred in the general case).

Neither can DS9 directly make use of starlists, however given a list
of stars (eg. from known astrometric positions or output by
sextractor) it's possible to run something like: 

	<./star.pos awk '{print $2,$3}' |
	  sed -e 's/^/circle /' -e 's/$/ 7 +#color=red/' |
	  xpaset ds9 regions

That will put circles around the star positions from ./star.pos.
Again, however, Hipparcos is probably too sparse of a catalog to be
more than marginally useful in that context.

> * 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.)
I don't think it makes sense to split, there's too many ways to do it
and I can't think of any way that's going to be useful to any
substantial fraction of people.  Datafiles (for astronomy in
particular) can be quite large and Hipparcos is relatively small.  It
might be worth discussing the best way to store these catalogs for
consistency with the ones that might be huge.  Perhaps the catalog
should be stored compressed or in binary format, and perhaps tools
should be provided for querying/extracting them, or even accessing or
retrieving remote data.

FYI, last year I wrote a query tool for the AAVSO's local copy of
USNO-B1, which is stored in uncompressed, binary format.  There's a
set of files for each 0.1 degree of declination; each file is sorted
by RA, and has an associated "lookup" file (which can be fseek()d)
which stores the offset in the datafile of the first record with a RA
for each 0.25 hours.  http://www.nofs.navy.mil/nomad/nomad_readme.html

Justin