startextdump doesn't output spherical coordinates

[LukeCEL]

Hi everyone,

I'm trying to get startextdump to output spherical coordinates (RA, Dec, Distance). However, when I type this into the command line:

Code: Select all

startextdump -s stars.dat

I get just the normal output options (x, y, z). I have also tried doing

Code: Select all

startextdump --spherical stars.dat

and changing

Code: Select all

static bool useSphericalCoords = false;

in line 27 to true. However, nothing seems to work, and it still outputs x, y, and z. What am I doing wrong?

Thanks,
Luke

[Janus]

That file does not contain the information you are looking for.
It is the result of formulaic conversion of polar coords {Ra, Dec, Dist} into rectangular {x,y,z} then output into a binary format.

If you are looking for the polar coords, here.
Grab the file below, hip2.dat.gz, then extract hip2.dat from it.
Load it into a speadsheet or import it into a database if you like.
Parse using the following guide. {Taken from stardb.pl in the source tree.}
The first column is the HIP#, the rest as follows.

Code: Select all

   my %star = (
      'RArad'    => substr($curLine,  15, 13),
      'DErad'    => substr($curLine,  29, 13),
      'Plx'      => substr($curLine,  43,  7),
      'e_RArad'  => substr($curLine,  69,  6),
      'e_DErad'  => substr($curLine,  76,  6),
      'e_Plx'    => substr($curLine,  83,  6),
      'Hpmag'    => substr($curLine, 129,  7),
      'B-V'      => substr($curLine, 152,  6)
      );
Note: 15+13 = 28, 29+13 = 42, just to clarify how substr works in perl.


And you will have a list of polar coords.
Warning, parallax is computed by LY = 3.26156 * (1/Plx) if you want direct distance.

Merge with the dump you already have using HIP# as the common key, and you have it all in one place.
I hope that gives you what you need.

Sorry about short reply, but still getting the spherical projection coded to compile with VS2015.
Needed a break from a frustrating job, and now it is getting frustrating as well.


Janus.

[LukeCEL]

Hi Janus, this is not exactly what I'm looking for.

The reason I need stars.txt to be in exactly this format is because I was trying to generate a new catalog of stellar radii (jsdc.stc) using Andrew Tribick's new stars.dat. His file uses distances that AFAIK, are the most accurate and up-to-date.

Thanks anyway,
Luke

Added after 1 minute 21 seconds:
I did end up making an updated jsdc.stc by slightly tweaking the jsdc.pl I used. Here's the updated version, anyway:

[ajtribick]

Looking at the code, the useSpherical parameter is only passed to DumpOldStarDatabase, which as the name implies only handles the older format. At that time stars.dat contained the HD cross-index and stored coordinates as (right ascension, declination, parallax). I believe the reason for the change to storing Cartesian coordinates was because differences in the trigonometric functions made it impossible for cel URLs to work across different machines even when the same star database was used.

[LukeCEL]

Very interesting, thank you for that.

I saw this bit of code:

Code: Select all

            else if (!strcmp(argv[i], "-s") || !strcmp(argv[i], "--spherical"))
            {
                useSphericalCoords = true;
            }


which made me assume that I needed to set useSphericalCoords to true. But if useSphericalCoords is only passed to DumpOldStarDatabase, does that mean that the "--spherical" argument does not work for the new stars.txt format?

[ajtribick]

Yes, the function DumpStarDatabase (used for the current star database format) is blissfully unaware of the existence of useSpherical.

Once you extract x, y and z from the file, the distance is easy to calculate from the usual Euclidean formula (x²+y²+z²). Extracting the right ascension and declination is somewhat complicated by the fact that the stored coordinates are in a left-handed (I think?) ecliptic frame rather than equatorial.

So you invert the transformation given in the Celestia wikibook (the matrix is a rotation matrix, so just negate the angle ε), then use atan2 and other inverse trigonometric functions to extract the angles.

[LukeCEL]

Thanks for the information! I've submitted a bug report on GitHub.

[LukeCEL]

I noticed a strange issue with startextdump. If I try to output startextdump's result as a file, such as like this:

Code: Select all

startextdump stars.dat output.txt

the file is cut off near the very end. For example with the default stars.dat, even though the last line should be HIP 120404, the last line looks like this:

Code: Select all

118249 554.5157 -769.9752 336.2617 0.0

What is happening here? Is anybody else able to confirm this bug?

[ajtribick]

Interesting... looking at the code I see what's going on: the ofstream is created on the heap via operator new and it is not deleted at the end of the program. So the ofstream destructor doesn't get called and the stream doesn't get flushed. There are no explicit calls to flush the stream either.

This kind of thing is why it is recommended to avoid calling new and delete explicitly in modern C++.

The export of the HD cross-index from old-format database files (which contained the HD identifier in stars.dat) would exhibit the same problem, but unless you're doing archaeology on really old Celestia versions that shouldn't be too much of an issue.

It looks like you don't actually have to specify an output file, in which case the output will be to stdout. This can then be redirected to a file, so the following should do what you want:

Code: Select all

startextdump stars.dat > output.txt

[LukeCEL]

Huh, that is weird indeed. At least here the solution seems obvious: just update the documentation to the correct syntax.

Does the same output problem exist for other stardb tools, such as makestardb and makexindex?

[ajtribick]

makestardb looks ok.
makexindex has the same issue.