Skip to content

satOmm2elem skips CelesTrak KVN files (MEAN_ELEMENT_THEORY = SGP/SGP4) #1673

Open

Description

@hneogy

hey, I tried the new OMM reader with gpconf and every record in a CelesTrak KVN file gets skipped with "Unsupported OMM MEAN_ELEMENT_THEORY: 'SGP/SGP4'; expected SGP4." CelesTrak writes MEAN_ELEMENT_THEORY = SGP/SGP4 in their KVN (their XML just says SGP4, so XML reads fine), so on their 565-object analyst file satOmm2elem ends up loading none. would you be ok treating SGP/SGP4 as SGP4? thanks!

Activity

  1. schaubh commented on Nov 10, 2026

    @schaubh
    Contributor

    Thanks for the feedback. working on a fix.

  2. self-assigned this
    on Nov 10, 2026
  3. hneogy commented on Nov 10, 2026

    @hneogy
    Author

    awesome, thanks! if you want I can re-run the CelesTrak KVN file through gpconf against your branch once it's up

  4. schaubh commented on Nov 10, 2026

    @schaubh
    Contributor

    Sure, that would be a great sanity check. I'm checking the omm handling more generally right now to see if there are other things to improve. I'll let you know when the branch is pushed into a PR to run the online checks.

  5. schaubh commented on Nov 10, 2026

    @schaubh
    Contributor

    @hneogy , the PR is now running CI tests, see #1675 if you want to pull this branch and test against your code.

  6. hneogy commented on Nov 10, 2026

    @hneogy
    Author

    ran #1675 (1497db5) through gpconf the same way as before and it does the job: satOmm2elem now loads all 565 records of CelesTrak's analyst KVN, where it loaded none, and the XML and JSON load all 565 too.

    across the corpus every KVN file but one reads right now. the one it still refuses is an OMM 3.0 record with no NORAD_CAT_ID. it says why, so your call whether that should be supported. as a bonus NORAD_CAT_ID = +25544 reads now, and a CSV cut off mid-row gets a clean "16 cells; expected 17" instead of a half-built record. nothing that passed before broke. thanks for the quick fix!

  7. hneogy commented on Nov 10, 2026

    @hneogy
    Author

    separate from the OMM side: running the TLE reader through gpconf turned up four things in tleHandling.py, and I have small fixes with tests for each (full suite passes, and they don't touch your #1675 changes):

    • a blank international designator fails the whole file (all of CelesTrak's analyst TLEs have one)
    • TLEs with ephemeris type 4 (SGP4-XP) run as plain SGP4, labelled SDP8
    • a name line starting with 1 or 2 (like 1KUNS-PF) gets read as a TLE line and fails the file
    • one bad set loses every set in the file

    would you like these as separate issues and PRs? the last one changes behaviour (skip the bad set with a warning instead of raising), so I wanted to check that's the direction you'd want first.

  8. schaubh commented on Nov 10, 2026

    @schaubh
    Contributor

    howdy @hneogy , let' make TLE reading a separate issue and PR please. Thanks for the support test driving these new features.

  9. hneogy commented on Nov 10, 2026

    @hneogy
    Author

    Sounds good, will open a TLE issue and PR shortly.

  10. schaubh commented on Nov 10, 2026

    @schaubh
    Contributor

    Just pushed a fix to the NORAD_CAT_ID issue you mentioned. Should be all good now. thanks for checking on your end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingenhancementNew feature or request

Type

No type

Projects

  • Status
    No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions