Celestia Coordinate Systems / Modes

[don]

To Chris and Developers...

The coordinate system names accepted by setframe map to Celestia's modes as follows:

equatorial - follow
geographic - synchronous (Sync Orbit)
lock - lock
chase - chase
universal - no mode selected (e.g. you just pressed ESC)

That's a total of five values.

However, the setframe command syntax (first documented by Selden) lists six possible values:

Code: Select all

setframe {ref <string>
          target <string>
          coordsys <string> (default = "universal") }
  coordsys must be one of the following:
    "observer"
    "geographic"
    "ecliptical"
    "universal"
    "lock"
    "chase"


PROBLEM: When Celestia is set to "Lock Earth-Sol", and you save a Bookmark, it sets the coordsys to a seventh value, "phaselock", which is not listed in the setframe syntax, but is obviously supposed to be just plain "lock", yes?

PROBLEM: The saved Bookmark data for this "Lock" does not include "Earth" as part of the two-object selection...

Code: Select all

"Lock Earth-Sol" {
   isFolder false
   parentFolder ""
   base   [ 0.003274855561013672 7.384594706946544e-011 9.049913490585093e-006 ]
   offset [ 6.784763723066689e-014 0 6.310056643865636e-017 ]
   axis   [ 2.48852e-007 1 6.82564e-007 ]
   angle  1.57356
   time   2452870.462814566
   selection "#0"
   coordsys "phaselock"
}


Then, when selecting the Bookmark in the Celestia UI, it displays "Lock Sol - ", with an error in the Abs display line for Sol, but no Earth or Sol on-screen.

PROBLEM: When Celestia's coordsys value is set to "any invalid value" via the setframe command in a script, and then a Bookmark is saved via the UI, the coordsys value saved in the bookmark is "local", which is an eighth coordsys value. However, it seems that this value should be "universal", which is supposed to be the default value according to Selden's original document -and- what the code seems to be doing. No?

CORRECTION: When Celestia is set to "Follow" and you save a Bookmark, it is recorded as "ecliptical", not as "equatorial" as your previous message stated (quoted above). Which means Follow=Ecliptical, not Follow=Equatorial.

This all leaves me in a state of confusion, that I hope you can clear up Chris, so that I can properly document Celestia's Coordinate Systems in the Scripting Guide.

You defined five Mode-to-coordsys matches (above), and Follow has been corrected to Ecliptical. However, that leaves us with three undefined Mode-to-coordsys matches (equatorial, observer, and local)...

Code: Select all

               Related Coordinate
Celestia Mode  System (setframe)   Comments
-------------  ------------------  --------------------------------------------------
Chase          chase               Okay
Sync Orbit     geographic          Okay, but you mentioned xing to "planetographic"
None set       universal           Also called "free", also called "absolute"
Lock           lock                Also called "phaselock" in Bookmarks/favorites
Follow         ecliptical          This is what the code says: Bookmarks/celestiacore
???            equatorial          What Celestia Mode does this represent?
???            observer            What Celestia Mode does this represent?
???            local               What Celestia Mode does this represent?


ADDITIONAL QUESTIONS:
Have you decided to change "geographic" to "planetographic", or leave it as-is? Why not just call it what the UI calls it: "syncorbit"?

Should all occurrences of "phaselock" be changed to "lock" in the source code, or the other way around? Referring to one mode by two different variable names will get real messy.

What about universal, free, and absolute? Can y'all just call this coordsys one name, instead of three or more <smile>?

I really appreciate your help Chris and Developers.

-Don G.

[HankR]

Don,

I believe that internally Celestia uses coordinate systems for other purposes in additon to defining observer modes. So it is not a problem that there are more coordinate system types than observer modes.

I think there may be some bugs in the favorites code for phaselock mode.

Presumably the result of coding an invalid value is undefined.

I think "free" refers to the observer mode, not the coordinate system.

- Hank

[don]

Howdy HankR,

Thank you for your reply.

I believe that internally Celestia uses coordinate systems for other purposes in additon to defining observer modes.

I understand. However, of the three undefined coordsys values, the values "observer" and "equatorial" are both exposed via the setframe command (see code below), which is why I am asking about them, so they can be documented for scripters.

As for "local", I just noticed in cmdparser.cpp that the default value has indeed been changed from "universal" to ObserverLocal ("local"). I am assuming "local" because this is what happens when coordsys in setframe is given an invalid string, but ONLY in cmdparser.cpp, and not in celx.cpp, which sets it to "universal". Here is the code from cmdparser.cpp ...

Code: Select all

static astro::CoordinateSystem parseCoordinateSystem(const string& name)
{
    if (compareIgnoringCase(name, "observer") == 0)
        return astro::ObserverLocal;
    else if (compareIgnoringCase(name, "geographic") == 0)
        return astro::Geographic;
    else if (compareIgnoringCase(name, "equatorial") == 0)
        return astro::Equatorial;
    else if (compareIgnoringCase(name, "ecliptical") == 0)
        return astro::Ecliptical;
    else if (compareIgnoringCase(name, "universal") == 0)
        return astro::Universal;
    else if (compareIgnoringCase(name, "lock") == 0)
        return astro::PhaseLock;
    else if (compareIgnoringCase(name, "chase") == 0)
        return astro::Chase;
    else
        return astro::ObserverLocal;
}


Looking at the first IF statement, it's saying if the passed coordsys is "observer", then set it to "local" (ObserverLocal), as found out by saving a bookmark and looking at the favorites.cel file. So, it would appear that "observer", "local", and ObserverLocal are all the same thing. Is this correct?

Now, this code has been duplicated and changed in the celx.cpp file, for whatever reason. Why is there not a single routine to parse the Coordinate System, instead of two (or more?) routines doing the same thing? ...

Code: Select all

static astro::CoordinateSystem parseCoordSys(const string& name)
{
    if (compareIgnoringCase(name, "universal") == 0)
        return astro::Universal;
    else if (compareIgnoringCase(name, "ecliptic") == 0)
        return astro::Ecliptical;
    else if (compareIgnoringCase(name, "equatorial") == 0)
        return astro::Equatorial;
    else if (compareIgnoringCase(name, "planetographic") == 0)
        return astro::Geographic;
    else if (compareIgnoringCase(name, "observer") == 0)
        return astro::ObserverLocal;
    else if (compareIgnoringCase(name, "lock") == 0)
        return astro::PhaseLock;
    else if (compareIgnoringCase(name, "chase") == 0)
        return astro::Chase;
    else
        return astro::Universal;
}


Comparing the two routines, one can notice the following changes:

* In cmdparser.cpp, the default coordsys value is "local", but in celx.cpp, it is "universal".

* The routine name is changed, from parseCoordinateSystem (cmdparser) to parseCoordinateSys (celx).

* The string "ecliptical" (cmdparser) has been changed to "ecliptic" (celx).

* The string "geographic" (cmdparser) has been changed to "planetographic" (celx) but still uses the Geographic variable ("geographic"), so it is being force-changed from "planetographic" to "geographic".

I think there may be some bugs in the favorites code for phaselock mode.

As mentioned in my first message ...

PROBLEM: When Celestia is set to "Lock Earth-Sol", and you save a Bookmark, it sets the coordsys to a seventh value, "phaselock", which is not listed in the setframe syntax, but is obviously supposed to be just plain "lock", yes?

PROBLEM: The saved Bookmark data for this "Lock" does not include "Earth" as part of the two-object selection...

Maybe these are the "bugs" in the Bookmark/favorites code? According to the two parseCoordSys routines above, "lock" = PhaseLock, the variable, not the string "phaselock".

-Don G.