brandon-rhodes / pyephem

Scientific-grade astronomy routines for Python
Other
783 stars 121 forks source link

Fixes for pyephem/bin/rebuild-star-data #244

Open Bernmeister opened 2 years ago

Bernmeister commented 2 years ago

When I ran pyephem/bin/rebuild-star-data I found some errors. I suspect the format of the source data has changed. Here is a patch:

55,56c55,56
<     line = line.decode('utf-8')
<     if line.startswith('#'):
---
>     line = line.decode('utf-8').strip()
>     if line.startswith('#') or line.startswith('$') or len(line) == 0:
58,59c58,59
<     name = line[0:18].strip()
<     hip = line[86:93].strip()
---
>     name = line[0:17].strip() # 1 - 17 -> 0 - 16 -> 0 - 17
>     hip = line[90:96].strip() # 91 - 96 -> 90 - 95 -> 90 - 96
69c69
< with load.open(hipparcos.URL) as f:
---
> with load.open(hipparcos.URL) as f: # DOES NOT WORK; USED LOCAL hip_main.dat
72c72
< with load.open(hipparcos.URL) as f:
---
> with load.open(hipparcos.URL) as f: # DOES NOT WORK; USED LOCAL hip_main.dat

In short there are three issues:

  1. Handle white space and non-comment lines.
  2. Indexing of fields is off.
  3. I had to use a local copy of hip_main.dat as the hipparcos.URL seems busted.

Bonus question: In pyephem/ephem/stars.py there is the object STAR_NUMBER_NAME containing, for example, the star Acamar with corresponding number 7. What is this number? I initially presumed to be the HIP which is 13847, but that does not match...

EDIT: Another bonus question: When the line is constructed, the spectral type component raw_row['SpType'][:2] must be a two character string (I found this contraint buried in _libastro.c). I'm creating my own star data and for the star/quasar 3C 273 (HIP 60936) the spectral data comes back as empty (a float NaN). So I replaced this with an empty string of length two and then created a body for that star/quasar in PyEphem and compared against Skyfield using hip_main.dat and the rise/set/az/alt match up. So it seems substituting in an empty string of length two for a missing spectral type is safe...is it?

EDIT: Looking at the source data just now, the columns are not quite all aligned, so some stars will trip up the indices I've given above! Only saving grace I suppose is that generating a new list of stars should be seldom at most.