Constellation data

The class used to integrate these data in java classes is BuildConstellations.java (see source code or javadoc).
All declinations and right ascensions were stored in radians. It will perharps be useful to rebuild the data files in order to store data already precessed to J2000.
To do : check if there is no loss of precision when storing the data in radians (String - double conversion).

Integration to JEphem

The main class to access to constellation informations is an abstract class : jephem.astro.sky.Constellations.
The call to methods of this class use constants of jephem.astro.sky.ConstellationConstants.
ConstellationConstants contains references to the official constellations and two supplementary constants : SerA and SerB, which refer to Serpens Caput and Serpens Cauda. This was necessary because Serpens constellation is made of two distinct areas.

Boundaries

Constellations were delimited in 1930 by Eugène Delporte (Délimitation scientifique des constellations, Delporte 1930, Cambridge University Press) ; I couldn't find an electronic version of this document on the web.

I first retrieved ConstBoundary.dat, which contains the data for the boundaries, from find the adress.org. The format is HH MM SS for ra and DD MM SS for dec.
I don't know where this file comes from (maybe a CDRom), and have no doc. about the data. This file can be retrieved from the download area. If you know its origin, thanks to let me know.
Then I found the files from A.C. Davenhall and S.K. Leggett (ftp://adc.gsfc.nasa.gov/pub/adc/archives/catalogs/6/6049/). The coordinates are in decimal format.

Which file to choose ?

Constellation boundaries are arbitrary data, so they are exact by definition. ConstBoundary.dat is then more precise.
But here is an extract of constell.doc, from Davenhall and Leggett work :
(...) In equator and equinox 1875 the lines joining the corners of the constellations
were great circles of right ascension and parallels of declination.  However,
precession to equator and equinox 2000 distorts the boundaries so that they
no longer lie along lines of constant right ascension or declination.  Thus,
prior to precession to equator and equinox 2000, points were interpolated at
one degree intervals along the boundaries in order that they should continue
to enclose the same area of sky (and thus the same set of stars).
I don't understand the need of an interpolation. Anyway, I only had ConstBoundary.dat when I coded, and used these data, which give à priori coherent graphical results.
To do : find out about this interpolation.

Names

For latin names, I used the page "Names and Standard Abbreviations of Constellations" of the IAU site at http://www.iau.org/IAU/Activities/nomenclature/const.html.
English names come from the help of SkyMapPro.
French names come from

Identification of a Constellation from a Position

An other interesting work is Identification of a Constellation from a Position, by Nancy G. Roman, Publications of the Astronomical Society of the Pacific 99, pp 695-699, july 1987. The article, the data files and example program can be found at ftp://cdsarc.u-strasbg.fr/pub/cats/VI/42/.
The article tells how to use the file data.dat, but does not describe the method used to generate it.
Question : is this method available somewhere?

Trying to restore the precision

In the data file (data.dat), data are given in decimal form, with 4 digits.
This corresponds to a precision of 3600 * 10-4 * 15 = 5,4 arc seconds for right ascensions and 3600 * 10-4 = 0.36 arc seconds for declinations.
This can be a problem for date searching routines (ex : find when Pluto transits a constellation boundary).
I supposed that the data in data.dat were obtained from other data, expressed with a precision of one second (time second for r.a. and arc second for dec.) and that the differences with exact data were coming from rounding process.
So buildRomanData() calls the private methods reformatRa() and reformatDec() to convert the data in format HH MM SS (for r.a.) or sDD MM SS (for dec.).
The seconds were computed rounding to the nearest integer.
When the original values were different from the generated values, I looked at the differences. The maximal error found is 1.8 arc second for r.a and 0.12 arc second for dec..
Curiously, the data of data.dat do not necessarily correspond to values of ConstBoundary.dat..