Satellites: Allow Satellite Number to be zero

[normanr]

Description

6a7afb8 added stripping of leading zeros, but a temporary/manually created Orbital Element may have a Satellite Number of zero, and that should be allowed.

I considered replacing the regular expression with QString::toInt() and QString::number(), but that's a larger change and doesn't allow non-numeric values. Adding the "not at a word boundary" assertion at the end is much simpler.

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?

I've added a unit test to test that 00000 and 0 both parse and return 0.

Test Configuration:

• Operating system: Debian Linux
• Graphics Card: Intel(R) UHD Graphics 620

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

[gzotti]

The NORAD number in my understanding is not for the user to play. I can neither approve nor disapprove this. Is Zero allowed with other programs that process TLE?

[normanr]

The NORAD number in my understanding is not for the user to play. I can neither approve nor disapprove this. Is Zero allowed with other programs that process TLE?

I got TLE data from flightclub.io for the (currently) future Starship Orbital Flight Test, so there's no official NORAD number yet. I hand edited the data to give it a non-zero number, but I think it would be nice if Stellarium handled it without the work-around.

Comments in https://celestrak.com/columns/v04n03/ seems to indicate that leading spaces and zeros should be treated the same, but then gives an example of non-leading zeros being replaced with spaces. Stellarium's parsing worked fine before 6a7afb8. I suspect that replacing all spaces with zeros would also be a valid way to parse the field.

In the long term NORAD is switching to Orbit Mean-Elements Message which is XML based, and will probably have less ambiguous representation of data.

[alex-w]

The use case is very specific, but the fix is acceptable

[github-actions]

Hello @normanr!

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

[github-actions]

Hello @normanr!

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