Improve TLE data management

[csete]

There are several flaws in the way Gpredict manages TLE data. A summary of how the application behaves now:

1. Gpredict is distributed with a copy of almost all satellites from http://celestrak.com -- This data becomes out of date within a few weeks and for this to work would require a monthly release.
2. The first time gpredict is started it checks the user config for satellite data and copies all data from the distribution into user config (regardless of age).
3. Gpredict also creates a default .qth and a default .mod file.
4. If the user manually deletes unwanted satellites from the user config, gpredict will recreate these data the next time it is started.
5. There is no way to remove satellites from the user config and the user ends up with tons of decayed objects in the local config.
6. When TLE is updated new sats are added (if configured) but obsolete sats are not deleted.
7. There is no easy way to remove a satellite or a category.
8. There is no easy way to add a new satellite or a category.

Possible solutions to the flaws:

1. Don't distribute any satellite data with gpredict.
2. The first time gpredict is run or if there are no TLE data in the user config, offer to download data from celestrak or import file from local file. If the user chooses to import data from celestrak (one or more of the predefined files e.g. amateur.txt) add those files to the list of files to be fetched when updating TLE from the web. Also create a category based on the name of the imported file.
3. Default QTH is ok and I suppose we should create a default module using a random satellite from the imported data.
4. Solved by item 2.
5. Solved by item 2.
6. Improve the TLE updater to first update the existing satellites then offer the option to add new satellites and remove obsolete ones. The choices are remembered in the config.
7. Need a basic satellite editor (perhaps after v1.4)
8. Need a basic satellite editor (perhaps after v1.4)

[cureton]

Hi Alex,
I have been thinking about a solution for this for the trsp files. Obviouly they are less dynamic that the TLE files however there may be a parallels. With the updates I have just submitted a pull-request for I realise that it will overwrite user developed trsp files with the distributed ones shoud a user upgrde the release of gpredict.

One solution is to distribute the trsp files in the distribution in the /usr/share/gpredit/trsp location, however upon loading the trsp files, first look in the user area first (~/.config/Gpredict/trsp), then failing that look in the /usr/share/gpredict/trsp location. That was the user can overwrite the system files as they wish.

This approach would also allow the distribution of the trsp and tle files as "volitile" packages in a lnux distribution at they contain only data and not code. Much the same was as the tzdata files are distributed. Therefore updates to "stable" distribution release can be release in a timely manner. (I'm looking at debian here)

This approach suits the trsp files better than the TLE file, but I think the approach has some merit.
What do you think?

[csete]

I think today it makes very little sense to distribute any satellite data files with gpredict. For most users it will be possible to download the current data when they first run the application.

[alexf91]

A seperate Github repository for the transponder files might be good.
This way, users of an official release could also update their transponder data and the files would still be under version control.

[csete]

Don't think I will ever have time to finish this, so I am working on a simplified version of this.