Fix observing list import/export

[gzotti]

Fix a few quirks and a real bug in ObsList import and export.

Description

List export exports a single list.
On import, the name of the list is checked.

List date is date of creation, not of last edit. Maybe we should change that?

The oh-so-important OLUD is actually not tested. If a list is created, an OLUD is given. Exporting to file, editing the "live" list, storing and importing the previously exported would (I think) just overwrite the existing list with same OLUD. Is this not what should have been avoided? What is the scenario?

Fixes

• Importing observe list doesn't replace default observe list #3206 (issue)
• after loading a list, show it immediately and fill its name in the name combo
• On export, let users export single lists (ending: .sol) or the whole list of lists .ol
• Change timestamp from list creation date to date of last edit.
• On import, make sure to test existing lists not by name and last date, but by OLUD (or all 3?)
• (other observations)

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

How Has This Been Tested?

Test Configuration:

• Operating system: Win11
• Graphics Card: 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.

[alex-w]

I didn't check the code yet, but I have important notification for import/export feature. In the original idea the OL is contains many lists of objects with some description and settings, of course, the OLUD is unique identifier for each list. The import/export feature should import/export one list per file and by the fact OL should support 2 formats of files - OL (all lists) and SOL (single observing list - the format for exchange the data). By the fact currently the format of SOL file is wrong. :(

See my observing lists file and exported default list from v23.1:
observingList.json.txt
observingList_default.json.txt

[gzotti]

The SOL/OL distinction was never discussed before January I think. Can you please edit the PR description with checkable list entries what should be done. And then please help to implement these things, esp. OL/SOL stuff. Not starting on June 15, but this weekend, finish by ~May 20 to allow real beta testing before release. I have never seriously used the lists in the new format, so some issues evaded my attention.

I just see the danger written above that the whole OLUD idea is useless if it allows edit/export/import without giving a new OLUD. Probably a new OLUD should be given whenever content changes (basically, create a checksum from list contents: entries, name, date), so that each import can immediately see whether this list exists already of if it was changed. We could then as well use the list name as key (instead of OLUD), plus a checksum entry for that purpose of identification. (Format 3.0...)

[ilkant]

I think that two timestaps to observe lists are good. Creation timestamp and last edited timestamp. Like Linux files.

[alex-w]

The SOL/OL distinction was never discussed before January I think. Can you please edit the PR description with checkable list entries what should be done.

I should find all my record for this feature before editing checklist...

And then please help to implement these things, esp. OL/SOL stuff. Not starting on June 15, but this weekend, finish by ~May 20 to allow real beta testing before release.

Good point

I have never seriously used the lists in the new format, so some issues evaded my attention.

Same problem

I just see the danger written above that the whole OLUD idea is useless if it allows edit/export/import without giving a new OLUD. Probably a new OLUD should be given whenever content changes (basically, create a checksum from list contents: entries, name, date), so that each import can immediately see whether this list exists already of if it was changed. We could then as well use the list name as key (instead of OLUD), plus a checksum entry for that purpose of identification. (Format 3.0...)

No. The OLUD should be unique within one collection of observing lists, but we've never guaranteed unique OLUD for whole world span. I hope in some time later on our website will be added new category for user contributed data - favorites/observing lists with good description and interesting data.

[gzotti]

Is the OLUD ever checked? Or will importing a renamed list with same OLUD overwrite an existing list? The latter case must be avoided, else the whole idea is broken! So, at least when importing, the check must be extended to not just name, but also OLUD.

[ilkant]

I have a vision: Observe list could be a set of objects. And then there can be a script which creates a star trek using the observation list. And the user can share and receive lists of observation points from others.

I have also thought that in those previous situations it is not necessary that all the information about the target has been stored in the list. However, if the data is in Stellarium data. But if that list is a list of the user's own observations, then there should be places for all the information obtained from the observation.

[gzotti]

These lists retrieve data from the program. Some people seem to have interest in using these lists externally.

Storing one's own observation notes is not intended at this stage. Years ago, an observation logger was allegedly planned, but without an actual usage scenario apparently went nowhere. I have read about a 3rd-party library/format/spec, but others may be more in actual "observing" than me.

[alex-w]

Is the OLUD ever checked? Or will importing a renamed list with same OLUD overwrite an existing list?

Well, as far as I remember the process of importing list into collection should add new list - not just adding some elements into existing one. Of course at this step OLUD is checked and the list will not import if collection have data with same OLUD.

The latter case must be avoided, else the whole idea is broken! So, at least when importing, the check must be extended to not just name, but also OLUD.

I fear in some chunk of refactoring (or probably someone requested it) the behaviour was changed to allow the ability of merging the lists.

[alex-w]

I have a vision: Observe list could be a set of objects. And then there can be a script which creates a star trek using the observation list. And the user can share and receive lists of observation points from others.

I have also thought that in those previous situations it is not necessary that all the information about the target has been stored in the list. However, if the data is in Stellarium data. But if that list is a list of the user's own observations, then there should be places for all the information obtained from the observation.

The observing log is different task and it is not in aim of observing lists. The observing lists by the fact is the collection of few bookmarks (favorites) lists.

[gzotti]

@alex-w, Storing (exporting) the whole ObsList as .ol is identical to copying the observingList.json file, right?
What about the file type options? Should I allow import of "*.json, *.ol, *.sol" (do we need to support *.json for legacy, or just skip that?) and, on export, discern "export all" and "export current list" just by the selected extension, one of "*.ol" or "*.sol"?

[alex-w]

I guess .sol for single list and .json for legacy/bookmarks. No need "export all" feature IMHO.

[gzotti]

You had expressed earlier that you want OL and SOL. It was not terribly hard to do so, so now it's done. A .sol is just a one-list .ol, and .ol has the same format as the observing list flavor of what was by now .json.

I can export and import lists. Hopefully it is done.

[github-actions]

Hello @gzotti!

The enhancement or feature has been merged into source code and you may test it via building Stellarium from source code or wait the weekly development snapshot...

[alex-w]

Thanks!

[github-actions]

Hello @gzotti!

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[github-actions]

Hello @gzotti!

Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest