Changing star designators, pros and cons

The place to discuss creating, porting and modifying Celestia's source code.
Topic author
onetwothree
Site Admin
Posts: 510
Joined: 22.09.2018
With us: 2 years

Changing star designators, pros and cons

Post #1by onetwothree » 28.01.2019, 12:58

Hi celestians!

We have a bug report from LukeCEL:

LukeCEL wrote:Currently stars labeled "MU xxx" or "NU xxx" are displayed as Bayer designations, but it doesn't allow variable star designations. For example, HIP 33345 = μ Canis Majoris but HIP 35355 = MU Canis Majoris.

Based on the Wikibook, changing the code to only allow "MU." or "NU." is one option, however that wouldn't be backwards compatible.

To properly fix it we need to rework completely names handling: change the way we keep them in memory, change the way we define them in stc files, change the way we handle user input in a console, etc. This require a lot of work.

So for 1.7.0 I think about less intrusive but still not backward compatible changes:
1) Either disallow 2-letter codes (NU/MU/XI) for greek letters, and use them with trailing point only (MU./NU./XI.) as the Wikibook states;
2 ) Or add a prefix (e.g. _) for greek letters (_BET, _MU, etc) as Pirogronian suggested;
3) Or do nothing for 1.7.0 and implement a more robust solution in 1.8?

What do you think?
Last edited by onetwothree on 29.01.2019, 19:38, edited 1 time in total.

john71
Posts: 491
Joined: 10.08.2016
With us: 4 years 2 months

Post #2by john71 » 28.01.2019, 14:04

Please do not change the stc files or earlier rules, because hundreds of work hours are invested in add-ons.

If you change the rules, those add-ons will become useless. :fie:

In my opinion backwards compatibility must be a priority.

Added after 14 minutes 21 seconds:
I use hundreds of fictional stars tens of thousands of light years away, so any minimal change at their positions and distances would be catastrophic, for example the few light years distances between them would become tens of light years or more.
Last edited by john71 on 29.01.2019, 08:24, edited 1 time in total.

Topic author
onetwothree
Site Admin
Posts: 510
Joined: 22.09.2018
With us: 2 years

Post #3by onetwothree » 28.01.2019, 16:58

John71, please reread the question.

john71
Posts: 491
Joined: 10.08.2016
With us: 4 years 2 months

Post #4by john71 » 28.01.2019, 17:05

"change the way we define them in stc files"

I was referring to this particular sentence.

pirogronian
Developer
Posts: 232
Joined: 05.01.2018
Age: 34
With us: 2 years 9 months
Location: Wrocław
Contact:

Post #5by pirogronian » 28.01.2019, 18:32

I think we may implement completely new ways to defining names without braking backward compatibility. For example, we may introduce new hash entries inside definition block:

Code: Select all

Star "traditional:names:separated:by:colon" {
    names = [
        { whole new name definition },
        { whole new name definition2 }
    ]
}


If we, for example, want to put Bayer name, we would write:

Code: Select all

{
    tyupe = "Bayer"
    name = "ALF Cen"
}


or just

Code: Select all

{
    name = "ALF Cen"
}


If we want to put variable star name, we would write:
{
type = "raw"
name = "MU blabla"
}

If we want to put catalog number, we would write:

Code: Select all

{
    name = "HIP 12345"
}


or

Code: Select all

{
    type = "HIP"
    number = 12345
}


General rule would be: if "type" field is absent, names are interpreted in traditional way.

I repeat, thi is my proposition only.
Last edited by pirogronian on 31.01.2019, 10:36, edited 1 time in total.
Universe is ruled by electricity.

john71
Posts: 491
Joined: 10.08.2016
With us: 4 years 2 months

Post #6by john71 » 28.01.2019, 19:03

Based on the Wikibook, changing the code to only allow "MU." or "NU." is one option, however that wouldn't be backwards compatible.

I think

1.) you should try new ideas and concepts boldly :clap:

2.) but as a user I have these very simple expectations:

- backwards compatibility
- easy usage
- bug free.

So in my opinion it is up to you, programmers to choose the new features.

But please don't forget, that Celestia is primarily a 3D astronomy CONTENT creator, in fact the only one really usable 3D astronomy content creator there is.
Last edited by john71 on 29.01.2019, 08:24, edited 1 time in total.

Avatar
LukeCEL
Posts: 358
Joined: 26.09.2017
With us: 3 years

Post #7by LukeCEL » 28.01.2019, 20:56

I'd like to reiterate my points a bit more clearly in this thread:

onetwothree wrote:2 ) Or add a prefix (e.g. _) for greek letters (_BET, _MU, etc) as Pirogronian suggested;
That's not backwards-compatible because previously made add-ons have are specified without underscores. But I think an alternative to what pirogronian suggested is that you could "escape" variable MU/NU stars so "MU CMa" is rendered as "μ CMa", but "_MU CMa" is rendered as "MU CMa".

