Create and draw convex hulls for constellations

[gzotti]

Description

For specialized research around star or transient identification, the idea of convex hulls came up.
This branch shall develop this feature.

I don't yet know whether it really fulfills its task or whether it should be hidden behind some manual setting. @sushoff, what is the actual purpose, and what do you want to use them for? Just display, or any advanced scripting/query functions? Practical issues arise for 1-2 star constellations, and a Voronoi-like splitting could actually form a connected spatial segmentation without overlaps and gaps. However, I have never played in these fields.

As technical issue, I have no idea why line drawing is suppressed in the long northern connection line of Hydra, eastern edge of Serpens (cauda) and for Draco intersecting UMi. Given I use SphericalPolygons for drawing, It may be similar to various issues reported around polygonal horizons.

Fixes # (issue)

Screenshots (if appropriate):

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update
• Housekeeping

How Has This Been Tested?

Test Configuration:

• Operating system: Win11
• Graphics Card: Geforce 3700Ti (irrelevant)

Checklist:

• My code follows the code style of this project.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (header file)
• I have updated the respective chapter in the Stellarium User Guide
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

This is an automatically generated QA checklist based on modified files.

[github-actions]

Hello @gzotti!

Thank you for proposing of the feature.

[sushoff]

THANK YOU, @gzotti , I love this new feature!

Use Cases (up to now)

1. initially, I wanted to visualize the area that is covered by a list of stars in ancient star catalogues, especially the gaps and overlaps
2. later, I also used them to compute the areas (in square degrees) that are covered by constellations
3. now I want to (doable with Youla's tool) also make little star catalogues of "all stars within the constellation area", which may be helpful to a) approach historical questions about the completeness of historical documents and b) astrophysical questions like "is this faint 20mag blackhole-binary within the historical constellation XY" (let's not discuss if these quesstions make sense - it's a fact that they are asked)

[sushoff]

yes, the "one and two stars"-constellations are an issue: up to now, I always defined exceptions for them.

Now, as we have the circles for single star-asterisms, I think, I would use those; something like

n= number@starsInConstellation
If n=1,
use radius
ELSE IF n =2
g = gravityCenter
radius = distanceFromHIP2GravCenter + 1degr
ELSE
...
(usual case)

[10110111]

Why are some of the hulls (e.g. those around Serpent and Dragon) open?

[sushoff]

Why are some of the hulls (e.g. those around Serpent and Dragon) open?

I think this is what @gzotti also wonders above: seems to be a problem with rendering, not with computation

[10110111]

I think this is what @gzotti also wonders above

Oops, missed that paragraph...

[gzotti]

I think this is what @gzotti also wonders above

Oops, missed that paragraph...

We have numerous reports about strange artifacts rendering horizon polygons (e.g. #4022). Some line parts are missing (which we also see here), and there are some spurious lines along the mathematical horizon. The StelSphereGeometry stuff, as ingenious it is, may have some issues. When I made the horizon polygons, there were occurrences of inverted filled areas when the horizon was very low. This was solved by making sure the zenith is "open". The situation did not improve when, during the Qt5->Qt6 adaptation, QList and QVector classes were merged, and some templated methods that used both classes with their respective particularities failed to build. It turned out (most of?) these methods were actually never used, though, so I excluded them (commented away), replacing specialized overrides by implementations of the respective base classes. Some time after that, we got new issue reports in that say the horizon polygon must not extend below 0°. This used to work previously, so maybe these overrides were used after all. However, that problem seems also to exist on latest Qt5 builds, where those overrides are still compiled.

If you have an idea what's wrong or want to have a look into it, you are more than welcome to fix it.

[gzotti]

THANK YOU, @gzotti , I love this new feature!

Use Cases (up to now)

1. initially, I wanted to visualize the area that is covered by a list of stars in ancient star catalogues, especially the gaps and overlaps

2. later, I also used them to compute the areas (in square degrees) that are covered by constellations

3. now I want to (doable with Youla's tool) also make little star catalogues of "all stars within the constellation area", which may be helpful to a) approach historical questions about the completeness of historical documents and b) astrophysical questions like "is this faint 20mag blackhole-binary within the historical constellation XY" (let's not discuss if these quesstions make sense - it's a fact that they are asked)

OK, so the next steps:

• - Add the dedicated infrastructure (GUI checkbox "draw convex hulls" and new color, managed in ConstellationMgr); However, I recommend hiding this for beginning users, and whoever needs that feature has to write a flag into config.ini to enable these elements. It would reduce screen clutter for likely most of users.

Do we need the hull feature also for asterisms? Probably not, as it is a somewhat artificial split needed mostly in modern_* SCs. However, we should still consider separating or flagging lunar stations/mansions as something special. (And by this, likewise flagging "culturally relevant zodiac" constellations. [sorry, this usually means 12, not 13...]). Currently we are (ab)using the asterism class for Lunar station asterisms where applicable (to make them stand out better, as they of course overlap with Solar Zodiac figures...), however the Indian-Vedic proposes artwork in some of these figures, which our Asterism class does not have.

• - re 1.) In index.json, a new entry inside constellation: "hull_completion": [StarId, ...]. These stars would simply be added to the definition of the hull.

• - re 2.) I hope SphericalRegion::getArea() does that out of the box. As said, these classes are super powerful, but, sigh, super underdocumented. A scripting function could create a text file (or CSV?) with (constellation, hull_area) entries.

• - re 3.) Without wanting to invalidate Youla's work (two solutions are better than one!): We could add a function in StarMgr that spits out a list of constellation names and the respective StarIds (HIP/Gaia numbers), or StarIds+coordinates (J2000 or current?) inside their hulls (via SphericalRegion::contains(Vec3d&)), as CSV or maybe xls. Do you need full-blown GUI support, or would you be happy with running a (built-in, delivered with package) script that creates such list in your user data directory? I'd prefer the latter, as this is IMHO really a 5-users-in-the-world research scenario. OTOH exposing such export button (with GUI that chooses output directory and file name) can likewise be hidden behind the power user flag in config.ini. Also, I have not investigated yet how to dump really all stars of a larger region. Such list (down to the faintest Gaia stars) can become very large. Or can we cut off magnitude somewhere? Or just limit ourselves to HIP stars? This will miss the blackhole star of course. Or would you set a Marker manually for the black hole, select it and would be happy to have the information in the InfoBox (top-left corner text), that the selected object is not only inside IAU constellation XY, but within the hull of current skyculture's constellations A and F (in case of overlaps)?

Any GUI changes should however wait for acceptance of #4179, which will among many other features bring dark constellations, after which their hulls will be added. @alex-w , @10110111 any opinions/reviews there?

[gzotti]

yes, the "one and two stars"-constellations are an issue: up to now, I always defined exceptions for them.

Now, as we have the circles for single star-asterisms, I think, I would use those; something like

n= number@starsInConstellation If n=1, use radius ELSE IF n =2 g = gravityCenter radius = distanceFromHIP2GravCenter + 1degr ELSE ... (usual case)

• - OK, that's easy then. However, 1-2-star constellations should receive a dedicated hull_radius entry (with fallback to single_star_radius for 1-star constellations, and 0.5deg for 2-star case) which would be added to distanceFromHIP2GravCenter to draw a big circle. There are dedicated SphericalRegions for these circles to be used as hulls.

[sushoff]

I would - as we did it with Youla - ALWAYS automatically compute the convex hull (we don't need the user's permission to do so)

• the user should have the option to display or not display them
• do we want to give the option to users (or only to SC contributors?) to add stars to the hull computation? (for creators, this sometimes makes sense - just think about the lists of stars "outside the constellation" in Ptolemy that won't be part of the stickfigure - but for users????) just asking

[sushoff]

THANK YOU, @gzotti , I love this new feature!
Use Cases (up to now)

1. initially, I wanted to visualize the area that is covered by a list of stars in ancient star catalogues, especially the gaps and overlaps

2. later, I also used them to compute the areas (in square degrees) that are covered by constellations

3. now I want to (doable with Youla's tool) also make little star catalogues of "all stars within the constellation area", which may be helpful to a) approach historical questions about the completeness of historical documents and b) astrophysical questions like "is this faint 20mag blackhole-binary within the historical constellation XY" (let's not discuss if these quesstions make sense - it's a fact that they are asked)

OK, so the next steps:

• - Add the dedicated infrastructure (GUI checkbox "draw convex hulls" and new color, managed in ConstellationMgr); However, I recommend hiding this for beginning users, and whoever needs that feature has to write a flag into config.ini to enable these elements. It would reduce screen clutter for likely most of users.

Do we need the hull feature also for asterisms? Probably not, as it is a somewhat artificial split needed mostly in modern_* SCs. However, we should still consider separating or flagging lunar stations/mansions as something special. (And by this, likewise flagging "culturally relevant zodiac" constellations. [sorry, this usually means 12, not 13...]). Currently we are (ab)using the asterism class for Lunar station asterisms where applicable (to make them stand out better, as they of course overlap with Solar Zodiac figures...), however the Indian-Vedic proposes artwork in some of these figures, which our Asterism class does not have.

• - re 1.) In index.json, a new entry inside constellation: "hull_completion": [StarId, ...]. These stars would simply be added to the definition of the hull.
• - re 2.) I hope SphericalRegion::getArea() does that out of the box. As said, these classes are super powerful, but, sigh, super underdocumented. A scripting function could create a text file (or CSV?) with (constellation, hull_area) entries.

