Dwarf planet candidate class, should we add it into the core

[onetwothree]

Hi!

There is a request from Celestia Origin team to add a new object class - dwarf planet candidates. I'm not a big fan of this addition as I don't see what makes such objects so special so we need a new independent class for them. Pirogronian is strictly against the addition because he considers this class virtual, just a name of a bureaucratic process stage.

Any opinions?

[john71]

NASA has announced that it will use the new guidelines established by the IAU.[63] Alan Stern, the director of NASA's mission to Pluto, rejects the current IAU definition of planet, both in terms of defining dwarf planets as something other than a type of planet, and in using orbital characteristics (rather than intrinsic characteristics) of objects to define them as dwarf planets.[64] Thus, in 2011, he still referred to Pluto as a planet,[65] and accepted other dwarf planets such as Ceres and Eris, as well as the larger moons, as additional planets.[66] Several years before the IAU definition, he used orbital characteristics to separate "überplanets" (the dominant eight) from "unterplanets" (the dwarf planets), considering both types "planets".[42]

https://en.wikipedia.org/wiki/Dwarf_planet#Contention

Added after 2 minutes 14 seconds:
In my opinion it is an accepted term, but a little bit shaky in its foundations...

[selden]

Note that onetwothree is writing about adding the SSC Class "dwarfplanetcandidate". Celestia has supported the SSC Class "dwarfplanet" for a long time.

Personally I have no strong feelings either way. However, I'm sticking with using Celestia v1.6.1 since there are many different versions of Celestia v1.7 with many incompatibilities and most people don't have any of them.

[john71]

Thanks Selden for clarifying! I meant that even the definition of dwarf planet is a contentious issue, so adding a "candidate" to it makes it even more problematic in my opinion.

[Croc]

The lower and upper limits of the size and mass of dwarf planets are not specified in the MAC solution.
The draft preliminary decision of the MAS said "to objects with a mass of more than 5 · 10 ^ 20 kg and a diameter of more than 800 km"
Today 5 big asteroids granted the status of "dwarf planet."
In the base of the asteroids of the team Celestia Origin there are 85 candidates for dwarf planets with a radius of more than 150 km (excluding mass).
---------------------
The class of dwarf planets was added in Celestia 1.6.0. This is a very generous solution for 5 objects.
Dwarf planet is an honorary status.
Why other large asteroids are not allocated.
---------------------
Another analogy.
In the UK, 69 municipalities with the status of "city" .The status of this is the right granted by the British monarch ...
St. Davids, with a population of less than 2,000, is the smallest city with a city status.
--------------------
For comparison, there is a category (class) - Moon, there is a category (class) of small moons Minormoon.
Why not extend this ranking to asteroids?

Rename the class “Dwarf Planet” to the class “Big asteroid”.

Added after 12 minutes 52 seconds:
.
Large asteroids in the status of "Dwarf Planet" can be distinguished by the color of the orbit and the color of the label.

[pirogronian]

@Croc

This is why I would glad remove also "dwarf planet" from object flags, as well as "Planet", "Moon", "Minor Moon", "Asteroid" and "Comet". All these names are too contractual and are mostly indistinguishable by renderer. It should be replaced by generic category system, as @onetwothree proposed.

Large asteroids in the status of "Dwarf Planet" can be distinguished by the color of the orbit and the color of the label.

That is why I propose second thing: all rendering aspects whitch do not represent physical appearance, should be configurable for user.

[john71]

But we should not change the possibility of distinguishing between different orbits of different objects. For example it is very nice to have different orbits for different class of objects (planet, moon and so on), so you can turn them off as a class, they have different colors, etc...

Sometimes you need to see only planetary orbits, but not the orbit of moons. or asteroids. But sometimes you need to see only comets and their orbits...

[onetwothree]

I'm in favor of having "Dwarf planet", "Planet", "Moon", "Minor Moon", "Asteroid" and "Comet". At least they are present in IAU nomenclature. I'm just not fan of making 100500 types of asteroids.

[Askaniy]