It doesn't look very nice, but it's backwards-compatible and unobtrusive.

onetwothree wrote:3) Or do nothing for 1.7.0 and implement a more robust solution in 1.8?
To be honest, I'd be fine with this as well. The MU/NU thing is only a minor annoyance; no need to change so much about .stc files to fix them.

pirogronian
Developer
Posts: 232
Joined: 05.01.2018
Age: 34
With us: 2 years 9 months
Location: Wrocław
Contact:

Post #8by pirogronian » 28.01.2019, 21:07

But I think an alternative to what pirogronian suggested is that you could "escape" variable MU/NU stars so "MU CMa" is rendered as "μ CMa", but "_MU CMa" is rendered as "MU CMa".

This is exactly was I proposed :D

The MU/NU thing is only a minor annoyance; no need to change so much about .stc files to fix them.

I though about possible future troubles with new naming conventions, if will be introduced eventually.
Universe is ruled by electricity.

Janus
Posts: 522
Joined: 13.08.2016
With us: 4 years 2 months

Post #9by Janus » 29.01.2019, 03:54

I am not a real astronomer, but I have seen and helped customers with category or terminology updates before.
The fist step is always the same, document what it is that needs to translate/update/change so everyone is talking about the same thing.
So, to clear the air, what I know so far is a question about handling greek alphabet shorthand in astronomical names.
Thus here is what I know of so far, though this list will be incomplete before long.
There is after all more than one source of stellar names.

Spoiler

Code: Select all

Lowercase Greek Letters
α    alpha            
ι    iota            
ρ    rho
β    beta            
κ    kappa
σ    sigma
γ    gamma            
λ    lambda
τ    tau
δ    delta            
μ    mu            
υ    upsilon
ε    epsilon            
ν    nu            
φ    phi
ζ    zeta            
ξ    xi            
χ    chi
η    eta            
ο    omicron            
ψ    psi
θ    theta            
π    pi            
ω    omega

So we start with ancient greek.
I would recommend that if anything needs to be changed, it be the smallest change possible.
I would start with a rosetta file of shorthand functioning as an extension of internationalization.
Basically, it contains lines equating ways of writing the same thing, Such as
β beta
Then everything in the database that has a name rather than a number, gets two names.
One is with shorthand, the other properly internationalized.
Add a function to reading the data files to check for and translate them according to the local language.
"whitespace lettergroup whitespace" for dictionary check of names.
In the gui add a shortcut key, and perhaps a view option, to decide which form to show, or perhaps both.

Alpha Centauri vs α Centauri

This maintains backwards compatibility, while providing translations of shorthand that an individual may not know.
Once done, it won't matter whether an amateur or an astronomer writes the label, both will be able to view and read it.
It also allows for stars to have names in multiple languages, perhaps another option to be added so the display can be changed on the fly.
It could be useful to be able to change asterisms, say from greek, to chinese, to japanese, to mayan, to whatever.
The same could be done for the names, or at least the properly written label.

I admit is kind of a cludge, but sometimes the past is every bit as important as the future.
Do not throw away the past to make way for the future, all that does is lose the lessons learned so they have to be learned again.


Janus.

Topic author
onetwothree
Site Admin
Posts: 510
Joined: 22.09.2018
With us: 2 years

Post #10by onetwothree » 29.01.2019, 19:38

I think we'll add a 'Version' field to STC/SSC files and files with Version >= 2 will have greek letters or designators as in the wiki.

Avatar
cartrite
Posts: 1794
Joined: 15.09.2005
With us: 15 years 1 month
Location: Pocono Mountains, Pennsylvania, USA

Post #11by cartrite » 29.01.2019, 20:25

The example used had 2 different identifiers. One was MU and the other was Mu. One of them was hip 33345 and the other pointed to hip35355. I'm not sure if all variable stars are treated as such. If so Maybe include lower case?
Toshiba Satellite P875=S7200 laptop, Intel i5 processor 2.5 ghz 6 gb ram, Graphics Intel(R) HD Graphics 4000 openSUSE Leap 15.1 and soon to be 15.2

Topic author
onetwothree
Site Admin
Posts: 510
Joined: 22.09.2018
With us: 2 years

Post #12by onetwothree » 30.01.2019, 10:45

The problem is search console which is case insensitive.

john71
Posts: 491
Joined: 10.08.2016
With us: 4 years 2 months

Post #13by john71 » 30.01.2019, 12:48

Stc 2.0 and ssc 2.0 is a perfect choice, because the new add-ons can use the new parameters.