• - re 3.) Without wanting to invalidate Youla's work (two solutions are better than one!):

BTW: yes, that will stay separately; a group of students is currently starting (today) to create the same again as a plugin

We could add a function in StarMgr that spits out a list of constellation names and the respective StarIds (HIP/Gaia numbers), or StarIds+coordinates (J2000 or current?)

only the identifiers: the J2000 coord. don't make sense for historical times - stars/ objects may move in/out of hulls with precession and proper motion ... it needs to be done per time layer and only on demand and perhaps by also filtering for a specific sort of objects (e.g. using the VSX with or SIMBAD object search within the boundaries of the hulls)

inside their hulls (via SphericalRegion::contains(Vec3d&)), as CSV or maybe xls.

yes ... :-) having in mind SIMBAD: they give several options. I would write CSV as this can be opened with EXCEL but also with notepad/ vi/ joe ...

Do you need full-blown GUI support, or would you be happy with running a (built-in, delivered with package) script that creates such list in your user data directory? I'd prefer the latter, as this is IMHO really a 5-users-in-the-world research scenario.

yes, I agree

OTOH exposing such export button (with GUI that chooses output directory and file name) can likewise be hidden behind the power user flag in config.ini. Also, I have not investigated yet how to dump really all stars of a larger region. Such list (down to the faintest Gaia stars) can become very large. Or can we cut off magnitude somewhere? Or just limit ourselves to HIP stars?

These options are already implemented in the above mentione d query-tools (SIMBAD, VSX). perhaps not reinvent the wheel? ;-)

So, new suggestion: just export the boundaries of the convex hull and start a SIMBAD-query in a browser within these borders.

This will miss the blackhole star of course. Or would you set a Marker manually for the black hole, select it and would be happy to have the information in the InfoBox (top-left corner text), that the selected object is not only inside IAU constellation XY, but within the hull of current skyculture's constellations A and F (in case of overlaps)?

Any GUI changes should however wait for acceptance of #4179, which will among many other features bring dark constellations, after which their hulls will be added. @alex-w , @10110111 any opinions/reviews there?

Yes, I've seen the Easter-egg-PR: looked into it, seems great - will get back later

[gzotti]

I would - as we did it with Youla - ALWAYS automatically compute the convex hull (we don't need the user's permission to do so)

* [ ]  the user should have the option to display or not display them

* [ ]  do we want to give the option to users (or only to SC contributors?) to add stars to the hull computation? (for creators, this sometimes makes sense - just think about the lists of stars "outside the constellation" in Ptolemy that won't be part of the stickfigure - but for users????) just asking

Computing the hull is done on loading, sure. It should still be updated periodically (once per year?) to deal with proper motion, though. Meanwhile I am even returning the hull in Constellation::getRegion() (I hope this does not break anything...) in order to get the star list (here I get some stars back, but not yet all. May need a look from @henrysky for this.)

But: I wonder how many users are interested in the feature in the first place (I have never seen it in any discussion outside your papers, but maybe I have just not read the right books in the last 44 years...), therefore I would prefer to hide even the GUI for it until users are advanced enough to edit config.ini. On my little observing laptop I'd probably not be interested at all and avoid GUI clutter. On my desktop with 34" screen, doing something else more scientific, maybe. Feel invited to write a motivation page for the User Guide how, why and when to apply those new features in users' everyday use of Stellarium. @alex-w , @10110111 opinions please: hide GUI by default, show GUI by default, or always show Hull GUI elements?

No, the star selection is similar to the stick figures, done by SC authors. Yes, Ptolemy's unformed stars and the Chinese "added" stars are the two applications coming to my mind. (Not sure if we can somehow add the "Added" stars by name search instead?) Of course, everybody can be author, make her private copy and add stars as seen fit.

Disprove my skepticism! I will invite the 50th, no, the 15th reported active, regular, serious user of this feature (not the 15th to try once!) to a drink when we meet at a conference or elsewhere. :-)

[sushoff]

well, for the "cone search" for any other object type then stars (the black hole binary etc.), I am thinking of use cases in astrophysics/ applied historical astronomy - yes, that's definitely not mainstream, and therefore not tought at universities ... and therefore, I was thinking about a tool for maybe five users or so: users of high level of education but not in history

for stars (at least those brighter than 6.5 mag), I have some use cases in mind but perhaps a bit fuzzy currently to articulate here. However, I admit that they are all technical - nothing what the average user will actively do with knowing it

OK with the decision to let only SC-authors add stars: so don't feel bothered by it: we will do that in the Sky Culture Maker-Dev-groups. :-) One thing less for you. :-)

[10110111]

opinions please: hide GUI by default, show GUI by default, or always show Hull GUI elements?

I guess you can hide it, but then the feature must be described in the User Guide, which the advanced users will likely(?) use and search (so "convex" and "hull" words need to be searchable).

[sushoff]

opinions please: hide GUI by default, show GUI by default, or always show Hull GUI elements?

I guess you can hide it, but then the feature must be described in the User Guide, which the advanced users will likely(?) use and search (so "convex" and "hull" words need to be searchable).

let's not call it "convex hull", but "historical constellation area". This will be something that users may indeed want to see I would create a button for it that is can be added to the menu like the boundary button (or use the boundary button instead - we had this discussion earlier but I don't remember the outcome).

[gzotti]

OK for "Constellation area" (somewhat shorter label), explained in the SUG more technically as convex hull (therefore the naming in json). The Guide is always searchable, but yes, these terms should all go into the index. There will be an action, configurable to be placed on a hotkey. But do we really need a separate button?

@sushoff please feel free to already add Ptolemy's unformed stars to the Almagest SC so we have a practical example ready in 25.2.

[gzotti]

These options are already implemented in the above mentione d query-tools (SIMBAD, VSX). perhaps not reinvent the wheel? ;-)

Ah, ok. Not working with SIMBAD on a regular basis, we'd need API, URLS etc. Maybe some example? This could be another query for the OnlineQueries plugin, of course.

But given that extracting data from our catalogs should also be about 10 lines of code, I'd like to have that offline as well.

[10110111]

But do we really need a separate button?

I guess what is meant is not a button but a combobox, e.g.

[x] Boundaries: [Defined by SC     ] [1 px <>][1 s <>]
                |Constellation area|

