Expansion of skycultures through spatial and temporal extent

[mRaetz]

Description

This extension adds spatial and temporal dimensions to sky cultures. These are used to allow users to make interactive selections. The selection menu has been redesigned for this purpose. In addition to a list, users can now explore and select the available cultures using a time-resolved map.
All new cultures in the future should have both a temporal and spatial dimension, which is why the SkyCultureMaker plugin has been updated as well. In addition to a region selection feature, a simple digitization tool has been implemented that allows users to digitize the culture territories themselves. Furthermore, a few minor changes were made that could be described as bug fixes. For example, a problem with pressing the ESC key in ScmSkyCultureDialog was fixed, as well as the previously invisible button for the artwork tooltips in ScmConstellationDialog.

• addition of spatial of temporal dimension to skyculture def
• new menu for skyculture selection that allows exploration of the available cultures
• integration of spatial / temporal extension into the SkyCultureMaker plugin
• small changes / bugfixes to the SkyCultureMaker plugin

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?

This extension has been manually tested on a desktop PC (Windows 10) and a laptop (Windows 11). In both cases, there were no compatibility issues. However, no statement can be made regarding correct functionality on other operating systems.

Test specification:

• OS: Windows 10 / 11
• CPU: AMD Ryzen 7 2700x
• GPU: NVIDIA GeForce GTX 1660 Ti

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]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[alex-w]

@gzotti @sushoff is this pull request OK for merge?

[gzotti]

I did not yet check the GeoJSON. Hopefully tonight...

[mRaetz]

Just to avoid any confusion:
the latest commit only contains (commented-out) code for writing GeoJSON. I wasn't sure if I had understood the conversation correctly and whether we actually want to switch directly to GeoJSON. If that's what you want, I'm happy to update the reading part as well (I just didn't want to make the code too messy for now).

On this note (something I noticed yesterday): some cultures on the main branch (at least one, namely norse_edda) already have a territory file. However, this was created using one of the SCM prototypes I provided to @sushoff during the development process. Since some things have changed since then, this skyculture isn’t being read correctly by the skyculture explorer. (I guess if we switch to GeoJSON, it would have to be redone anyway.)

[sushoff]

@mRaetz ok, thanks for the note - so I'd need someone to create polygons ... :-) Good that I didn't have time for it so far ;-) thanks for notifying me!

[gzotti]

I have a preference to use existing applicable standard formats and switch before the old format is being circulated. If it's only norse_edda, this can be converted manually. The advantage is using other tools which already exist and which may have special capabilities that facilitate editing. Although I have not used it by now, QGIS has GeoJSON capabilities, at least via dedicated plugins. A very easy-to-use interface for drawing is geojson.io. In the right part of the Window the created GeoJSON is displayed, and you would have (for now) to add the beginDate/endDate properties manually. Maybe the territory file should be named territory.geojson to make it easier to understand.

[gzotti]

I have just pushed an editor-converted territory.geojson of norse_edda to master. It loads in QGIS, so should be OK. The geojson file and map use still has to be described in the user guide. Here we can write that only polygon features are supported, and other feature types ignored. The older format should then go away without sorrow. I can imagine authors will want to start editing the polygons in SCM but may want to refine later. And adding the missing polygons later this year should be much easier with this. (with or without bespoke QGIS import/export plugin)

[mRaetz]

I have a preference to use existing applicable standard formats and switch before the old format is being circulated

That sounds to me like we're going to use GeoJSON directly? If so, I'll push the changes so that the territory.geojson files are read correctly. (?)

I have just pushed an editor-converted territory.geojson of norse_edda to master.

It's looking pretty good, but im afraid those weren't the only issues. The endTime is still an int (while the current implementation uses a string), and the entries for the global beginTime and endTime are missing from the index.json file.

Another thing (that isn't really due to the format, but it's probably something that could have been avoided):
There's an artifact between the polygons that likely has no business being there, but is instead a result of the digitization process.

[gzotti]

I have a preference to use existing applicable standard formats and switch before the old format is being circulated

That sounds to me like we're going to use GeoJSON directly? If so, I'll push the changes so that the territory.geojson files are read correctly. (?)

