Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2019-02-03T19:20:38Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/512Add weather model GPT22019-02-03T19:20:38ZBryan CazabonneAdd weather model GPT2Same as issue #511 but with the Global Pressure and Temperature 2 (GPT2) model.
GPT2 model is an improvement of GPT model.
More information about this model can be found at : [GPT2](http://vmf.geo.tuwien.ac.at/documentation/Lagler%20et...Same as issue #511 but with the Global Pressure and Temperature 2 (GPT2) model.
GPT2 model is an improvement of GPT model.
More information about this model can be found at : [GPT2](http://vmf.geo.tuwien.ac.at/documentation/Lagler%20et%20al.,%202013%20%20%20(GPT2).pdf)9.3Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/513Add clock bias in measurements2019-02-01T18:07:12ZLuc MaisonobeAdd clock bias in measurementsMeasurements made by ground stations may be affected by clock biases.
Such a bias should be available for estimation in orbit determination.Measurements made by ground stations may be affected by clock biases.
Such a bias should be available for estimation in orbit determination.9.3Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/514Deprecate then delete unused DerivativeStructure acceleration computation met...2019-07-05T17:41:52ZMaxime JournotDeprecate then delete unused DerivativeStructure acceleration computation methodsSome methods computing `FieldVector3D<DerivativeStructure>` acceleration and using a parameter name as input should have been deleted in version 9.0 but were left over.
They should be deemed `@Deprecated` in version 9.3 and then deleted ...Some methods computing `FieldVector3D<DerivativeStructure>` acceleration and using a parameter name as input should have been deleted in version 9.0 but were left over.
They should be deemed `@Deprecated` in version 9.3 and then deleted in version 10.0.
These methods are:
- `FieldVector3D<DerivativeStructure> dragAcceleration` in interface [DragSensitive](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/DragSensitive.java#L117) and all its implementations;
- `FieldVector3D<DerivativeStructure> radiationPressureAcceleration` in [RadiationSensitive](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/radiation/RadiationSensitive.java#L90) and all its implementations
Related tests should also be deprecated then deleted.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/515add clock offset for inter-satellite measurements2019-02-01T18:07:12ZLuc Maisonobeadd clock offset for inter-satellite measurementsThis is the same as issue #513, but for inter-satellites measurements.This is the same as issue #513, but for inter-satellites measurements.9.3Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/516GPSPropagator should manage clock corrections2019-02-03T19:16:33ZLuc MaisonobeGPSPropagator should manage clock correctionsThe GPSPropagator should be able to provide clock corrections, including the relativistic correction related to the propagated state as additional states.The GPSPropagator should be able to provide clock corrections, including the relativistic correction related to the propagated state as additional states.9.3Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/517GPT2 model uses hardcoded 5° step2019-02-03T19:16:15ZLuc MaisonobeGPT2 model uses hardcoded 5° stepThe GPT2 model cannot load grids with finer or coarser step sizes than an hardcoded value of 5°.
As the grids include the latitude/longitude values, they could theoretically be loaded with a
different step size. Indeed, tuwien does provi...The GPT2 model cannot load grids with finer or coarser step sizes than an hardcoded value of 5°.
As the grids include the latitude/longitude values, they could theoretically be loaded with a
different step size. Indeed, tuwien does provide at least to step sizes: 1° and 5°.9.3Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/518AbstractGNSSAttitudeProvider should be private package2019-07-05T17:41:50ZPetrus HyvönenAbstractGNSSAttitudeProvider should be private packageThe AbstractGNSSAttitudeProvider is not usable outside the attitude package and was not intented (ref Luc) for public usage. This package should thus be set private.The AbstractGNSSAttitudeProvider is not usable outside the attitude package and was not intented (ref Luc) for public usage. This package should thus be set private.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/519Add GLONASS Propagator2019-07-05T17:41:53ZBryan CazabonneAdd GLONASS PropagatorAs it is already done in Orekit for GPS orbits, it can be interesting to add a Glonass propagator to convert Glonass almanac data to position and velocity vector components.
Steps of computation are present into [GLONASS Interface Contr...As it is already done in Orekit for GPS orbits, it can be interesting to add a Glonass propagator to convert Glonass almanac data to position and velocity vector components.
Steps of computation are present into [GLONASS Interface Control Document](http://gauss.gge.unb.ca/GLONASS.ICD.pdf)10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/520Add Galileo Propagator2019-07-05T17:41:52ZBryan CazabonneAdd Galileo PropagatorSame as issue #519 but for Galileo almanacs.
Steps of computations are available into [Galileo Interface Control Document](https://www.gsc-europa.eu/system/files/galileo_documents/Galileo-OS-SIS-ICD.pdf)Same as issue #519 but for Galileo almanacs.
Steps of computations are available into [Galileo Interface Control Document](https://www.gsc-europa.eu/system/files/galileo_documents/Galileo-OS-SIS-ICD.pdf)10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/521Add BeiDou Propagator2019-07-05T17:41:53ZBryan CazabonneAdd BeiDou PropagatorSame as issue #519 and #520 but for BeiDou satellites.
Steps of computation are detailed into [BeiDou Interface Control Document](http://en.beidou.gov.cn/SYSTEMS/Officialdocument/201806/P020180608525875134604.pdf)Same as issue #519 and #520 but for BeiDou satellites.
Steps of computation are detailed into [BeiDou Interface Control Document](http://en.beidou.gov.cn/SYSTEMS/Officialdocument/201806/P020180608525875134604.pdf)10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/522Add QZSS Propagator2019-07-05T17:41:53ZBryan CazabonneAdd QZSS PropagatorSee issues #519 #520 #521
Steps of computation are available on the [QZSS Interface Specification](http://qzss.go.jp/en/technical/download/pdf/ps-is-qzss/is-qzss-pnt-003.pdf?t=1549268771755)See issues #519 #520 #521
Steps of computation are available on the [QZSS Interface Specification](http://qzss.go.jp/en/technical/download/pdf/ps-is-qzss/is-qzss-pnt-003.pdf?t=1549268771755)10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/523Add support for loading RINEX navigation file2021-03-10T10:34:16ZGowtham SivaramanAdd support for loading RINEX navigation fileOrekit (as of v9.3) supports RINEX (measurement/observation files) versions 2.x and 3.x. But the support for loading navigation files (Eg: ftp://cddis.nasa.gov/gnss/data/daily/2019/035/19n/brdc0350.19n.Z) is lacking. The RINEX data forma...Orekit (as of v9.3) supports RINEX (measurement/observation files) versions 2.x and 3.x. But the support for loading navigation files (Eg: ftp://cddis.nasa.gov/gnss/data/daily/2019/035/19n/brdc0350.19n.Z) is lacking. The RINEX data format document (ftp://igs.org/pub/data/format/rinex301.pdf
) discusses the format of navigation file broadcasted.
Similar to SEM/YUMA parsers, the support to run GPSPropagator at the end of loading RINEX navigation files can be made available.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/524Endless propagation when detector is equal to 02019-11-13T16:01:13ZMikael FillastreEndless propagation when detector is equal to 0Following this discussion : https://forum.orekit.org/t/cross-dependence-between-model-detector-and-handler/385
With the code attached [DetectorClosedLoopControlTest.java](/uploads/d3242bf3a3f6532d28c6982b261e001e/DetectorClosedLoopContro...Following this discussion : https://forum.orekit.org/t/cross-dependence-between-model-detector-and-handler/385
With the code attached [DetectorClosedLoopControlTest.java](/uploads/d3242bf3a3f6532d28c6982b261e001e/DetectorClosedLoopControlTest.java)
I use a detector to reach a value, once reached (eventoccured called on handler) the source of evolution is removed and the detector stays at 0 which causes the propagator to loop infinitely.
Here is the code which loops infinitely : ![infinite_loop](/uploads/9d4ee30bd6792eedb9f1f99487f6a672/infinite_loop.PNG)https://gitlab.orekit.org/orekit/orekit/-/issues/525How to use BatchLSEstimator with GPSPropagator?2023-07-21T11:50:59ZGowtham SivaramanHow to use BatchLSEstimator with GPSPropagator?A typical problem of Orbit determination of LEO satellites using GNSS involves processing InterSatellitesRange with remote satellite being one of the GNSS satellites. But the BatchLSEstimator requires the constellation to be propagated n...A typical problem of Orbit determination of LEO satellites using GNSS involves processing InterSatellitesRange with remote satellite being one of the GNSS satellites. But the BatchLSEstimator requires the constellation to be propagated numerically (instead of using GPSPropagator).
Since the Numerical propagation of the constellation requires PV data, which typically is unavailable (even with IGS final product). It would be a great feature to implement a separate propagator to interpolate the position solution from IGS data (as mentioned here: https://gssc.esa.int/navipedia/index.php/Precise_GNSS_Satellite_Coordinates_Computation) which can be fed into BatchLSEstimator to use for the orbit determination.https://gitlab.orekit.org/orekit/orekit/-/issues/526Remove private class BilinearInterpolatingFunction into Saastamoinen model2019-07-05T17:42:39ZBryan CazabonneRemove private class BilinearInterpolatingFunction into Saastamoinen modelBilinearInterpolatingFunction is available into Hipparchus since release 1.4. Hence, it is possible to replace the private class BilinearInterpolatingFunction of the Saastamoinen model by the one of Hipparchus.BilinearInterpolatingFunction is available into Hipparchus since release 1.4. Hence, it is possible to replace the private class BilinearInterpolatingFunction of the Saastamoinen model by the one of Hipparchus.10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/527SI base unit API for magnetic field model2019-07-05T17:41:53ZBryan CazabonneSI base unit API for magnetic field modelCurrent API for magnetic field model is not in SI base unit. Magnetic field is computed using latitude and longitude in degrees and height in kilometers as input parameters. Furthermore, `getDeclination()` and `getInclination()` methods ...Current API for magnetic field model is not in SI base unit. Magnetic field is computed using latitude and longitude in degrees and height in kilometers as input parameters. Furthermore, `getDeclination()` and `getInclination()` methods in `GeoMagneticElements.java` class return angles in degree unit. API has to be change to consider angles in radians and height in meters.10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/528getClockCorrection from SP3File returns value in megaseconds2019-07-05T17:42:39ZGowtham SivaramangetClockCorrection from SP3File returns value in megasecondsWhen trying to load clock corrections value using `SP3Parser` from an sp3 file, the value returned by `getClockCorrection` is in megaseconds, although the document specifies seconds.
During parsing of SP3 file, `latestClock` is multipl...When trying to load clock corrections value using `SP3Parser` from an sp3 file, the value returned by `getClockCorrection` is in megaseconds, although the document specifies seconds.
During parsing of SP3 file, `latestClock` is multiplied by 1E6 instead of 1E-6. Similarly issue exists for `clockRateChange` also.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/529Attitude transitions in analytical propagators2019-07-05T17:42:40ZMirco RasottoAttitude transitions in analytical propagatorsWhen trying to use the attitude sequence with an Ephemeris object, an OUT_OF_RANGE_SIMPLE exception is thrown.When trying to use the attitude sequence with an Ephemeris object, an OUT_OF_RANGE_SIMPLE exception is thrown.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/530Removing Serializable for events detectors and attitude providers2019-06-14T20:00:01ZLuc MaisonobeRemoving Serializable for events detectors and attitude providersAs per discussion [https://forum.orekit.org/t/removing-serializable-for-events-detectors-and-perhaps-attitude-providers/403](https://forum.orekit.org/t/removing-serializable-for-events-detectors-and-perhaps-attitude-providers/403), seria...As per discussion [https://forum.orekit.org/t/removing-serializable-for-events-detectors-and-perhaps-attitude-providers/403](https://forum.orekit.org/t/removing-serializable-for-events-detectors-and-perhaps-attitude-providers/403), serialization should be removed for at least event detectors and attitude providers.10.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/531Remove TroposphericModel interface2019-07-05T17:41:52ZBryan CazabonneRemove TroposphericModel interfaceSince Orekit 9.3, a new interface is available for tropospheric models (`DiscreteTroposphericModel`).
Because of compatibility issues, we did not delete the interface `TroposphericModel` for Orekit 9.3 release. Major release allowing API...Since Orekit 9.3, a new interface is available for tropospheric models (`DiscreteTroposphericModel`).
Because of compatibility issues, we did not delete the interface `TroposphericModel` for Orekit 9.3 release. Major release allowing API changes it is possible for Orekit 10.0 release to delete this interface. Implementations of the old interface `TroposphericModel` should now implement `DiscreteTroposphericModel`.10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/532Add Shapiro effect2019-06-14T19:59:46ZLuc MaisonobeAdd Shapiro effectFor very accurate (centimeter level) range measurements, the relativistic Shapiro effect
should be considered.For very accurate (centimeter level) range measurements, the relativistic Shapiro effect
should be considered.10.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/534GPS Almanac parsers missing GPS week number rollover2019-05-09T20:53:14ZGowtham SivaramanGPS Almanac parsers missing GPS week number rollover`YUMAParser` and `SEMParser` does not take into account, the GPS week number rollover. YUMA and SEM files contain week number (mod 1024).
Since the date of the almanac is created using `GPSDate` (from v9.3) whose constructor requires ab...`YUMAParser` and `SEMParser` does not take into account, the GPS week number rollover. YUMA and SEM files contain week number (mod 1024).
Since the date of the almanac is created using `GPSDate` (from v9.3) whose constructor requires absolute week number and time of the week, the `getDate()` function of the almanac returns incorrect date.https://gitlab.orekit.org/orekit/orekit/-/issues/537`FIXME` in EKF code2023-10-31T19:48:47ZHao Peng`FIXME` in EKF codeCurrently I'm using the EKF provided as a sequential estimation package. I found many code snippets commented as `FIXME`. Could you guys provide more explanation about these `FIXME`? To my understanding, they should imply errors, but the...Currently I'm using the EKF provided as a sequential estimation package. I found many code snippets commented as `FIXME`. Could you guys provide more explanation about these `FIXME`? To my understanding, they should imply errors, but the result looks correct.
Specifically, I would like to know if the `FIXME` in `/orekit-main/src/main/java/org/orekit/estimation/sequential/UnivariateProcessNoise.java` has been fixed or not yet? Thank you.
[A list of all the `FIXME` in the `master` branch.](https://gitlab.orekit.org/search?utf8=%E2%9C%93&search=fixme&group_id=&project_id=1&search_code=true&repository_ref=master)https://gitlab.orekit.org/orekit/orekit/-/issues/538Problem with method ComparableMeasurement.compareTo()2019-07-05T17:42:40ZDorian GegoutProblem with method ComparableMeasurement.compareTo()It seems there is a bug the method ComparableMeasurement.compareTo() which allow violation of the transitivity rule. Further details are explained on https://forum.orekit.org/t/problem-with-method-comparablemeasurement-compareto/438It seems there is a bug the method ComparableMeasurement.compareTo() which allow violation of the transitivity rule. Further details are explained on https://forum.orekit.org/t/problem-with-method-comparablemeasurement-compareto/43810.0https://gitlab.orekit.org/orekit/orekit/-/issues/539Deprecated day of year computation in DTM2000 model.2019-07-05T17:42:36ZMaxime JournotDeprecated day of year computation in DTM2000 model.DTM2000 atmosphere class uses Java class GregorianCalendar in method [getDensity](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/atmosphere/DTM2000.java#L333) to compute the day of year.
No Tim...DTM2000 atmosphere class uses Java class GregorianCalendar in method [getDensity](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/atmosphere/DTM2000.java#L333) to compute the day of year.
No TimeZone is provided so that the default TimeZone is used. Default TimeZone depends on user's machine so it can be different than "GMT+00".
Day of year computation should not be dependent on user's default time zone.
Method [DateComponents.getDayOfYear](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/time/DateComponents.java#L447) should be used instead (as in [NRLMSIS00.getDensity](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/forces/drag/atmosphere/NRLMSISE00.java#L1127)).10.0https://gitlab.orekit.org/orekit/orekit/-/issues/540[tiny suggestion] In Kalman Filter, nullify `corrected` after `predict()`2019-04-26T18:33:51ZHao Peng[tiny suggestion] In Kalman Filter, nullify `corrected` after `predict()`This is actually a suggestion to `org.hipparchus.filtering.kalman.AbstractKalmanFilter`.
After line 59, simply add `corrected = null;`.
Usually after doing a prediction, the old correction becomes useless.
It can help prevent using...This is actually a suggestion to `org.hipparchus.filtering.kalman.AbstractKalmanFilter`.
After line 59, simply add `corrected = null;`.
Usually after doing a prediction, the old correction becomes useless.
It can help prevent using wrong data when one forgets to `correct()` after `predict()`. It seems not affect all other functions.https://gitlab.orekit.org/orekit/orekit/-/issues/541README enhancement2019-07-05T17:42:35ZSébastien Dinotsebastien.dinot@csgroup.euREADME enhancementIn my humble opinion, the [README file](https://gitlab.orekit.org/orekit/orekit/blob/master/README.txt) provided with Orekit source code is totally old-fashioned:
* It uses the plain text format rather than a lightweight markup language...In my humble opinion, the [README file](https://gitlab.orekit.org/orekit/orekit/blob/master/README.txt) provided with Orekit source code is totally old-fashioned:
* It uses the plain text format rather than a lightweight markup language such as [Markdown](https://daringfireball.net/projects/markdown/) or [reStructuredText](http://docutils.sourceforge.net/rst.html).
* It is poor in information (no indication is provided, for example, on how to contribute, or how to report a bug).
Several initiatives have attempted to list good practices regarding the content of a README file and/or to provide README templates:
* [Readme Best Practices](https://github.com/jehna/readme-best-practices)
* [Art of README](https://github.com/noffle/art-of-readme)
I think that Orekit merits such modern README file.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/542Duplicated building instructions2020-02-20T12:32:32ZSébastien Dinotsebastien.dinot@csgroup.euDuplicated building instructionsBuilding instructions are provided in two files:
* [BUILDING.txt](BUILDING.txt)
* [building.md](src/site/markdown/building.md)
Instructions are more detailed in `building.md` file, but instructions for building Orekit through Ant are o...Building instructions are provided in two files:
* [BUILDING.txt](BUILDING.txt)
* [building.md](src/site/markdown/building.md)
Instructions are more detailed in `building.md` file, but instructions for building Orekit through Ant are only provided in the `BUILDING.txt` file. Since the `README.md` file proposed in merge request !3 directs users to the `building.md` file, the missing instructions should be added to it and the `BUILDING.txt` file deleted.10.2Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/543Hang via crafted itrf-versions.conf2019-07-05T17:41:52ZEvan WardHang via crafted itrf-versions.confI was playing around with the new itrf-versions.conf and noticed that any regular expression (RE) is accepted. If the file is loaded from an un-trusted source this can hang the application because Java's REs can take exponential time to ...I was playing around with the new itrf-versions.conf and noticed that any regular expression (RE) is accepted. If the file is loaded from an un-trusted source this can hang the application because Java's REs can take exponential time to halt.[1] One one hand supplemental data should only be loaded from trusted sources to ensure the accuracy of computations. On the other hand one could argue that the effects of loading un-trusted data shouldn't be any worse than inaccurate results. So I'm not decided if it is a security issue or not. The thing that makes me nervous is that Orekit can load these files from the internet. What do you think? @luc
For example, I have a `itrf-versions.conf` file that contains:
```
f(.+)+.{40} ------ ------ ITRF-2005
```
And a EOP file named `finals2000A.0reallyloooooooooooooooooooonName`. With these settings Orekit has been hung since yesterday. It seems the file name needs to be longer than about 20 characters to cause issues.
Possible Solutions:
1. Document it and warn the user so they can take appropriate steps to only load trusted data.
2. Use a different RE implementation than Java's Matcher. It is possible to match the above RE in roughly linear time, but Java's implementation of RE is extended to include non-regular expressions such as back references which necessitates the slower algorithm.
3. Implement a watchdog, though I'm not sure if RE matching is interruptible.
4. others?
[1] https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS10.0Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/orekit/-/issues/544Infinite loop on GPSPropagator and (Field)KeplerianOrbit2019-07-05T17:42:35ZBryan CazabonneInfinite loop on GPSPropagator and (Field)KeplerianOrbitA pull request has been open on the Orekit GitHub repository ([here](https://github.com/CS-SI/Orekit/pull/21#issuecomment-489652905)). It is related to an endless loop when `x.getValue()` or `x0.getValue()` is Double.NaN on GPSPropagator...A pull request has been open on the Orekit GitHub repository ([here](https://github.com/CS-SI/Orekit/pull/21#issuecomment-489652905)). It is related to an endless loop when `x.getValue()` or `x0.getValue()` is Double.NaN on GPSPropagator class. This endless loop can also occur on KeplerianOrbit and FieldKeplerianOrbit classes.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/545.mailmap file is out of date2019-07-05T17:42:36ZSébastien Dinotsebastien.dinot@csgroup.eu.mailmap file is out of dateThe [.mailmap](https://gitlab.orekit.org/orekit/orekit/blob/develop/.mailmap) file is quite out of date. As it stands, Orekit seems to have been developed by 49 different people, but in reality, the project has only 33 contributors.
The...The [.mailmap](https://gitlab.orekit.org/orekit/orekit/blob/develop/.mailmap) file is quite out of date. As it stands, Orekit seems to have been developed by 49 different people, but in reality, the project has only 33 contributors.
The merge request !4 is proposed to fix this issue.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/546Update pom.xml to Hipparchus 1.52019-07-05T17:41:51ZMaxime JournotUpdate pom.xml to Hipparchus 1.5Hipparchus 1.5 was released a week ago.
We can now update the pom.xml of Orekit.Hipparchus 1.5 was released a week ago.
We can now update the pom.xml of Orekit.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/548Organization of the models package2019-07-05T17:41:51ZBryan CazabonneOrganization of the models packageA discussion has been open in the [forum](https://forum.orekit.org/t/package-organization-in-orekit/472) for this enhancement. The goal is to have a clean organization by adding sub-packages for ionospheric, tropospheric and global weath...A discussion has been open in the [forum](https://forum.orekit.org/t/package-organization-in-orekit/472) for this enhancement. The goal is to have a clean organization by adding sub-packages for ionospheric, tropospheric and global weather models.10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/549Eclipse Detector: Re-add the getters and delete deprecated constructors ?2019-07-05T17:41:50ZMaxime JournotEclipse Detector: Re-add the getters and delete deprecated constructors ?In [EclipseDetector](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/propagation/events/EclipseDetector.java) class, recent changes (see [#535](https://gitlab.orekit.org/orekit/orekit/issues/535)) have:
1. ...In [EclipseDetector](https://gitlab.orekit.org/orekit/orekit/blob/develop/src/main/java/org/orekit/propagation/events/EclipseDetector.java) class, recent changes (see [#535](https://gitlab.orekit.org/orekit/orekit/issues/535)) have:
1. Removed the getters for the occulted and occulting body;
1. Lead to the deprecation of constructor based on a spherical occulting body.
For version 10.0 shall we ?
1. Write back some getters. They can be useful when multiple EclipseDetectors are used and we want to discriminate between them.
Example: Set up 2 EclipseDetectors for Sun occultation, one with the Earth and the other one with the Moon as the occulting body.
Use an event logger to log the events.
After propagation, how can we distinguish between Earth eclipses and Moon eclipses if we don't have access to the occulting body name ?
Maybe there is another way to do it but I don't know how...
1. Delete the deprecated constructors and the inner class `SphericalOccultingBody`.
Though it seems ok to me to keep the older constructors for users that just want to use "simple" spherical-based occultation.
On the other hand we could simply document how to use a spherical body, as @luc explains it in issue #535.
What do you think ?10.0https://gitlab.orekit.org/orekit/orekit/-/issues/550Download url of the latest Orekit archives not provided in technical document...2019-07-05T17:42:37ZSébastien Dinotsebastien.dinot@csgroup.euDownload url of the latest Orekit archives not provided in technical documentationDownload url of the latest Orekit archives not provided in the technical documentation generated by Maven:
<https://www.orekit.org/site-orekit-9.3.1/downloads.html>
---
| package | link ...Download url of the latest Orekit archives not provided in the technical documentation generated by Maven:
<https://www.orekit.org/site-orekit-9.3.1/downloads.html>
---
| package | link |
|----------|---------------------------------------------------------------------|
| source | orekit-9.3.1-sources.zip (URL to be defined after official release) |
| binary | orekit-9.3.1.jar (URL to be defined after official release) |
version 9.3.1 downloads (release date: 2019-03-16)
---10.0https://gitlab.orekit.org/orekit/orekit/-/issues/551AttitudeSequence transition not computed with analytical propagators2019-07-05T17:42:37ZRomaric HERAttitudeSequence transition not computed with analytical propagatorsIn the case of an attitude transition is triggered by an event detector during an analytical propagation, the attitude of the satellite is not correctly computed if the beginning of the propagation is before the transition and the end of...In the case of an attitude transition is triggered by an event detector during an analytical propagation, the attitude of the satellite is not correctly computed if the beginning of the propagation is before the transition and the end of the propagation is after the transition.
The origin of the bug is : the final SpacecraftState is computed before the event triggering, but the attitude transition is computed only after the events triggering. So the returned SpacecraftState is computed with the initial attitude law, not the updated one after the transition.10.0Romaric HERRomaric HERhttps://gitlab.orekit.org/orekit/orekit/-/issues/552AttitudeSequence bug when the propagation ends and restart during the transit...2019-07-05T17:42:37ZRomaric HERAttitudeSequence bug when the propagation ends and restart during the transition periodIn case of multiple uses of the propagate method with an attitude sequence, if one use of propagate method ends in the transition period an another one starts during the transition period, the attitude after the transition is not correct...In case of multiple uses of the propagate method with an attitude sequence, if one use of propagate method ends in the transition period an another one starts during the transition period, the attitude after the transition is not correct.
This is due to the fact that each use of the propagate method reset the events detector, that reset the TimeSpanMap used in the AttitudeSequence object. The reset will cause that the map that is supposed to describe the "after" attitude law is deleted by the reset, since the current date is still in the transition period. But the transition event is already in the past so the "after" attitude law will not be computed again. The attitude law is stuck in the transition phase and returns wrong values.10.0Romaric HERRomaric HERhttps://gitlab.orekit.org/orekit/orekit/-/issues/553AttitudeSequence bug with Ephemeris propagator2019-07-05T17:42:36ZRomaric HERAttitudeSequence bug with Ephemeris propagatorIn case of an attitude transition during an propagation with Ephemeris, a "OUT_OF_RANGE_SIMPLE" exception will be thrown.
This is due to a check in the getPVCoordinates method of Ephemeris, that will check that the current date is the s...In case of an attitude transition during an propagation with Ephemeris, a "OUT_OF_RANGE_SIMPLE" exception will be thrown.
This is due to a check in the getPVCoordinates method of Ephemeris, that will check that the current date is the same as the computed state date. In case of an attitude transition, if we try to compute the attitude during the transition period, the propagator needs the attitude at the end of this period, so this check will fail.10.0Romaric HERRomaric HERhttps://gitlab.orekit.org/orekit/orekit/-/issues/554Merge branch "propagation-in-inertial-frame" into "develop"2019-07-05T17:41:51ZMaxime JournotMerge branch "propagation-in-inertial-frame" into "develop"The `propagation-in-inertial-frame` branch has been living its life on its own since 4 years now.
As we're on the verge of releasing a major version, it is time to merge it on the `develop` branch.The `propagation-in-inertial-frame` branch has been living its life on its own since 4 years now.
As we're on the verge of releasing a major version, it is time to merge it on the `develop` branch.10.0https://gitlab.orekit.org/orekit/orekit/-/issues/555Change ionospheric models API2021-03-10T10:40:53ZBryan CazabonneChange ionospheric models APICurrent API used for the computation of the path delay due to ionospheric effects limits the implementation of new ionospheric models. Current API can be improved by:
* Add `SpacecraftState` information and the possibility to estimate s...Current API used for the computation of the path delay due to ionospheric effects limits the implementation of new ionospheric models. Current API can be improved by:
* Add `SpacecraftState` information and the possibility to estimate some ionospheric model parameters.
* Add the frequency parameter to limit the number of model initialization.
* Replace `GeodeticPoint`, elevation and azimuth parameters with `TopocentricFrame` parameter.
Old method parameters: `pathDelay(AbsoluteDate date, GeodeticPoint geo, double elevation, double azimuth)`
New method parameters: `pathDelay(SpacecraftState state, TopocentricFrame baseFrame, double frequency, double[] parameters)`11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/556Coverage results not taken into account in the CI build status2019-07-05T17:42:38ZSébastien Dinotsebastien.dinot@csgroup.euCoverage results not taken into account in the CI build statusThe CI build status of [Build #127](https://ci.orekit.org/job/orekit/job/develop/127/) displayed by Jenkins is "Success" (blue bullet) despite that the coverage ratios are under the required values:
* Class: 99 % instead of 100 %
* Meth...The CI build status of [Build #127](https://ci.orekit.org/job/orekit/job/develop/127/) displayed by Jenkins is "Success" (blue bullet) despite that the coverage ratios are under the required values:
* Class: 99 % instead of 100 %
* Method: 93 % instead of 95 %
The CI tool should warn developers against such deviation and display a different result (yellow or red bullet depending on the coverage ratios are under "maximum<Counter>Coverage" or "minimun<Counter>Coverage").10.0https://gitlab.orekit.org/orekit/orekit/-/issues/558Broken links on Maven site2019-07-05T17:41:51ZSébastien Dinotsebastien.dinot@csgroup.euBroken links on Maven siteHere are two broken links in the documentation site generated by Maven:
* [licence.html](https://www.orekit.org/site-orekit-development/license.html)
* [team-list.html](https://www.orekit.org/site-orekit-development/team-list.html)
Lin...Here are two broken links in the documentation site generated by Maven:
* [licence.html](https://www.orekit.org/site-orekit-development/license.html)
* [team-list.html](https://www.orekit.org/site-orekit-development/team-list.html)
Links to the first page are available in the source files below:
* [src/site/site.xml](https://gitlab.orekit.org/orekit/orekit/blob/master/src/site/site.xml#L34)
* [src/site/markdown/index.md](https://gitlab.orekit.org/orekit/orekit/blob/master/src/site/markdown/index.md)
No link to the second link found in source files, but there are 675 occurrence of this link in the generated page [target/site/changes-report.html](https://www.orekit.org/site-orekit-development/changes-report.html).10.0https://gitlab.orekit.org/orekit/orekit/-/issues/559Marshall Solar Activity Future Estimation URL and name patterns have changed2019-06-12T13:31:23ZLuc MaisonobeMarshall Solar Activity Future Estimation URL and name patterns have changedThe NASA web site for providing MSAFE file have changed, there are three main consequence:
- the URL given in the configuration page is obsolete, it is now https://www.nasa.gov/msfcsolar/archivedforecast
- the old file names pattern...The NASA web site for providing MSAFE file have changed, there are three main consequence:
- the URL given in the configuration page is obsolete, it is now https://www.nasa.gov/msfcsolar/archivedforecast
- the old file names patterns have been changed to full lower case (Mar1999F10.txt was renamed mar1999f10.txt')
- the newer file names have a '_prd' part after the 'f10' (for example may2019f10_prd.txt)
The first change is just documentation, but the last two changes imply changing calling code (the supportedNames regexp)10.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/560New lines property in checkstyle.xml configuration file2020-02-04T15:45:29ZMaxime JournotNew lines property in checkstyle.xml configuration fileIn `checkstyle.xml`, I'd like to replace one of the last line:
<module name="NewlineAtEndOfFile">
With:
<module name="NewlineAtEndOfFile">
<property name="lineSeparator" value="lf"/>
</module>
The reason is that I...In `checkstyle.xml`, I'd like to replace one of the last line:
<module name="NewlineAtEndOfFile">
With:
<module name="NewlineAtEndOfFile">
<property name="lineSeparator" value="lf"/>
</module>
The reason is that I am using Windows operating system (I know...).
I configured my editor to use unix-style end of lines ("lf"), so that when I'm pushing code I'm not messing around the whole git.
However, my operating system being what it is, checkstyle wants to see "CR/LF" ends of line at the end of every java files. So it raises an error for all the files in `src/main/java`.
I've been using the property above for a while now. It works well and I think it could benefit to other developers that are also using Windows OS (if there is any...).
Do you think it's a good idea ?
I'm not sure whether it can have some side effects on Linux OS or on someone's repository who would have an IDE configured differently.10.1https://gitlab.orekit.org/orekit/orekit/-/issues/561Creating TLES with epoch during leap second fails2020-05-13T18:12:01ZEvan WardCreating TLES with epoch during leap second failsBacktrace:
```
org.orekit.errors.OrekitInternalError: internal error, please notify development team by creating an issue at https://gitlab.orekit.org/orekit/orekit/issues
at org.orekit.propagation.analytical.tle.TLE.toString(TLE.jav...Backtrace:
```
org.orekit.errors.OrekitInternalError: internal error, please notify development team by creating an issue at https://gitlab.orekit.org/orekit/orekit/issues
at org.orekit.propagation.analytical.tle.TLE.toString(TLE.java:617)
...
Caused by: org.orekit.errors.OrekitException: invalid TLE parameter for object 34,602: fraction = 100000579
at org.orekit.propagation.analytical.tle.TLE.addPadding(TLE.java:431)
at org.orekit.propagation.analytical.tle.TLE.addPadding(TLE.java:414)
at org.orekit.propagation.analytical.tle.TLE.buildLine1(TLE.java:310)
at org.orekit.propagation.analytical.tle.TLE.getLine1(TLE.java:271)
at org.orekit.propagation.analytical.tle.TLE.toString(TLE.java:615)
... 26 more
```
Not sure if on days with leap seconds the divisor is supposed to be 86400 or 86401. I'll see how some other tools handle it.https://gitlab.orekit.org/orekit/orekit/-/issues/563In ephemeris, additional states managed by AdditionalStateProvider should be ...2019-06-21T08:08:38ZMikael FillastreIn ephemeris, additional states managed by AdditionalStateProvider should be savedIn reference to discussion https://forum.orekit.org/t/additionnal-states-in-ephemerides-not-reinitilialized-and-or-updated/502/3
Code to reproduce the problem :
```java
package space.exotrail.exoops.numerical.orekit;
import java.io.IOE...In reference to discussion https://forum.orekit.org/t/additionnal-states-in-ephemerides-not-reinitilialized-and-or-updated/502/3
Code to reproduce the problem :
```java
package space.exotrail.exoops.numerical.orekit;
import java.io.IOException;
import org.hipparchus.ode.AbstractIntegrator;
import org.hipparchus.ode.nonstiff.ClassicalRungeKuttaIntegrator;
import org.hipparchus.util.FastMath;
import org.junit.Assert;
import org.junit.Test;
import org.orekit.errors.OrekitException;
import org.orekit.frames.Frame;
import org.orekit.frames.FramesFactory;
import org.orekit.orbits.KeplerianOrbit;
import org.orekit.orbits.Orbit;
import org.orekit.orbits.PositionAngle;
import org.orekit.propagation.AdditionalStateProvider;
import org.orekit.propagation.BoundedPropagator;
import org.orekit.propagation.SpacecraftState;
import org.orekit.propagation.events.DateDetector;
import org.orekit.propagation.events.EventDetector;
import org.orekit.propagation.events.handlers.EventHandler;
import org.orekit.propagation.numerical.NumericalPropagator;
import org.orekit.time.AbsoluteDate;
import org.orekit.time.TimeScale;
import org.orekit.time.TimeScalesFactory;
public class AdditionalStatesTest {
public static final String STATE_NAME = "STATE";
public static final int STATE_INDEX = 0;
public static final int STATE_START = 10;
public static final int STATE_END = -10;
public class Handler implements EventHandler<EventDetector> {
private StateProviderTest additionalStateProvider;
public Handler (StateProviderTest additionalStateProvider) {
this.additionalStateProvider = additionalStateProvider;
}
@Override
public void init(final SpacecraftState s0, final AbsoluteDate t) {
additionalStateProvider.setFirstPart(true);
}
@Override
public Action eventOccurred(SpacecraftState s, EventDetector detector, boolean increasing)
throws OrekitException {
additionalStateProvider.setFirstPart(false);
return Action.CONTINUE;
}
}
public class StateProviderTest implements AdditionalStateProvider {
public boolean firstPart = true;
@Override
public String getName() {
return STATE_NAME;
}
@Override
public double[] getAdditionalState(SpacecraftState state) throws OrekitException {
if (isFirstPart()) {
double[] ret = { STATE_START };
return ret;
} else {
double[] ret = { STATE_END };
return ret;
}
}
public boolean isFirstPart() {
return firstPart;
}
public void setFirstPart(boolean firstPart) {
this.firstPart = firstPart;
}
}
@Test
public void TestAdditionalStates() throws OrekitException, IOException {
// Initial orbit parameters
double a = 24396159; // semi major axis in meters
double e = 0.72831215; // eccentricity
double i = FastMath.toRadians(7); // inclination
double omega = FastMath.toRadians(180); // perigee argument
double raan = FastMath.toRadians(261); // right ascension of ascending node
double lM = 0; // mean anomaly
// Inertial frame
Frame inertialFrame = FramesFactory.getEME2000();
// Initial date in UTC time scale
TimeScale utc = TimeScalesFactory.getUTC();
AbsoluteDate initialDate = new AbsoluteDate(2004, 01, 01, 23, 30, 00.000, utc);
// gravitation coefficient
double mu = 3.986004415e+14;
// Orbit construction as Keplerian
Orbit initialOrbit = new KeplerianOrbit(a, e, i, omega, raan, lM, PositionAngle.MEAN,
inertialFrame, initialDate, mu);
// Initialize state
SpacecraftState initialState = new SpacecraftState(initialOrbit);
// Numerical propagation with no perturbation (only Keplerian movement)
// Using a very simple integrator with a fixed step: classical Runge-Kutta
double stepSize = 10; // the step is ten seconds
AbstractIntegrator integrator = new ClassicalRungeKuttaIntegrator(stepSize);
NumericalPropagator propagator = new NumericalPropagator(integrator);
// Set the propagator to ephemeris mode
propagator.setEphemerisMode();
StateProviderTest stateProvider = new StateProviderTest();
propagator.addEventDetector(new DateDetector(initialDate.shiftedBy(3000))
.withHandler(new Handler(stateProvider)));
propagator.addAdditionalStateProvider(stateProvider);
propagator.setInitialState(initialState);
// Propagation with storage of the results in an integrated ephemeris
SpacecraftState firstPartState = propagator.propagate(initialDate.shiftedBy(2000));
propagator.resetInitialState(initialState);
SpacecraftState finalState = propagator.propagate(initialDate.shiftedBy(6000));
BoundedPropagator ephemeris = propagator.getGeneratedEphemeris();
double stateAfterPropagation = finalState.getAdditionalState(STATE_NAME)[STATE_INDEX];
double stateInFirstPartOfPropagation = firstPartState
.getAdditionalState(STATE_NAME)[STATE_INDEX];
double stateInFirstPartOfEphemerides = ephemeris.propagate(initialDate.shiftedBy(1000))
.getAdditionalState(STATE_NAME)[STATE_INDEX];
double stateInSecondPartOfEphemerides = ephemeris.propagate(initialDate.shiftedBy(4000))
.getAdditionalState(STATE_NAME)[STATE_INDEX];
Assert.assertEquals(STATE_START, stateInFirstPartOfPropagation, 1e-12);
Assert.assertEquals(STATE_END, stateAfterPropagation, 1e-12);
Assert.assertEquals(STATE_START, stateInFirstPartOfEphemerides, 1e-12);
Assert.assertEquals(STATE_END, stateInSecondPartOfEphemerides, 1e-12);
}
}
```
Analysis from Luc :
> They should be stored, so I think you found a bug here.
>
>I looked at the internal class AbstractIntegratedPropagator.EphemerisModeHandler which handles >ephemeris generation, at the end of the handleStep method, in the part performed only for the >last step, just before the propagation stops. In this part, there are two separate handlings >of additional states:
>
> states managed by additional equations (i.e. differential equations), they will be >retrieved from
> the underlying integrator additional states
> states labelled as “unmanaged”, only their initial values as present in the initial state >will be retrieved
>
>It now seems to me that we missed a third category: states manged by an analytical >AdditionalStateProvider, which is your case. I think we considered that as we can’t dump an >unknown additional state provider, we cannot store it in an ephemeris. If ephemerides were >used only on the exact sample points, this would not be a problem, we could simply dump the >value. However, ephemerides can be interpolated, and how do we interpolate states for which we >don’t have any equation?
>
>There may be two different answers to this:
>
> if the ephemeris is indeed used whay we are still in the same process, and the >AdditionalStateProvider
> instances are still available: then we could store a reference to them in the ephemeris >and call it so it
> computes the additional state just as it would do in the original propagation
> if the ephemeris was dumped on file and reloaded, then we could use a n points >interpolation (n to
> be defined at loading time) from the sampled states.https://gitlab.orekit.org/orekit/orekit/-/issues/564Visibility of AbstractGaussianContributionContext2019-06-25T19:49:29ZPetrus HyvönenVisibility of AbstractGaussianContributionContextHi,
In the AbstractGaussianContribution (and field version) there is a protected abstract getLLimits(SpacecraftState state, AbstractGaussianContributionContext context), where it seems like the AbstractGaussianContributionContext is not...Hi,
In the AbstractGaussianContribution (and field version) there is a protected abstract getLLimits(SpacecraftState state, AbstractGaussianContributionContext context), where it seems like the AbstractGaussianContributionContext is not specified as I understand it defaults to private, and thus cannot be accessed? Maybe this abstract class is not for general usage outside DSST, but then we should mark it as such?10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/565Static loading of GLONASS in LazyLeapHolder2019-06-25T19:49:51ZPetrus HyvönenStatic loading of GLONASS in LazyLeapHolderThe LazyLeapHolder has a static loading of UTC in the getGLONASS() mehtod of TimeScalesFactory.
```
private static class LazyLeapHolder {
/**
* Reference epoch for GLONASS four-year interval number: 1996-01-01T00:00:0...The LazyLeapHolder has a static loading of UTC in the getGLONASS() mehtod of TimeScalesFactory.
```
private static class LazyLeapHolder {
/**
* Reference epoch for GLONASS four-year interval number: 1996-01-01T00:00:00
* GLONASS time.
*/
public static final AbsoluteDate GLONASS_EPOCH = new AbsoluteDate(
DateComponents.GLONASS_EPOCH,
TimeComponents.H00,
TimeScalesFactory.getGLONASS());
}
```10.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/566ITRFVersionLoader is private2019-07-05T17:41:51ZEvan WardITRFVersionLoader is privateIn 10.0-RC1 the class `ITRFVersionLoader` is private which prevents users from adding their own EOP loaders for EOP formats not supported by Orekit. I will make this class public so that users can add EOP loaders for custom formats.In 10.0-RC1 the class `ITRFVersionLoader` is private which prevents users from adding their own EOP loaders for EOP formats not supported by Orekit. I will make this class public so that users can add EOP loaders for custom formats.10.0Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/orekit/-/issues/567Strange midnight turn for GPS block IIA2019-07-09T15:47:59ZLuc MaisonobeStrange midnight turn for GPS block IIAA strange behavior has been observed in a specific case of midnight turn in yaw for GPS block IIA.
The test case was built in a similar way as the original tests cases, using `FindBaseSamples` and `GenerateBaseSamples` from the referen...A strange behavior has been observed in a specific case of midnight turn in yaw for GPS block IIA.
The test case was built in a similar way as the original tests cases, using `FindBaseSamples` and `GenerateBaseSamples` from the reference attitude generator utilities folder. It was however set at a much earlier data than the existing tests and was found on GPS week 1218 (May 2003), for satellite G07 (satCode G37, a Block-IIA satellite), using SP3 file `ngs12183.sp3.Z`. On May 14th, between 07:58 and 09:28, a midnight turn occurs and the Sun crosses the orbital plane (β increasing from negative to positive values). This case should already be handled by Orekit since version 9.3, and there are already test cases for it, but only in the noon turn case as no midnight turn with simultaneous Sun crossing was found until now.
The current output is that the spacecraft starts its linear turn at about 0.1272°/s and the Sun changes side. Then, the satellite keeps turning for about 70 minutes, completing one turn and an half instead of only one half of a turn. One turn and an half seems unrealistic and the reference eclips, even the patched version, does not do that.10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/568Bracketing error in GNSS attitude models2019-07-09T15:50:45ZLuc MaisonobeBracketing error in GNSS attitude modelsIn addition to the unrealistic turn depicted in issue #567, another unrelated error has been identified.
When attempting to add the strange turn it in the existing test framework by adding the relevant lines to `beta-crossing-BLOCK-IIA....In addition to the unrealistic turn depicted in issue #567, another unrelated error has been identified.
When attempting to add the strange turn it in the existing test framework by adding the relevant lines to `beta-crossing-BLOCK-IIA.txt` data file, an exception was triggered.
The problem occurs during the attempt to locate the time at which the linear model reaches target yaw. The bracketing attempt uses steps that increase too fast (their size is doubled at each iteration), hence missing a pair of zero crossings.10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/569Parse Rinex 3 files with blank SYS / PHASE SHIFT header lines2019-07-17T15:14:41ZLuc MaisonobeParse Rinex 3 files with blank SYS / PHASE SHIFT header linesRinex 3 files with blank header lines for SYS / PHASE SHIFT and fail to parse.
One such example is [GANP00SVK_R_20151890000_01D_30S_MO.crx.gz](ftp://igs.bkg.bund.de/IGS/obs/2015/189/GANP00SVK_R_20151890000_01D_30S_MO.crx.gz) where the S...Rinex 3 files with blank header lines for SYS / PHASE SHIFT and fail to parse.
One such example is [GANP00SVK_R_20151890000_01D_30S_MO.crx.gz](ftp://igs.bkg.bund.de/IGS/obs/2015/189/GANP00SVK_R_20151890000_01D_30S_MO.crx.gz) where the SYS / PHASE SHIFT line for SBAS at line 31
(line 29 when Hatanaka compression has been removed) reads:
```
S SYS / PHASE SHIFT
```
whereas a non-blank line for Galileo reads:
```
E L5X 0.00000 SYS / PHASE SHIFT
```
The faulty line display neither an observation type nor a phase shift value. This seems to be an application of one sentence in section 9.1 in Rinex 3.03 specification.
> The uncorrected reference signal group of observations are left blank
> in the SYS / PHASE SHIFT records.10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/570getFootprint method of FieldOfView should be public2019-08-13T09:47:47ZPetrus HyvönengetFootprint method of FieldOfView should be publicThe getFootprint method of propagation.events.FieldOfView should be public, currently not set scope so defaults to private (?).The getFootprint method of propagation.events.FieldOfView should be public, currently not set scope so defaults to private (?).10.1Petrus HyvönenPetrus Hyvönenhttps://gitlab.orekit.org/orekit/orekit/-/issues/571Loading of RINEX 2 files with more than 12 satellites fails2019-07-11T14:41:58ZLuc MaisonobeLoading of RINEX 2 files with more than 12 satellites failsWhen attempting to read the RINEX 2 file [bogi1210.09d.Z](ftp://igs.bkg.bund.de/IGS/obs/2009/121/bogi1210.09d.Z),
even after having uncompressed it prior to loading, a `NumberFormatException` is thrown.
It seems the parser is lost as th...When attempting to read the RINEX 2 file [bogi1210.09d.Z](ftp://igs.bkg.bund.de/IGS/obs/2009/121/bogi1210.09d.Z),
even after having uncompressed it prior to loading, a `NumberFormatException` is thrown.
It seems the parser is lost as the file contains more than 12 satellites for each epoch,
which implies using continuation lines.10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/572Saastamoinen model is not defined for altitudes bigger than 5000 meters2019-07-25T10:53:29ZBryan CazabonneSaastamoinen model is not defined for altitudes bigger than 5000 metersDuring the computation of the path delay, if the station altitude is bigger than 5000.0 meters an exception occurs. Indeed, there are no data in the model for altitudes bigger than 5000.0 meters.During the computation of the path delay, if the station altitude is bigger than 5000.0 meters an exception occurs. Indeed, there are no data in the model for altitudes bigger than 5000.0 meters.10.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/573NullPointerException on corrupted Unix-compressed file2019-07-17T08:43:21ZLuc MaisonobeNullPointerException on corrupted Unix-compressed fileSome corrupted Unix-compressed files generate a `NullPointerException` upon reading.
One such file is the six bytes file starting with: 0x1f, 0x9d, 0x90, 0x31, 0x5c, 0xff.Some corrupted Unix-compressed files generate a `NullPointerException` upon reading.
One such file is the six bytes file starting with: 0x1f, 0x9d, 0x90, 0x31, 0x5c, 0xff.10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/574Attempt to read past end of Unix-compressed file generates exception2019-07-17T09:26:39ZLuc MaisonobeAttempt to read past end of Unix-compressed file generates exceptionWhen uncompressing a Unix-compressed .Z file, if the caller insist on attempting
to read bytes despite end of file has been encountered, an exception is generated.
This does happen when the uncompressed output is read using a `BufferedRe...When uncompressing a Unix-compressed .Z file, if the caller insist on attempting
to read bytes despite end of file has been encountered, an exception is generated.
This does happen when the uncompressed output is read using a `BufferedReader` to
directly get lines from text files.
The uncompressing filter should keep returning -1 to indicate end of file if
caller repeatedly.10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/575The user can set a ConvergenceChecker in BatchLSEstimator2019-10-09T15:00:18ZQuentin RhoneThe user can set a ConvergenceChecker in BatchLSEstimatorCurrently, user can only call setParametersConvergenceThreshold and the ConvergenceChecker will be built from that. We could add a setConvergenceChecker method and would build the default checker only if no checker has been set up by use...Currently, user can only call setParametersConvergenceThreshold and the ConvergenceChecker will be built from that. We could add a setConvergenceChecker method and would build the default checker only if no checker has been set up by user. We should decide what to do if users call both method. It could be considered an error or they each new call would invalidate settings from previous calls to the other method. This should be documented, though.10.1https://gitlab.orekit.org/orekit/orekit/-/issues/576Add weak-time-dependent (WTD) terms in the DSST lunar solar short period motion.2022-01-19T15:34:59ZBryan CazabonneAdd weak-time-dependent (WTD) terms in the DSST lunar solar short period motion.For a better accuracy in orbit propagation and orbit determination it is necessary to add the weak-time-dependent (WTD) terms in the Orekit DSST lunar solar short period motion. For GNSS or GEO orbits adding these terms can improve signi...For a better accuracy in orbit propagation and orbit determination it is necessary to add the weak-time-dependent (WTD) terms in the Orekit DSST lunar solar short period motion. For GNSS or GEO orbits adding these terms can improve significantly the results.https://gitlab.orekit.org/orekit/orekit/-/issues/577rename IRNSS into NAVIC2021-03-02T14:02:20ZLuc Maisonoberename IRNSS into NAVICThe Indian Regional Navigation Satellite System was renamed [NAVIC](https://gssc.esa.int/navipedia/index.php/NAVIC) (NAVigation with Indian Constellation) in 2016.
The enumerates for `Satellitesystem` should be updated and `IRNSSScale` ...The Indian Regional Navigation Satellite System was renamed [NAVIC](https://gssc.esa.int/navipedia/index.php/NAVIC) (NAVigation with Indian Constellation) in 2016.
The enumerates for `Satellitesystem` should be updated and `IRNSSScale` time scale should be renamed.
Such renaming are incompatible change, so they have to wait for next major version: 11.0.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/578Orbit determination tutorial does not use filtering for measurement files2019-07-23T21:32:04ZDavid SoulardOrbit determination tutorial does not use filtering for measurement filesIf .XXd or .Z are used as measurements files, the OD tutorial does not recognize them as RINEX files.If .XXd or .Z are used as measurements files, the OD tutorial does not recognize them as RINEX files.10.1https://gitlab.orekit.org/orekit/orekit/-/issues/579Error when reading the COMPACT RINEX files2019-07-23T21:32:33ZDavid SoulardError when reading the COMPACT RINEX filesThe Hatanaka filter does not accept SPLICE within the RINEX file.
example of file with which this error occurs: ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/aber0440.16s.ZThe Hatanaka filter does not accept SPLICE within the RINEX file.
example of file with which this error occurs: ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/aber0440.16s.Z10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/580COMPACT RINEX: reading problem with some files2019-07-24T15:05:21ZDavid SoulardCOMPACT RINEX: reading problem with some filesWhen trying to read COMPACT RINEX file, exception sometimes occuring with some files:
- with: ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/abmf0440.16d.Z
"java.lang.NumberFormatException: For input string: ".-96"" occurs
- with: f...When trying to read COMPACT RINEX file, exception sometimes occuring with some files:
- with: ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/abmf0440.16d.Z
"java.lang.NumberFormatException: For input string: ".-96"" occurs
- with: ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/arev0440.16d.Z
"org.orekit.errors.OrekitIllegalArgumentException: mois inexistant" 0 occurs10.1https://gitlab.orekit.org/orekit/orekit/-/issues/581COMPACT RINEX: error when reading a month "0"2019-07-24T15:05:58ZDavid SoulardCOMPACT RINEX: error when reading a month "0"With the file : ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/arev0440.16d.Z the exception "org.orekit.errors.OrekitIllegalArgumentException: mois inexistant 0" occurs.With the file : ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/arev0440.16d.Z the exception "org.orekit.errors.OrekitIllegalArgumentException: mois inexistant 0" occurs.10.1https://gitlab.orekit.org/orekit/orekit/-/issues/582RinexHeader exception with RINEX 3 file2021-01-12T10:22:09ZDavid SoulardRinexHeader exception with RINEX 3 fileParser does not accept header with the RINEX 3 file : ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/MCHL00AUS_R_20160440000_01D_30S_MO.crx.gzParser does not accept header with the RINEX 3 file : ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/MCHL00AUS_R_20160440000_01D_30S_MO.crx.gzhttps://gitlab.orekit.org/orekit/orekit/-/issues/583FUTURE_INFINITY > FUTURE_INFINITY2019-09-18T13:14:09ZEvan WardFUTURE_INFINITY > FUTURE_INFINITY`AbsoluteDate.FUTURE_INFINITY.compareTo(AbsoluteDate.FUTURE_INFINITY)` currently returns `1`, but it should return `0` according to the contract of `Comparator.compareTo()`.
This would break strict backward compatibility, but currently ...`AbsoluteDate.FUTURE_INFINITY.compareTo(AbsoluteDate.FUTURE_INFINITY)` currently returns `1`, but it should return `0` according to the contract of `Comparator.compareTo()`.
This would break strict backward compatibility, but currently any `TreeMap` or `TreeSet` with `ChronologicalComparator` (of which Orekit has several) will not work correctly. I'll push a fix tomorrow unless I hear any objections.10.1Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/orekit/-/issues/584Long overflow in AbsoluteDate2020-05-13T18:10:14ZEvan WardLong overflow in AbsoluteDateIf the constructor `AbsoluteDate(AbsoluteDate, double)` is called with a large double value, or if the epoch of the first argument is already large then overflow can occur in `epoch = since.epoch + dl` if the sum is greater than `Long.M...If the constructor `AbsoluteDate(AbsoluteDate, double)` is called with a large double value, or if the epoch of the first argument is already large then overflow can occur in `epoch = since.epoch + dl` if the sum is greater than `Long.MAX_VALUE`. `FastMath.addExact()` could be used to throw an exception if overflow does occur. If overflow does occur the values should probably be set equal to past/future infinity. This can occur in the other constructor that sets `epoch` as well. A more conservative approach would be to return infinities if `offset` is not in the interval [0, 1).
Examples:
```
AbsoluteDate.J2000_EPOCH.shiftedBy(Long.MAX_VALUE).shiftedBy(Long.MAX_VALUE).toString()
// result is "2000-01-01T11:58:53.816" but it should be far in the future
AbsoluteDate.J2000_EPOCH.durationFrom(AbsoluteDate.J2000_EPOCH.shiftedBy(Long.MIN_VALUE))
// result is -9.223372036854776E18 but it should be positive
```
Not sure if this has an practical relevance.https://gitlab.orekit.org/orekit/orekit/-/issues/585Improve contributing guide2019-10-03T09:29:58ZBryan CazabonneImprove contributing guideCurrent version of the contributing guide just propose to the user to go on the forum and open a discussion about its contribution proposal.
Thanks to the GitLab features, it is possible to contribute to Orekit thanks to the merge reque...Current version of the contributing guide just propose to the user to go on the forum and open a discussion about its contribution proposal.
Thanks to the GitLab features, it is possible to contribute to Orekit thanks to the merge requests system. This possibility of contribution must be added to the contribution guide.10.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/586Set Propagator's default attitude provider to be aligned with Propagator.getF...2021-09-02T13:08:16ZEvan WardSet Propagator's default attitude provider to be aligned with Propagator.getFrame()For performance reasons when possible the default attitude provider should be aligned with the Propagator's Frame. This avoid computing frame transformations to/from EME2000 when the user isn't interested in the attitude. Some performanc...For performance reasons when possible the default attitude provider should be aligned with the Propagator's Frame. This avoid computing frame transformations to/from EME2000 when the user isn't interested in the attitude. Some performance profiling on my machine has shown that for the `TLEPropagator` computing the attitude is about as expensive as computing the position and velocity. In other words, there is a factor of two slow down if the default attitude law is not changed and the user doesn't need an EME2000 aligned attitude. I think most analytical propagators would benefit from changing the default attitude provider including `EphemerisSegmentPropagator` and `Ephemeris`. Since this changes semantics and may subtly break some applications I think we should wait until the next major release to make the change. I can add a `FrameAligned` `AttitudeProvider` now.
Workaround until this is fully implemented:
```java
TLEPropagator p = ...;
Frame teme = FramesFactory.getTEME()
// with new FrameAligned class
p.setAttitudeProvider(new FrameAligned(teme));
// with existing classes, but not as fast
p.setAttitudeProvider(new FixedRate(epoch, teme, AngularCoordinates.IDENTITY));
```11.0Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/orekit/-/issues/589AggregateBoundedPropagator double propagates2019-09-17T20:26:45ZEvan WardAggregateBoundedPropagator double propagatesCurrently `basicPropagate()` calls `propagateOrbit()` and `getMass()`, which both call `getPropagator().propagate()` doubling the number of propagations from what is necessary. Fix by overriding `basicPropagate()`.Currently `basicPropagate()` calls `propagateOrbit()` and `getMass()`, which both call `getPropagator().propagate()` doubling the number of propagations from what is necessary. Fix by overriding `basicPropagate()`.10.1https://gitlab.orekit.org/orekit/orekit/-/issues/590DateTimeComponents.toString() incorrect during leap second2021-09-02T13:48:22ZEvan WardDateTimeComponents.toString() incorrect during leap second```java
TimeScale utc = TimeScalesFactory.getUTC();
AbsoluteDate d = new AbsoluteDate("2017-01-01", utc).shiftedBy(-0.5);
DateTimeComponents dtc = d.getComponents(utc)
// the assert below fails, values are
// 2016-12-31T23:59:60.568 and ...```java
TimeScale utc = TimeScalesFactory.getUTC();
AbsoluteDate d = new AbsoluteDate("2017-01-01", utc).shiftedBy(-0.5);
DateTimeComponents dtc = d.getComponents(utc)
// the assert below fails, values are
// 2016-12-31T23:59:60.568 and 2017-01-01T00:00:00.000
Assert.assertEquals(d.toString(), dtc.toString());
// this passes, indicating the issue is in DateTimeComponents
Assert.assertEquals(d.toString(), dtc.getDate().toString() + "T" + dtc.getTime());
```11.0Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/orekit/-/issues/591TimeComponents.toString() round to invalid time2021-09-02T13:48:29ZEvan WardTimeComponents.toString() round to invalid timeThe expression `new TimeComponents(23, 59, 59.9999).toString()` produces the string "23:59:60.000" which contains a second number that is invalid most of the time. Tricky because rolling over would also be wrong and TimeComponents doesn'...The expression `new TimeComponents(23, 59, 59.9999).toString()` produces the string "23:59:60.000" which contains a second number that is invalid most of the time. Tricky because rolling over would also be wrong and TimeComponents doesn't know how many seconds are valid in this particular minute. Perhaps truncate seconds numbers in [59.999, 60) and [60.999, 61) to avoid producing invalid times.11.0Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/orekit/-/issues/592Loading files only from a predefined list2019-08-23T11:40:08ZLuc MaisonobeLoading files only from a predefined listFor files loading (tai-utc.dat, JPL ephemerides, EOP...), some applications require a more fine-grained control than available in the current `DataProvider` implementations. These applications require to pick-up specific files that may b...For files loading (tai-utc.dat, JPL ephemerides, EOP...), some applications require a more fine-grained control than available in the current `DataProvider` implementations. These applications require to pick-up specific files that may be located in directories containing other files that the applications would prefer to ignore. In this case, the traditional `DirectoryCrawler` would pick up all the files.
A new `FilesListCrawler` that only loads files from a predefined list configured at construction time (or built on the fly) would allow such applications to get the fine control they need.10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/593Missing some Earth equatorial radius and flattening for IERS in Constants class2019-10-02T15:55:00ZGuylaine PratMissing some Earth equatorial radius and flattening for IERS in Constants classThe IERS2003, IERS96 and IERS2010 Earth equatorial radius and flattening are not present in the Constants class whereas for instance WGS84, GRS80 or EGM96 are.
These conventions can be found here (in the technical notes):
https://www.ie...The IERS2003, IERS96 and IERS2010 Earth equatorial radius and flattening are not present in the Constants class whereas for instance WGS84, GRS80 or EGM96 are.
These conventions can be found here (in the technical notes):
https://www.iers.org/IERS/EN/DataProducts/Conventions/conventions.html
and
http://iers-conventions.obspm.fr/conventions_archive.php10.1https://gitlab.orekit.org/orekit/orekit/-/issues/594Too restrictive FieldOfView2019-12-12T21:24:11ZLuc MaisonobeToo restrictive FieldOfViewThe `FieldOfView` class that is used in `FieldOfViewDetector`, `GroundFieldOfViewDetector` and `FootprintOverlapDetector` only allows shapes defined using `SphericalPolygonsSet`. It is therefore impossible to use simple circular or ellip...The `FieldOfView` class that is used in `FieldOfViewDetector`, `GroundFieldOfViewDetector` and `FootprintOverlapDetector` only allows shapes defined using `SphericalPolygonsSet`. It is therefore impossible to use simple circular or elliptical FoV.
For circular FoV, a dedicated `CircularFieldOfViewDetector` exists, but there is nothing similar for ground field of view or footprint overlap.
It would be nice to have a general hierarchy of field of views with several ways to model the shape, with at least one using `SphericalPolygonsSet` and another one for simple circular cases.10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/595Add elliptical Field Of View2019-09-02T14:42:45ZLuc MaisonobeAdd elliptical Field Of ViewOnce feature #594 has been implemented, a new shape could be added: elliptical Field Of View, defined by a central line of sight, two orthogonal axes, and two separate half aperture angles.Once feature #594 has been implemented, a new shape could be added: elliptical Field Of View, defined by a central line of sight, two orthogonal axes, and two separate half aperture angles.10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/596Allow the user to set epsilon and maxIterations for DSST mean parameters conv...2019-10-04T07:04:16ZYannick JeandrozAllow the user to set epsilon and maxIterations for DSST mean parameters conversionHi everyone,
Recently, we have performed lots and lots of osculating->mean parameters conversions. And we have stumbled upon a few cases where the hardcoded values for the following parameters have proved troublesome :
- The "epsilon" ...Hi everyone,
Recently, we have performed lots and lots of osculating->mean parameters conversions. And we have stumbled upon a few cases where the hardcoded values for the following parameters have proved troublesome :
- The "epsilon" [here](https://gitlab.orekit.org/orekit/orekit/blob/master/src/main/java/org/orekit/propagation/semianalytical/dsst/DSSTPropagator.java#L600)
- And the max number of iterations [there](https://gitlab.orekit.org/orekit/orekit/blob/master/src/main/java/org/orekit/propagation/semianalytical/dsst/DSSTPropagator.java#L612)
Our tests have shown that the algorithm converges just fine if we increase those values a bit. Actually, increasing the epsilon is enough in our experience, but we believe it would be nice to have control over the maxIterations too, just in case.
I think it would be a good idea to allow the user to set those values, just to ensure that all cases can potentially be handled, even when convergence is slow.
In addition, it could be nice to increase the default values a bit, to ensure the algorithm converges in nearly all cases without fiddling with the values. Based on our (limited) experience, we would leave max iterations at 200, but multiply the epsilon by 100 (2 extra orders of magnitude).
If there is consensus on this issue, we can contribute the change. It should be quite simple : two extra "setters", and maybe a change on the default value for epsilon.Yannick JeandrozYannick Jeandrozhttps://gitlab.orekit.org/orekit/orekit/-/issues/598Duplicate mu (=GM) parameter driver in Kalman test2020-04-01T07:35:08ZDavid SoulardDuplicate mu (=GM) parameter driver in Kalman testIn Kalman test, propagator builder is built without Newtonian attraction. Hence, it goes in setMu(double) method, this parameter is then duplicate a number of times equals to the number of measurements. It leads to a very high computatio...In Kalman test, propagator builder is built without Newtonian attraction. Hence, it goes in setMu(double) method, this parameter is then duplicate a number of times equals to the number of measurements. It leads to a very high computation time.10.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/599NaN produced when dealing with flat ellipses2019-09-09T15:23:23ZLuc MaisonobeNaN produced when dealing with flat ellipsesWhen attempting to project a point on a 2D ellipse, the algorithm sometimes fails and produces NaN.
This seems to be happen on flat ellipses, where the ellipse evolute extends far outside the ellipse
itself along the minor axis. The init...When attempting to project a point on a 2D ellipse, the algorithm sometimes fails and produces NaN.
This seems to be happen on flat ellipses, where the ellipse evolute extends far outside the ellipse
itself along the minor axis. The initial point in the iterations generates a line that does not
intersect the ellipse at all.
The following test case reproduces the bug.
```java
@Test
public void testFlatEllipse() {
final double a = 0.839;
final double b = 0.176;
final Ellipse ellipse = new Ellipse(Vector3D.ZERO, Vector3D.PLUS_I, Vector3D.PLUS_J,
a, b, FramesFactory.getGCRF());
final Vector2D close = ellipse.projectToEllipse(new Vector2D(2.0, 4.0));
Assert.assertEquals(1.0,
close.getX() * close.getX() / (a * a) + close.getY() * close.getY() / (b * b),
1.0e-10);
}
```10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/600Reading RINEX 32019-09-10T12:36:27ZDavid SoulardReading RINEX 3Error when reading RINEX 3. When two many kind of measurement type appears for a system, a blank left where parser thinks finding a satellite system name (e.g: G, R, ...).
Example with file THTG00PYF_R_20160440000_01D_30S_MO.crx from IG...Error when reading RINEX 3. When two many kind of measurement type appears for a system, a blank left where parser thinks finding a satellite system name (e.g: G, R, ...).
Example with file THTG00PYF_R_20160440000_01D_30S_MO.crx from IGS website.10.1https://gitlab.orekit.org/orekit/orekit/-/issues/601getPVInPZ90 method of GLONASSNumericalPropagator should be private2021-01-13T17:59:04ZBryan CazabonnegetPVInPZ90 method of GLONASSNumericalPropagator should be privateThe getPVInPZ90 method of propagation.numerical.GLONASSNumericalPropagator should be private. Indeed since commit @1feaf45f the frame transformation is performed at the end of the propagation inside the propagate method.The getPVInPZ90 method of propagation.numerical.GLONASSNumericalPropagator should be private. Indeed since commit @1feaf45f the frame transformation is performed at the end of the propagation inside the propagate method.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/603Unknown observation type "1C" when reading RINEX file2019-09-19T07:17:48ZDavid SoulardUnknown observation type "1C" when reading RINEX fileOrekit sends Illegal Argument Exception when reading the following RINEX file:
ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/TLSG00FRA_R_20160440000_01D_30S_MO.crx.gz
The execption occurs at row 880 in RinexLoader.java, variable to = "1C"...Orekit sends Illegal Argument Exception when reading the following RINEX file:
ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/TLSG00FRA_R_20160440000_01D_30S_MO.crx.gz
The execption occurs at row 880 in RinexLoader.java, variable to = "1C" which does not belong to enum ObersationType.10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/604Error in some RINEX file where "SYS / PHASE SHIFT" has a s added a shift2019-09-20T06:05:51ZDavid SoulardError in some RINEX file where "SYS / PHASE SHIFT" has a s added a shiftIn the RINEX file ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/VILL00ESP_R_20160440000_01D_30S_MO.crx.gz
Within the header, some lines end with "SYS / PHASE SHIFTS" instead of "SYS / PHASE SHIFT".
RinexLoader does not accept such an erro...In the RINEX file ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/VILL00ESP_R_20160440000_01D_30S_MO.crx.gz
Within the header, some lines end with "SYS / PHASE SHIFTS" instead of "SYS / PHASE SHIFT".
RinexLoader does not accept such an error.
Should we make RINEX loader accept it anyway ?10.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/605Unknown type C0 reading Rinex files2020-05-15T11:41:04ZDavid SoulardUnknown type C0 reading Rinex filesWithin ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/GAMB00PYF_R_20160440000_01D_30S_MO.crx.gz header, in GLONASS observation type there is a "C0" which is unkown for the RINEX loader.
In RINEX format (ftp://igs.org/pub/data/format/rinex30...Within ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/GAMB00PYF_R_20160440000_01D_30S_MO.crx.gz header, in GLONASS observation type there is a "C0" which is unkown for the RINEX loader.
In RINEX format (ftp://igs.org/pub/data/format/rinex303.pdf) table 5 gives the GLONASS observations code, it does not refer to "C0".10.2https://gitlab.orekit.org/orekit/orekit/-/issues/606Wrong position of the "PRN / # OF OBS" header part in RINEX file2019-11-13T15:58:28ZDavid SoulardWrong position of the "PRN / # OF OBS" header part in RINEX fileIn some RINEX files, such as: ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/HKSL00HKG_R_20160440000_01D_30S_MO.crx.gz and
ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/HKWS00HKG_R_20160440000_01D_30S_MO.crx.gz the header part with "PRN / # ...In some RINEX files, such as: ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/HKSL00HKG_R_20160440000_01D_30S_MO.crx.gz and
ftp://igs.ensg.ign.fr/pub/igs/data/2016/044/HKWS00HKG_R_20160440000_01D_30S_MO.crx.gz the header part with "PRN / # OF OBS"
is placed at the end of the file. Hence reading these files leads to the following error:
"org.orekit.errors.OrekitException: fin inattendue du fichier HKWS00HKG_R_20160440000_01D_30S_MO.crx".https://gitlab.orekit.org/orekit/orekit/-/issues/607Implement data loading proposal2020-01-30T12:51:55ZEvan WardImplement data loading proposalImplement the proposal for a new auxiliary data handling design from https://forum.orekit.org/t/data-context-proposal/589
Goals:
- Updating data a new sets become available
- Running with different data sets in the same application
- Co...Implement the proposal for a new auxiliary data handling design from https://forum.orekit.org/t/data-context-proposal/589
Goals:
- Updating data a new sets become available
- Running with different data sets in the same application
- Comparing results with different data sets
- Compatibility with 10.0
See the discussion thread for more detailed goals, design ideas, and general discussion. This bug is primarily to track implementation progress.
Don't forget to update documentation, and tutorials. :)10.1Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/orekit/-/issues/608Add support for version 3.04 of RINEX files2019-09-26T13:32:21ZBryan CazabonneAdd support for version 3.04 of RINEX filesOrekit supports RINEX versions 2.00, 2.10, 2.11, 2.12, 2.20, 3.00, 3.01, 3.02, and 3.03 for observation files. The new RINEX format 3.04 (ftp://igs.org/pub/data/format/rinex304.pdf) is not supported yet. This format is very close to the ...Orekit supports RINEX versions 2.00, 2.10, 2.11, 2.12, 2.20, 3.00, 3.01, 3.02, and 3.03 for observation files. The new RINEX format 3.04 (ftp://igs.org/pub/data/format/rinex304.pdf) is not supported yet. This format is very close to the ones already supported by Orekit.10.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/609Add comparison methods in AbsoluteDate to improve readability2019-10-04T08:50:25ZYannick JeandrozAdd comparison methods in AbsoluteDate to improve readabilityDuring the discussion [here](https://forum.orekit.org/t/new-absolutedate-methods/594), the community has decided that some new comparison methods in the class AbsoluteDate and FieldAbsoluteDate would help users of Orekit to write more re...During the discussion [here](https://forum.orekit.org/t/new-absolutedate-methods/594), the community has decided that some new comparison methods in the class AbsoluteDate and FieldAbsoluteDate would help users of Orekit to write more readable code.
List of new methods to create in class AbsoluteDate and FieldAbsoluteDate (with TimeStamped replaced by FieldTimeStamped for FieldAbsoluteDate):
- `isEqualTo(TimeStamped t)`: true if instance equals `t.getDate()`
- `isCloseTo(TimeStamped t, double tolerance)`: true if `t.getDate()` is separated from instance by less than tolerance seconds.
- `isBefore(TimeStamped t)`: true if instance is strictly before `t.getDate()`
- `isAfter(TimeStamped t)`: true if instance is strictly after `t.getDate()`
- `isBeforeOrEqualTo(TimeStamped t)`: true if instance is simultaneous or before `t.getDate()`
- `isAfterOrEqualTo(TimeStamped t)`: true if instance is simultaneous or after `t.getDate()`
- `isBetween(TimeStamped t1, TimeStamped t2)`: true if instance is strictly between `t1.getDate()` and `t2.getDate()`. `t1` and `t2` can be in any chronological order, but if they represent the same instant this will always return false.
- `isBetweenOrEqualTo(TimeStamped t1, TimeStamped t2)`: true if instance is strictly between `t1.getDate()` and `t2.getDate()`. `t1` and `t2` can be in any chronological order
10.1Yannick JeandrozYannick Jeandrozhttps://gitlab.orekit.org/orekit/orekit/-/issues/610Add IRNSS propagator2019-10-02T15:55:00ZBryan CazabonneAdd IRNSS propagatorAs IRNSS navigation data are now becoming more widely available, it can be interesting to add a `IRNSSPropagator` class to compute IRNSS satellite positions from navigation data.
More information can be found [here](https://www.isro.gov...As IRNSS navigation data are now becoming more widely available, it can be interesting to add a `IRNSSPropagator` class to compute IRNSS satellite positions from navigation data.
More information can be found [here](https://www.isro.gov.in/sites/default/files/irnss_sps_icd_version1.1-2017.pdf)10.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/611Add SBAS propagator2019-12-03T16:17:32ZBryan CazabonneAdd SBAS propagatorAs SBAS navigation data are now becoming more widely available in navigation RINEX files, it can be interesting to add a `SBASPropagator` class to compute SBAS satellite positions from RINEX navigation data.As SBAS navigation data are now becoming more widely available in navigation RINEX files, it can be interesting to add a `SBASPropagator` class to compute SBAS satellite positions from RINEX navigation data.10.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/612DSST orbit determination tutorial does not work anymore2019-10-02T15:55:00ZLuc MaisonobeDSST orbit determination tutorial does not work anymoreIt appears `DSSTOrbitDetermination` in the `src/tutorials` section is not in sync with `DSSTOrbitDeterminationTest` in the tests section (missing support for `ground.station.weather.estimated`).
Regardless of this key being added or not,...It appears `DSSTOrbitDetermination` in the `src/tutorials` section is not in sync with `DSSTOrbitDeterminationTest` in the tests section (missing support for `ground.station.weather.estimated`).
Regardless of this key being added or not, the tutorial also fails, stopping at the second iteration with a huge RMS.10.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/613Cannot use Dsst in osculating propagation type with event detectors2020-02-20T12:33:44ZDorian GegoutCannot use Dsst in osculating propagation type with event detectorssee https://forum.orekit.org/t/bug-cannot-use-dsst-with-osculating-propagation-type-and-event-detector/598/2 for explanationssee https://forum.orekit.org/t/bug-cannot-use-dsst-with-osculating-propagation-type-and-event-detector/598/2 for explanations10.2Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/614Measurements multiplexer2019-10-09T14:32:21ZLuc MaisonobeMeasurements multiplexerKalman filter process measurements one at a time. When several measurements are performed at the same time it ends up looping, using propagation with duration zero, and adjusting the estimated parameters progressively, with a result that...Kalman filter process measurements one at a time. When several measurements are performed at the same time it ends up looping, using propagation with duration zero, and adjusting the estimated parameters progressively, with a result that depends on the order of measurements and possible observability problems.
We should add a measurement multiplexer that allow to gather all measurements occurring at the same time and present it to the Orbit Determination process as one measurement with a dimension equal to the sum of the individual measurements dimensions.10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/615Requesting addAdditionalEquations() in NumericalPropagatorBuilder2019-11-27T09:29:02ZShiva IyerRequesting addAdditionalEquations() in NumericalPropagatorBuilderI am using Orekit's Kalman estimator. As you know, KalmanEstimatorBuilder expects an IntegratedPropagatorBuilder, which I am providing in the form of a NumericalPropagatorBuilder. I also need to implement AdditionalEquations in my workfl...I am using Orekit's Kalman estimator. As you know, KalmanEstimatorBuilder expects an IntegratedPropagatorBuilder, which I am providing in the form of a NumericalPropagatorBuilder. I also need to implement AdditionalEquations in my workflow, but there is no way to provide AdditionalEquations to a NumericalPropagatorBuilder. My only alternative is to subclass NumericalPropagatorBuilder and add my AdditionalEquations every time the buildPropagator(...) method is called. Would it be possible to add the method addAdditionalEquations() in NumericalPropagatorBuilder?
I can look into implementing this capability myself but wanted to post an issue here in case other developers wish to chime in with concerns.10.1https://gitlab.orekit.org/orekit/orekit/-/issues/616ParameterDriversList doesn't work properly with embedded ParameterDriversList2019-10-09T14:32:37ZLuc MaisonobeParameterDriversList doesn't work properly with embedded ParameterDriversListWhen the `ParameterDriver` added to a `ParameterDriversList` is itself already
a `ParameterDriversList` instance, changed are not propagated properly to all
parameters. Only the one initiating the change and the one in the added list
are...When the `ParameterDriver` added to a `ParameterDriversList` is itself already
a `ParameterDriversList` instance, changed are not propagated properly to all
parameters. Only the one initiating the change and the one in the added list
are updated, the pre-existing ones in the top-level list are forgotten.10.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/617MultiplexedMeasurement does not support multi satellite measurements2019-12-03T16:17:35ZBryan CazabonneMultiplexedMeasurement does not support multi satellite measurementsWhen trying to use `MultiplexedMeasurement` class with measurements form different satellites a `NullPointerException` occurs.
This because state derivatives array is initialize with null object instead of zero values. Initialize the arr...When trying to use `MultiplexedMeasurement` class with measurements form different satellites a `NullPointerException` occurs.
This because state derivatives array is initialize with null object instead of zero values. Initialize the array taking into consideration the state dimension solve the issue.10.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/618ClasspathCrawler matches suportedNames against full path of file2021-09-01T15:21:27ZEvan WardClasspathCrawler matches suportedNames against full path of fileOther crawlers only use the last part of the path, i.e. the file name, for matching with the `supportedNames`, but `ClasspathCrawler` uses the whole path. This creates issues when the regular expression include `^`. By default `Celestial...Other crawlers only use the last part of the path, i.e. the file name, for matching with the `supportedNames`, but `ClasspathCrawler` uses the whole path. This creates issues when the regular expression include `^`. By default `CelestialBodyFactory` includes a `^` in the supported names regular expression. `ClasspathCrawler` should be updated to just use the last component of the path like `ZipJarCrawler` and the other crawlers do.
A workaround is to use a zip file on the class path since `ZipJarCrawler` does correctly handle file names.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/619Moon/EME2000 Frame does not seem to be centred at Moon2019-11-08T15:22:17ZGowtham SivaramanMoon/EME2000 Frame does not seem to be centred at MoonI loaded a state from an OPM file whose `REF_FRAME` is `EME2000` and `CENTER_NAME` is `MOON`. A `CCSDSModifiedFrame` (Moon/EME2000) was returned by the OPMParser.
When I try to get the Moon's position in this frame I end up with large ...I loaded a state from an OPM file whose `REF_FRAME` is `EME2000` and `CENTER_NAME` is `MOON`. A `CCSDSModifiedFrame` (Moon/EME2000) was returned by the OPMParser.
When I try to get the Moon's position in this frame I end up with large values although 0 was expected.
---
**PV of Moon in "Moon/EME2000" Frame** is
{2019-12-22T09:08:20.000, P(-5.57062165160045E8, -4.7554407087575513E8, -1.4359885140204152E8), V(1358.237641860649, -1432.7800019503525, -733.5351121306229), A(0.004348018731378364, 0.0036550471244211962, 0.0010962409176896607)}
At the same time, **PV of Moon in "Moon/Inertial" Frame** (created via `getInertiallyOrientedFrame`)
{2019-12-22T09:08:20.000, P(0.0, 0.0, 0.0), V(0.0, 0.0, 0.0), A(0.0, 0.0, 0.0)}
---
I guess it has something to do with the linear transformation (carried out by CCSDSModifiedFrame) from EME2000 (Earth) to EME2000 (Moon).10.1https://gitlab.orekit.org/orekit/orekit/-/issues/621NPE in GlobalIonosphereMapModel2019-12-03T16:17:35ZEvan WardNPE in GlobalIonosphereMapModelThe attached file, probably corrupt, causes `GlobalIonosphereMapModel` to throw an NPE while parsing it. I would expect an OrekitException with the name of the file and a description of the problem. Seems like `latitudes` and `longitudes...The attached file, probably corrupt, causes `GlobalIonosphereMapModel` to throw an NPE while parsing it. I would expect an OrekitException with the name of the file and a description of the problem. Seems like `latitudes` and `longitudes` are used before checking if those values have been parsed yet.
[missing-header-gpsg0150.19i](/uploads/614a9094132aa86bd62732eb58c69bb9/missing-header-gpsg0150.19i)
```
java.lang.NullPointerException
at org.orekit.models.earth.ionosphere.GlobalIonosphereMapModel$Parser.interpolateTEC(GlobalIonosphereMapModel.java:713)
at org.orekit.models.earth.ionosphere.GlobalIonosphereMapModel$Parser.loadData(GlobalIonosphereMapModel.java:575)
at org.orekit.data.DataProvidersManager$MonitoringWrapper.loadData(DataProvidersManager.java:394)
at org.orekit.data.ClasspathCrawler.feed(ClasspathCrawler.java:145)
at org.orekit.data.DataProvidersManager.feed(DataProvidersManager.java:352)
at org.orekit.models.earth.ionosphere.GlobalIonosphereMapModel.loadsIfNeeded(GlobalIonosphereMapModel.java:434)
at org.orekit.models.earth.ionosphere.GlobalIonosphereMapModel.getTEC(GlobalIonosphereMapModel.java:316)
at org.orekit.models.earth.ionosphere.GlobalIonosphereMapModelTest.testCorruptedFileMissingHeader(GlobalIonosphereMapModelTest.java:163)
```10.1Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/622NPE in AntexLoader2019-11-18T07:40:01ZEvan WardNPE in AntexLoaderWhen parsing the attached, probably corrupted file `AntexLoader` throws a NPE. I would expect an Orekit exception with the file name and line number.
[igs14-npe.atx](/uploads/63c9cf23716c76c05b5e0de2eaaba351/igs14-npe.atx)
```
java.lan...When parsing the attached, probably corrupted file `AntexLoader` throws a NPE. I would expect an Orekit exception with the file name and line number.
[igs14-npe.atx](/uploads/63c9cf23716c76c05b5e0de2eaaba351/igs14-npe.atx)
```
java.lang.NullPointerException
at org.orekit.gnss.antenna.AntexLoader$Parser.loadData(AntexLoader.java:361)
at org.orekit.data.DataProvidersManager$MonitoringWrapper.loadData(DataProvidersManager.java:394)
at org.orekit.data.ClasspathCrawler.feed(ClasspathCrawler.java:145)
at org.orekit.data.DataProvidersManager.feed(DataProvidersManager.java:352)
at org.orekit.gnss.antenna.AntexLoader.<init>(AntexLoader.java:87)
```10.1Bryan CazabonneBryan Cazabonne