I suggest that you should also check the changes celestia.Sci is implementing in the stc/ssc files. It would be nice, if Celestia3d would be able to open celestia.Sci add-ons.

If I'm correct there is a change in the definition of star or planet positions in celestia.Sci, some celestia.Sci exoplanet files are not working anymore properly in Celestia3d.

Topic author
onetwothree
Site Admin
Posts: 510
Joined: 22.09.2018
With us: 2 years

Post #14by onetwothree » 30.01.2019, 17:43

@john71, could you point to such celestia.Sci only addons?

john71
Posts: 491
Joined: 10.08.2016
With us: 4 years 2 months

Post #15by john71 » 30.01.2019, 18:04

Maybe this was the discussion, I'm not sure:

@ajtribick

I tried using your celestia-exoplanets script, but after copying the ssc and stc file into the data directory, celestia did not display any exoplanets at all.

I don't know what I'm doing wrong. Would you mind sending me a pm to help me?

If you're using Celestia 1.6.1 then it will not work because I'm using the units syntax that unfortunately never made it into a released version of Celestia. The main reason is because it is a lot more convenient than using Celestia's defaults which tend to work best with our rather wide-spaced solar system and not so well once you start dealing with planetary orbital periods of a few days.

Either you'd need to compile Celestia from the SVN repository yourself (slightly annoying on Windows because qt4 and the latest Microsoft compiler don't seem to get along particularly well), or find someone else who's built it and has the binaries.

http://forum.celestialmatters.org/viewtopic.php?f=17&t=683&p=14726&hilit=exoplanets#p14726

Added after 1 minute 44 seconds:
Or maybe this:

http://forum.celestialmatters.org/viewtopic.php?f=2&t=839&p=13930&hilit=exoplanets#p13930

Added after 1 minute 41 seconds:
I'm not 100% percent sure that it will be in celestia.Sci, but it came up on that forum.

pirogronian
Developer
Posts: 232
Joined: 05.01.2018
Age: 34
With us: 2 years 9 months
Location: Wrocław
Contact:

Post #16by pirogronian » 30.01.2019, 20:52

onetwothree wrote:The problem is search console which is case insensitive.
Searching by typed text is not case sensitive, both with legacy code and aftyer my changes in #213.
Universe is ruled by electricity.

john71
Posts: 491
Joined: 10.08.2016
With us: 4 years 2 months

Post #17by john71 » 30.01.2019, 21:11

onetwothree: I think the ssc/stc 2.0 standard should rethink the AU/ light year/parsec usage, and the RA/DEC hours/degrees conversion.

Avatar
LukeCEL
Posts: 358
Joined: 26.09.2017
With us: 3 years

Post #18by LukeCEL » 30.01.2019, 21:36

john71 wrote:
ajtribick wrote:If you're using Celestia 1.6.1 then it will not work because I'm using the units syntax that unfortunately never made it into a released version of Celestia. The main reason is because it is a lot more convenient than using Celestia's defaults which tend to work best with our rather wide-spaced solar system and not so well once you start dealing with planetary orbital periods of a few days.

Yeah, essentially Celestia.sci has unit support, while Celestia 1.6.1 doesn't. From what I can tell, you can specify the units of a parameter like this:

Code: Select all

   Distance<pc> 100


john71 wrote:onetwothree: I think the ssc/stc 2.0 standard should rethink the AU/ light year/parsec usage, and the RA/DEC hours/degrees conversion.

I don't know, I still feel like creating a new catalog format is a bit overkill, even if we do want to implement database-like structures. In any case, if I can ever get the whole compiling thing going, I will probably be sticking to using the existing format, again, for backwards compatibility.

But if you do decided to make a "ssc/stc 2.0 standard", please consider changing the units for the "RA" parameter for .DSC files. They're in hours, not degrees, for reasons I don't understand.

john71
Posts: 491
Joined: 10.08.2016
With us: 4 years 2 months

Post #19by john71 » 31.01.2019, 08:34

LukeCEL: yes, the dsc files are different in this regard, good point.

In my opinion - as I said many times before - backwards compatibility is essential, so ssc/stc/dsc 1.0 files should work flawlessly in 1.7 or 1.8 versions too.

Does it in any way worth the enormous work to implement such changes?

I personally don't think.

"If it ain't broke, don't fix it".

pirogronian
Developer
Posts: 232
Joined: 05.01.2018
Age: 34
With us: 2 years 9 months
Location: Wrocław
Contact:

Post #20by pirogronian » 31.01.2019, 10:34

I also think about adding new parameters to specify catalog file entry behaviour rather than introducing global versioning per whole file. Recall first code example in my previous post: https://celestia.space/forum/viewtopic.php?p=142019#p142019
Universe is ruled by electricity.


Return to “Development”

Who is online