If nobody objects by tomorrow (@alex-w , @10110111 , @sushoff ?), I see no point in keeping the self-made format.

I have just pushed an editor-converted territory.geojson of norse_edda to master.

It's looking pretty good, but im afraid those weren't the only issues. The endTime is still an int (while the current implementation uses a string),

Ah, you can change the property type then. As I understand the properties are a dictionary where the data types are defined as required. However, you could also just use 10.000 as special marker value.

and the entries for the global beginTime and endTime are missing from the index.json file.

Where should it go? It is not described in the specifications (User Guide), so I know nothing about it.

Another thing (that isn't really due to the format, but it's probably something that could have been avoided): There's an artifact between the polygons that likely has no business being there, but is instead a result of the digitization process.

Right, but it was already there. Maybe we can repair this into a 4th polygon feature later. I was not aware of this file until 2 hours ago...

[alex-w]

That sounds to me like we're going to use GeoJSON directly? If so, I'll push the changes so that the territory.geojson files are read correctly. (?)

If nobody objects by tomorrow (@alex-w , @10110111 , @sushoff ?), I see no point in keeping the self-made format.

+1 for using standard formats

[mRaetz]

• The GeoJSON files should now be read correctly.
• I've “fixed” the norse_edda culture (added beginTime / endTime in index.json and removed the artifact we talked about yesterday).
• I also changed the data type of endTime from string back to integer. The new special value in the territory.geojson file is now 9146.

[gzotti]

9146... do you mind sharing any deeper explanation for this? (It will be a documented code, so whatever it is. Just that users will be curious.)

[mRaetz]

previously it was "∞", the symbol for infinity. alpha to num: I = 9, N = 14, F = 6 (INF or 9146)

[gzotti]

Argh. I tested the PR and just wanted to approve this as it now really works (at least I could not find new problems. I have not tested image aligning since February though. This should not have changed presumably). I am now reading of a rebase problem, but a squash/merge should work here as well. It's one big feature change. I will add user changes to the SUG on weekend, hoping I don't mis-describe the new features.

[10110111]

Oops, this breaks the Surveys tab:

[alex-w]

Damn... The tab Sky Culture has troubles too

[gzotti]

Seems some widget definition was duplicated in the survey tab. Going into it now...

EDIT: Fixed. One lengthy widget duplicate removed.

[10110111]

Why do we have minimumSize=1500 in culturesListWidget? This makes the window unnecessarily huge.
Also, I get this warning multiple times when using Qt Designer on viewDialog.ui:

Could not create pixmap from :/graphicGui/uieSearchBoxBackground.png

[10110111]

What is the map supposed to be used for? I see cities marked on it, but no symbols for the location of at least the current SC.

[mRaetz]

Why do we have minimumSize=1500 in culturesListWidget?

I'm not entirely sure anymore, but I think the list was so “thin” that some names were not easily readable or couldn't be distinguished from others. But maybe that's unnecessary and should be removed. I've never had a problem with the size on my screen, but I can imagine it might be an issue on smaller screens.
As for the error in QtDesigner, I can't say anything about it because I don't get that error message. (I'm using version 6.5.8).

What is the map supposed to be used for? I see cities marked on it, but no symbols for the location of at least the current SC.

Are we talking about how the territory of skycultures is represented? This is done using polygons that currently do not exist. For skycultures like “modern,” these will likely never exist, since there isn't really a definable territory for them.

[10110111]

This is done using polygons that currently do not exist.

Ah, that explains it.

As for the error in QtDesigner, I can't say anything about it because I don't get that error message.

Yeah, somehow Stellarium itself also finds the file successfully.

[gzotti]

Map: Each SC can now have a GeoJSON file territory.geojson that shows its location as click-selectable polygon. The time slider below would show the localisation of the SCs as coded in beginTime/endTime properties. The polygon can be created when defining a SC with the SCM plugin, and probably edited/refined with general GIS tools like QGIS. So far, only Norse-Edda has it, but we should add those files to all non-"World" SCs in the upcoming months to populate the map (#4842). I have disabled a warning for missing polygon for now.