Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Orekit Orekit
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 90
    • Issues 90
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 16
    • Merge requests 16
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Orekit
  • OrekitOrekit
  • Issues
  • #867
Closed
Open
Created Dec 03, 2021 by Clément Jonglez@yzokrasDeveloper

SinexLoader doesn’t handle multiple historical eccentricities for a same station

When reading the eccentricities file for ILRS stations (https://ilrs.gsfc.nasa.gov/network/site_procedures/eccentricity.html), I realized that Orekit does not support multiple eccentricity entries for a same station. This is used in ILRS stations to indicate the historical detector positions in case it was moved or in case a new survey provides a better estimation of the detector position. For instance for the Yarragadee station (7090), there are 18 entries with each a validity time interval, see ecc_xyz.snx lines 888 to 905.

Looking at the source code in SinexLoader.java from line 232, Orekit's behaviour is the following:

  • Set the validity time interval of the Station object based on the first entry found for this station (for Yarragadee, it gives 1979-07-01T00:00:00.000Z to 1983-07-26T23:59:58.000Z)
  • Set the eccentricities based on the last entry found for this station (for Yarragadee, it gives [-1.2073; 2.5034; -1.5509])

A possible fix could be:

  • Set the validity time interval of the Station object from the start time of the first segment until the end time of the last segment found for this station
  • Store all the historical eccentricity data in a TimeSpanMap
  • Add a method Station::getEccentricities(AbsoluteDate date) to return the eccentricity value corresponding to the time input by the user
    • To not break existing code, maybe the method Station::getEccentricities() could be kept and could return the latest eccentricity value
Edited Dec 03, 2021 by Clément Jonglez
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking