stars.dat : star coordinates

[sphinkie]

Hi,

I am trying to understand the stars.dat file.
The format is well explained some another threads, but for X,Y, Z, I have few questions :

- What is the origin (0,0,0) point ?
(the center of the galaxy?, the Earth? , or else ?)

- How are defined the axis ? It seems Z is upwards, but Y is ???
(from the center to the Earth, maybe ?)

thanks

[selden]

- What is the origin (0,0,0) point ?
(the center of the galaxy?, the Earth? , or else ?)

The Sun, but the Sun is very slightly offset from [0,0,0] to avoid numerical problems. This may change.

- How are defined the axis ? It seems Z is upwards, but Y is ???
(from the center to the Earth, maybe ?)

stars.dat uses the same axes as the Ecliptic coordinate system.

[Malenfant]

- What is the origin (0,0,0) point ?
(the center of the galaxy?, the Earth? , or else ?)

The Sun, but the Sun is very slightly offset from [0,0,0] to avoid numerical problems. This may change.

Why was it put off-zero? I can't for the life of me think why that was a good idea.

[selden]

I have to admit that I really don't know.

[sphinkie]

thanks guys !

[cpotting]

- What is the origin (0,0,0) point ?
(the center of the galaxy?, the Earth? , or else ?)

The Sun, but the Sun is very slightly offset from [0,0,0] to avoid numerical problems. This may change.

Why was it put off-zero? I can't for the life of me think why that was a good idea.

As I understand, this was done in order to facilitate rendering Sol a the proper magnitude. The calculations used would not work if Sol was at the origin (my guess is that the calculation would then have to work with a "distance to Sol" of 0), so the Sun was offset from the centre of the Celestia universe

[ajtribick]

The original version of stars.dat stored parallax rather than distance, which goes (to a very good approximation) as 1/distance, which makes it impossible to specify a distance of 0. The magnitude was also stored as apparent magnitude, which was converted to absolute magnitude by assuming the observer was at the coordinate origin - for a star at the coordinate origin, this would become infinite.

So to remove the troublesome infinities at the price of some accuracy, the sun was offset.

The new prerelease and FT versions of Celestia do not suffer from this problem, but the Sun has not been restored to its correct position. The reason is that cel URLs and scripts use absolute coordinates, and restoring the Sun would break all of these.

It is possible to put the Sun at the origin by modifying the entry in nearstars.stc and changing the distance value to 0 (or create a .stc file in extras to do this - it makes handling updates to nearstars.stc easier). Just don't expect cel URLs and scripts set in the solar system to work as expected.

[Malenfant]

The new prerelease and FT versions of Celestia do not suffer from this problem, but the Sun has not been restored to its correct position. The reason is that cel URLs and scripts use absolute coordinates, and restoring the Sun would break all of these.

It is possible to put the Sun at the origin by modifying the entry in nearstars.stc and changing the distance value to 0 (or create a .stc file in extras to do this - it makes handling updates to nearstars.stc easier). Just don't expect cel URLs and scripts set in the solar system to work as expected.

Well since it isn't required to have the sun offset from zero anymore, I think this should be corrected.

Let the scriptwriters know that it's been changed, and let them correct their scripts to work in the new system. (I presume you're talking about people who do educational/tour scripts, because it doesn't affect the 'addon' scripts like my planetary magnitudes one or any other scripts that add functionality).

Either way I don't think Celestia's realism should be comprimised just because correcting a major error like this breaks a few scripts.

[chris]

The new prerelease and FT versions of Celestia do not suffer from this problem, but the Sun has not been restored to its correct position. The reason is that cel URLs and scripts use absolute coordinates, and restoring the Sun would break all of these.

It is possible to put the Sun at the origin by modifying the entry in nearstars.stc and changing the distance value to 0 (or create a .stc file in extras to do this - it makes handling updates to nearstars.stc easier). Just don't expect cel URLs and scripts set in the solar system to work as expected.

Well since it isn't required to have the sun offset from zero anymore, I think this should be corrected.

Let the scriptwriters know that it's been changed, and let them correct their scripts to work in the new system. (I presume you're talking about people who do educational/tour scripts, because it doesn't affect the 'addon' scripts like my planetary magnitudes one or any other scripts that add functionality).

Either way I don't think Celestia's realism should be comprimised just because correcting a major error like this breaks a few scripts.

The thing is, it's not really compromising the realism of Celestia. We don't know the distance between the Sun and any star to a precision smaller than the distance that the Sun is offset from the origin in Celestia. It can be a slight nuisance for people modifying Celestia's code, but it's not innaccurate in any meaningful sense. It seems a bad idea to break a lot of scripts and cel:// URLs for what amounts to only a very minor convenience for Celestia developers.

--Chris

[Malenfant]

The thing is, it's not really compromising the realism of Celestia. We don't know the distance between the Sun and any star to a precision smaller than the distance that the Sun is offset from the origin in Celestia. It can be a slight nuisance for people modifying Celestia's code, but it's not innaccurate in any meaningful sense. It seems a bad idea to break a lot of scripts and cel:// URLs for what amounts to only a very minor convenience for Celestia developers.

--Chris

First, the obligatory "ZOMG, Chris actually posted something here again!!!11one!!" comment .

Now that's out of the way, I disagree .

For one thing, it seems very inelegant to have the origin of a coordinate system with nothing in it. What then would be so special about RA 0, Dec 0, distance 0 if there's nothing there? Sure, one could centre the coordinate system on anything, but Sol itself is as good a place as any to put it. And yet the system is centred on an empty point in space that is over 200 AU from Sol? Seems daft to me, to be honest.

For another, if a distance of 0.00326167 as defined for Sol is inconsequential compared to the distance between Sol and the nearest stars then why not just set get rid of this extra distance and set it at zero anyway? And why have that distance anyway? Why not 0.00025, or 0.00001, or 0.0004? I presume there's some reason for this number to be selected, otherwise it's entirely arbitrary. As it is, it seems that 0.00326167 ly is about 3.0857e10 km, or about 205.7 AU. AFAIK, this number doesn't have any astronomical significance.

For another, how many of us actually use these scripts and Cel urls that rely on Sol being offset by 205.7 AU from the origin? Are these even particularly common? I have never used any that do. I don't believe that anything that comes with Celestia's core distribution would suffer as a result of Sol's location being corrected to be at the origin.

It just seems to me like this is some holdover from a previous era that is totally unecessary. Let's just drop it, correct the problem, and let the script writers deal with it. Otherwise it undoubtedly will bite us in the ass later on, as such holdovers usually do. (remember that 640K memory limit in DOS? Well later on IIRC people found it to be a major problem even though it wasn't necessary anymore).

[chris]

The thing is, it's not really compromising the realism of Celestia. We don't know the distance between the Sun and any star to a precision smaller than the distance that the Sun is offset from the origin in Celestia. It can be a slight nuisance for people modifying Celestia's code, but it's not innaccurate in any meaningful sense. It seems a bad idea to break a lot of scripts and cel:// URLs for what amounts to only a very minor convenience for Celestia developers.

--Chris

First, the obligatory "ZOMG, Chris actually posted something here again!!!11one!!" comment .

It's good to be back

Now that's out of the way, I disagree .

For one thing, it seems very inelegant to have the origin of a coordinate system with nothing in it. What then would be so special about RA 0, Dec 0, distance 0 if there's nothing there? Sure, one could centre the coordinate system on anything, but Sol itself is as good a place as any to put it. And yet the system is centred on an empty point in space that is over 200 AU from Sol? Seems daft to me, to be honest.

For another, if a distance of 0.00326167 as defined for Sol is inconsequential compared to the distance between Sol and the nearest stars then why not just set get rid of this extra distance and set it at zero anyway? And why have that distance anyway? Why not 0.00025, or 0.00001, or 0.0004? I presume there's some reason for this number to be selected, otherwise it's entirely arbitrary. As it is, it seems that 0.00326167 ly is about 3.0857e10 km, or about 205.7 AU. AFAIK, this number doesn't have any astronomical significance.

Yes, it is inelegant, and no there's no astronomical significance to the value chosen, other than the fact that it's distance from the origin is smaller than the minimum error in current stellar distance measurements.

For another, how many of us actually use these scripts and Cel urls that rely on Sol being offset by 205.7 AU from the origin? Are these even particularly common? I have never used any that do. I don't believe that anything that comes with Celestia's core distribution would suffer as a result of Sol's location being corrected to be at the origin.

The positions stored in cel URLs are absolute. If the position of Sol moves by ~205.7 AU to the true origin, it will break every cel URL out there that refers to a point within the Solar System. They'll all be 205.7 AU off, i.e. completely useless.

It just seems to me like this is some holdover from a previous era that is totally unecessary. Let's just drop it, correct the problem, and let the script writers deal with it. Otherwise it undoubtedly will bite us in the ass later on, as such holdovers usually do. (remember that 640K memory limit in DOS? Well later on IIRC people found it to be a major problem even though it wasn't necessary anymore).

How is it going to bite us exactly? Nothing in the Celestia code requires the Sun to be at the origin, since Celestia would work just fine without the Sun there at all. The 640K memory limit is a bad analogy--Celestia is not marching inevitably toward some wall at 205.7 AU. If it wasn't for backward compatibility, I'd move the Sun to the origin. But without some concrete example of how things will go horribly wrong without a truly heliocentric universe, I just don't see the need to force everyone who's posted a cel URL to change it for the next version of Celestia.

Ultimately, we could probably have it both ways--cel URL backward compatibility and Sol at the origin--if we start adding a version to cel:// URLs. Perhaps in Celestia 1.5 . . .

--Chris

[Cham]

Perhaps in Celestia 1.5 . . .

--Chris

OMG !! A version 1.5 !? From the horse's mouth !

[Malenfant]

The positions stored in cel URLs are absolute. If the position of Sol moves by ~205.7 AU to the true origin, it will break every cel URL out there that refers to a point within the Solar System. They'll all be 205.7 AU off, i.e. completely useless.

Then why not define cel URLs to be relative rather than absolute?

Again, I'm not convinced changing this would be a major inconvenience to anybody - how often are cel URLs defined in the solar system anyway? As I said, there's none in the celestia core distribution so why exactly should a developer care that a few URLs are going to be broken by fixing what a now obselete fudge?

Given that a big focus in Celestia is supposed to be accuracy it seems that this just tramples all over that. It doesn't really matter that 205.7 AU is smaller than the current distance measurements, it's still an arbitrary distance in an arbitrary direction that was added for a reason that serves no purpose anymore. And it really makes no sense to me to keep it in terms of anything the program does.

If nothing else, why don't we have FT1.3 set the sun at the exact origin and see what happens. (and while we're at it, we can correct the incorrect value for the speed of light too). Personally I really doubt that anyone would even notice that the changes have been made, and if that was the case then that would disprove any objection that URLs would have been broken.

It's a lot simpler to do that faffing around with converters or whatever for people who insist on using URLs that are outdated. IMO that'd be their problem to sort out, not yours.

[cpotting]

Then why not define cel URLs to be relative rather than absolute?

That would still break all the existing URL's out there.

Again, I'm not convinced changing this would be a major inconvenience to anybody - how often are cel URLs defined in the solar system anyway?

Quite often, I would think. Just look at the Celestia Guide by Frank Gregorio. The very first thing you see is a cel URL that would break. And this single document is chock full of additional cel URL's that would break.

As I said, there's none in the celestia core distribution so why exactly should a developer care that a few URLs are going to be broken by fixing what a now obselete fudge?

But what is the advantage of changing it? Why? Other than making heliocentric coordinates easier. But I see nothing special about heliocentric coordinates. When I want to measure where things are relative to the Earth, I have do conversions (and Earth is where I do most of my observing from ). Ditto for finding things relative to the centre of the galaxy. What is so special about heliocentric coordinates that it would warrant breaking a tool used by so many people to share views and experiences (which is exactly what cel URL's do)?

Given that a big focus in Celestia is supposed to be accuracy it seems that this just tramples all over that. It doesn't really matter that 205.7 AU is smaller than the current distance measurements, it's still an arbitrary distance in an arbitrary direction that was added for a reason that serves no purpose anymore. And it really makes no sense to me to keep it in terms of anything the program does.

I will argree with you here, that the 205.7 shift is an inaccuracy in a program that is touted for its accuracy.

I like Chris' suggestion: if the 205.7 shift is removed, then version numbers should be added to cel URL's. That way old URL's (without the version number) can be shifted 205.7 AU's so that they still render correctly. But I would add that we also need a new frame of reference in celx scripting to prevent scripts from breaking too.

[Malenfant]

Ok. Here are two cel URLs. The first is from a normal Celestia 1.4 with the sun at it's default offset from zero, the second is with the sun set at 0 distance.

cel://Follow/Sol:Earth/2005-11-23T00:00 ... 6239&lm=12
cel://Follow/Sol:Earth/2005-11-23T00:00 ... 6239&lm=12

The parts that are different between the two are these bits in the middle:

Code: Select all

x=QIS26vEFvkzFDA&y=iGT0adNC8f///////////w&z=LKl/6L16q2Py/////////w&ow=0.708588&ox=0.000000&oy=0.705622&oz=0.000000
x=fFCREfQ1w6EH&y=dmX0kMdD8f///////////w&z=+I16gzI/k2Ty/////////w&ow=0.969279&ox=0.000007&oy=0.245965&oz=0.000002


It's not remotely obvious to me what the first bit of gibberish is and why it's different, but the last part seem to be xyz coordinates (relative to what, and in what units, I don't know) and those are different.

So is there any way to convert one to the other? If we can figure that out then maybe we can change Sol to the origin and give out a converter afterwards to convert all other URLs to the new system.


By the way, heres a cel URL of the same thing from FT1.1 (with the sun offset). I noticed that it doesn't have Follow/Sol:Earth at the start, it just has Follow/Earth.

cel://Follow/Earth/2005-11-23T00:00:00. ... 2623&lm=12

[ajtribick]

Out of interest, what would correcting the speed of light break?

[cpotting]

The parts that are different between the two are these bits in the middle:

Code: Select all

x=QIS26vEFvkzFDA&y=iGT0adNC8f///////////w&z=LKl/6L16q2Py/////////w&ow=0.708588&ox=0.000000&oy=0.705622&oz=0.000000
x=fFCREfQ1w6EH&y=dmX0kMdD8f///////////w&z=+I16gzI/k2Ty/////////w&ow=0.969279&ox=0.000007&oy=0.245965&oz=0.000002


It's not remotely obvious to me what the first bit of gibberish is and why it's different, but the last part seem to be xyz coordinates (relative to what, and in what units, I don't know) and those are different.

As I understand it, the x, y, z and w at the start specify the orientation of the observer. The ox, oy, and oz indicate the coordinates of the observer in universal coordinates.

[Malenfant]

The parts that are different between the two are these bits in the middle:

Code: Select all

x=QIS26vEFvkzFDA&y=iGT0adNC8f///////////w&z=LKl/6L16q2Py/////////w&ow=0.708588&ox=0.000000&oy=0.705622&oz=0.000000
x=fFCREfQ1w6EH&y=dmX0kMdD8f///////////w&z=+I16gzI/k2Ty/////////w&ow=0.969279&ox=0.000007&oy=0.245965&oz=0.000002


It's not remotely obvious to me what the first bit of gibberish is and why it's different, but the last part seem to be xyz coordinates (relative to what, and in what units, I don't know) and those are different.

As I understand it, the x, y, z and w at the start specify the orientation of the observer.

How? It looks like a jumble of letters and numbers to me. (besides, they should be the same shouldn't they? It's the same view of the Earth)

[selden]

The apparent gibberish is a dump of the bits that specify Celestia's Render View Options.

[cpotting]

How? It looks like a jumble of letters and numbers to me. (besides, they should be the same shouldn't they? It's the same view of the Earth)

The apparent gibberish is a dump of the bits that specify Celestia's Render View Options.

I know they indicate the internal quaternion values as used with the newrotation() method. Exactly how they are encoded, I'm not sure. Look at the "newrotation" and "the rotation object" sections in the Celx Visual Guide.

Selden, do you mean that they hold more than just the observer's orientation? I don't recall seeing anything more than just the orientation values being stored in the x,y,z,w values. I could be wrong though (I've been wrong before...but just one time...it was long ago...and I was young )