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:
Handle white space and non-comment lines.
Indexing of fields is off.
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.
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:In short there are three issues:
hip_main.dat
as thehipparcos.URL
seems busted.Bonus question: In
pyephem/ephem/stars.py
there is the objectSTAR_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/quasar3C 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 inPyEphem
and compared againstSkyfield
usinghip_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.