It seems to me that adding classes of asteroids and comets to other classes will not be correct, but without adding them the full base of the minor bodies of the Solar System is displayed terribly. In the old Russian forum, it was called “Orange Armageddon”.
In fact, there are not so many official classes of asteroids and comets (https://pdssbn.astro.umd.edu/data_other/objclass.shtml), but adding them to classes of other objects (dwarf planets, planets, moon, minor moons, asteroids, comets) is not worth it.

I think for dwarf planet candidates there is a compromise - to include them in the class “Dwarf planets”, but to display them a little differently. For example, by the colour of graphic elements.

[Croc]

Ascanius (from the Celestia Origin team) is very close to my point of view. It is necessary to refer the candidates to the category “Dwarf Planets”.
In this case, programmers do not need to change anything.
Ascanius for the classification of asteroids and comets by the type of orbits (cupids, mars-crossers, etc.). From me such a proposal was.
=============
pirogronian and onetwothree, make a classification of asteroids by type of orbits. If someone does not need it, let it not use it.
=============
This discussion worries me. Pirogronian and onetwothree have opposite views.
I am for pluralism of opinions.

[pirogronian]

@Croc

Me and @onetwothree have quite similar views, in my opinion. I'm just a bit more radical and have more wishes. So, rather me and you have opposite views . But don't worry, I'm going to implement user defined categories.

[Askaniy]

Pirogronian on GitHub:

As estabilished on forum, we need some kind of user defined category system. I propose something similar to tags: multiple categories per object, for more flexibility. Categories database would be generated in fly, during data files loading. I can start it.

A good option. Or add subcategories: for asteroids (14 subcategories), comets (8 subcategories), dwarf planets (2 subcategories).

[selden]

Would it be possible to provide the capability to define ObjectTypes in an SSC catalog?

It seems to me that would allow people who need additional Objects to define and use whatever categories they need for their Addons.

[john71]

Great idea! (Oh my God! Selden! 10000 posts??? ).

[pirogronian]

Would it be possible to provide the capability to define ObjectTypes in an SSC catalog?

Lexical way to declare categories in data files is a technical detail, which can be discussed. There could be even multiple ways to do that. Quoting @onetwothree on github:

Celestia parser supports arrays, so in ssc file we can have
tags [foo, bar]

I'm going to implement also categories hierarchy and optional localised translations.

[Croc]

Give a small piece of ssc-file with foo, you bar. Please.

[Janus]

A thought.

Could "Candidate" be a generic category to indicate that data is tentative?
Perhaps a flag for displaying or hiding items with questionable or unconfirmed data?


Janus.

[LukeCEL]

Perhaps a flag for displaying or hiding items with questionable or unconfirmed data?

I like this idea in theory. I come across objects with patchy data a lot, sometimes the objects themselves are questionable. (However, if this is implemented, I'd have to update a lot of my add-ons...)

Also, how would you implement this? For example, what about objects like 2060 Chiron where the ring system is tentative? You'd need to declare somewhere that the ring system only is tenative. Just my thoughts.

[Janus]

In the body object you have a boolean Candidate or Confirmed that is checked during a render loop.

if (BodyRender || (ShowCandidates == Candidate) {RenderBody}
if (OrbitRender || (ShowCandidates == Candidate) {RenderOrbit}
if (LabelRender || (ShowCandidates == Candidate) {RenderLabel}

The same logic could be applied to make a Candidate only display.
Add an extra parameter or make another call to the render function after setting up the new requirements.

Just something to be thought about.

I think ring systems are the children of things, and so would be separate from them.
Just mark the main body as a noncandidate, and the ring as a candidate.


Janus.

Edited for an attempt at better clarity.

[pirogronian]

As user defined categories are already implemented, there would be following code in .ssc file (@Croc, You asked about such a example):

Code: Select all

Category = "name"

or

Code: Select all

Category = [ "name1", "name2" ...]

For candidate bodies there would be, for example, "Candidate body" category and "Candidate rings" separately for bodies with candidate ring system. Appipropriate Lua script would set display options.

This can be more sophisticated, if we make also ring class 'categorizable'. But from developer' point of view it won't be trivial.