This will then not use too much space (there's some empty space between the checkbox and the spinboxes).

[sushoff]

"hull_extension": [ 38503, 37667, ...],

"Andromeda", "hull_extension: [113726]"
"Aquarius", "hull_extension: [1170, 910, 301]"
"Aquila", "hull_extension: [95501, 99473, 96468, 96483, 97804]"
"Aries", "hull_extension: [9884, 12489, 13209, 12719, 13061]"
"Bootes", "hull_extension: [69673]"
"Cancer", "hull_extension: [44798, 45410, 44946, 44405]"
"Canis Major", "hull_extension: [33971, 29034, 28199, 27628, 29807, 30277, 27204, 26634, 27810, 25859, 30788]"
"Centaurus", "hull_extension: [63003]"
"Cepheus", "hull_extension: [110991, 107259]"
"Corona Australis", "hull_extension: [92308, 93542, 92953, 94005, 90422]"
"Gemini", "hull_extension: [32921, 28734, 37300, 38722, 37908, 40167, 29696]"
"Hydra", "hull_extension: [41307, 50414]"
"Leo", "hull_extension: [53807, 61394, 53417, 60742, 54182, 59847, 52457, 53824]"
"Libra", "hull_extension: [76600, 76569, 78207, 77811, 78727, 76470, 76880, 73714, 76219]"
"Ophiuchus", "hull_extension: [88601, 88290, 88149, 88192, 88771]"
"Orion", "hull_extension: [25247]"
"Perseus", "hull_extension: [19949, 19811, 13254]"
"Pisces", "hull_extension: [443, 145, 154, 118209]"
"Piscis Austrinus", "hull_extension: [102831, 103738, 106327, 104177, 105382, 105696]"
"Scorpius", "hull_extension: [87072, UnknownEntity, [ M7], 85423]"
"Serpens", "hull_extension: [78554]"
"Taurus", "hull_extension: [16852, 27265, 25539, 26777, 23497, 24822, 28237, 26640, 27468, 27830, 26248, 17954]"
"Ursa Major", "hull_extension: [63125, 45860, 46952, 61317, 47029, 44700]"
"Virgo", "hull_extension: [67494, 64078, 61740, 64407, 62985, 64924]"

works in general - but what do I do with the M7 star cluster?

[gzotti]

Hmm, so far constellation stick figures consisted of HIP indices. You could identify any HIP/Gaia star at the right edge of M7 (so that M7 is mostly included in the hull) and add this. The long Gaia number must be coded as string, else it should work.

[gzotti]

But do we really need a separate button?

I guess what is meant is not a button but a combobox, e.g.

[x] Boundaries: [Defined by SC     ] [1 px <>][1 s <>]
                |Constellation area|

This will then not use too much space (there's some empty space between the checkbox and the spinboxes).

No, I think @sushoff wants a bottom bar button. These can be activated/configured a bit, of course, but still... an action/hotkey would be all I'd use.

I am afraid that of the 25 users of hulls, 20 will want both, borders and hulls, so the combo in the dialog is IMO not useful. I will add color/checkbox as usual, and hide them by default. The Guide will instruct users that there are more features and how to activate them. But only after #4179.

[alex-w]

I think for convex hulls UI should have separate elements (like for constellations or asterisms) - display, color, line width and opacity.

[sushoff]

Hmm, so far constellation stick figures consisted of HIP indices. You could identify any HIP/Gaia star at the right edge of M7 (so that M7 is mostly included in the hull) and add this. The long Gaia number must be coded as string, else it should work.

yes, that's what we are all doing up to now: a similar problem is, of course, omega Centauri, in many historical star catalogues...

but it would be better to allow coordinates of these ... there more (much fainter) globular clusters like this - some of them even have HR numbers (I found at least one some years ago and suppose that there are more)

[gzotti]

OK, for the hull_extension, it may be possible to either

• detect an Array instead of an integer/string, and if it's an array, it should be ["name", ra_decimalHours, dec_decimalDegrees]. These coordinates would be taken as J2000 coordinates. The name is mandatory and must be unique within the constellation! (needed technically for hull creation), or
• just write "DSO:M7" or "DSO:NGC5432". This would be separable from a Gaia star (which is a numerical string not starting with "DSO:"), and automatically provide the unique name. It is alsso much more author friendly and much more expressive, as in principle all objects which NebulaMgr can find are valid. Internally, we use StelObjectP anyhow, so we can ask StarMgr for a star or NebulaMgr for a DSO, this does not matter, both provide coordinates. This may be therefore the better approach.

Hmm, by this idea, maybe even the constellation lines themselves could include DSO like ω Cen. Let's try in the hull_extension first...

[gzotti]

"hull_extension": [ 38503, 37667, ...],

"Andromeda", "hull_extension: [113726]" "Aquarius", "hull_extension: [1170, 910, 301]"

@sushoff Are these to be inserted in modern or in greek_almagest?

[gzotti]

:-)

[sushoff]

I strongly support your second idea! @gzotti This will indeed solve several problems (with omega Cen in the Almagest etc.)

Yes, the list I had sent yesterday was for the Almagest (just quickly scripted from my private/local database)

[gzotti]

[gzotti]

"Scorpius", "hull_extension: [87072, UnknownEntity, [ M7], 85423]"

-->

"hull_extension": [87072, "DSO:M7", 85423],

But no idea what to do with UnknownEntity. Is this just your private annotation that there still is one unidentified object mentioned?

[sushoff]

"Scorpius", "hull_extension: [87072, UnknownEntity, [ M7], 85423]"

-->

"hull_extension": [87072, "DSO:M7", 85423],

But no idea what to do with UnknownEntity. Is this just your private annotation that there still is one unidentified object mentioned?

yes, it was in the script used to translate HR to HIP (when no HR, then "unknown entity") and I left it in to highlight the problem