Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2021-02-25T17:21:33Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/756Add new method signature for IodGooding2021-02-25T17:21:33ZBryan CazabonneAdd new method signature for IodGoodingSame as #753 but for `IodGooding`.Same as #753 but for `IodGooding`.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/757Dynamic outlier filter and multiplexed measurements2021-02-16T15:26:04Zandrea fiorentinoDynamic outlier filter and multiplexed measurements[Relevant forum discussion here](https://forum.orekit.org/t/dynamic-outlier-filter-and-multiplexed-measurements/1104).
As of now, the dynamic outlier filter doesn't seem to be correctly applied to Multiplexed measurements before computa...[Relevant forum discussion here](https://forum.orekit.org/t/dynamic-outlier-filter-and-multiplexed-measurements/1104).
As of now, the dynamic outlier filter doesn't seem to be correctly applied to Multiplexed measurements before computation of innovation.
The measurement as a whole should be tagged as rejected if and only if all the observables are rejected. In this case no innovation should be computed.
On the other hand, if only a (proper) subset of the observables is accepted for processing, the innovation should be computed by only taking those into account.https://gitlab.orekit.org/orekit/orekit/-/issues/758Support alpha-5 TLE satellite numbers2021-03-11T10:54:20ZMark RuttenSupport alpha-5 TLE satellite numbersUS Space Force have introduced a new form of 5-digit satellite number (a combination of a letter and numbers) that allows for numbers > 99,999. Orekit currently expects the satellite numbers to be decimal digits.
From the [space-track ...US Space Force have introduced a new form of 5-digit satellite number (a combination of a letter and numbers) that allows for numbers > 99,999. Orekit currently expects the satellite numbers to be decimal digits.
From the [space-track documentation](https://www.space-track.org/documentation#tle-alpha5):
Alpha-5 is a stopgap object numbering schema from the United States Space Force that increases the satellite catalog’s capacity to display up to 339,999 objects in the GP/GP_History API classes using legacy fixed-width Two and Three Line Element Set (TLE/3LE) formats.
Replacing the 1st digit of the 5-digit object number with an alphanumeric character makes it possible to represent 240,000 more numbers. Objects less than 100,000 are unaffected by Alpha-5, as are users who download elsets from the GP and GP_History API classes in other formats like XML, JSON, KVN, and CSV. In order to preserve legacy operations that depend on 5-digit integers, our legacy API Classes tle, tle_latest, and tle_publish will not change to Alpha-5.
Only capital letters and numbers are used in Alpha-5. The letters “I” and “O” are omitted to avoid confusion with the numbers “1” and “0”.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/759Add support for JB2008 (atmosphere model) input data2022-03-02T14:25:34ZBayden PritchardAdd support for JB2008 (atmosphere model) input dataCurrently the JB2008InputParameters interface is not implementedCurrently the JB2008InputParameters interface is not implemented11.2https://gitlab.orekit.org/orekit/orekit/-/issues/760TabulatedProvider ignores frame passed in getAttitude call2021-02-25T17:21:49ZLuc MaisonobeTabulatedProvider ignores frame passed in getAttitude callWhen a `TabulatedProvider` is created, it has a set of predefined attitudes
that have been computed in a fixed reference frame.
When the `getAttitude()` method is called, user can ask for the attitude
in a different frame. This is curren...When a `TabulatedProvider` is created, it has a set of predefined attitudes
that have been computed in a fixed reference frame.
When the `getAttitude()` method is called, user can ask for the attitude
in a different frame. This is currently ignored, the returned attitude
is just interpolated in the table and no frames conversion is attempted.11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/761TabulatedProvider should implement BoundedAttitudeProvider2021-02-26T08:39:23ZLuc MaisonobeTabulatedProvider should implement BoundedAttitudeProviderTable is bounded, so the provider must be too.Table is bounded, so the provider must be too.11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/762TabulatedLofOffset should implement BoundedAttitudeProvider2021-03-05T18:40:52ZBryan CazabonneTabulatedLofOffset should implement BoundedAttitudeProviderSame as #761 but for `TabulatedLofOffset`.Same as #761 but for `TabulatedLofOffset`.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/763Add support for IGS SSR data2021-04-02T14:20:59ZBryan CazabonneAdd support for IGS SSR dataIn October 2020, IGS released the first format for SSR (State Space Representation) data: https://files.igs.org/pub/data/format/igs_ssr_v1.pdf
It could be interesting to start the implementation of this format in OrekitIn October 2020, IGS released the first format for SSR (State Space Representation) data: https://files.igs.org/pub/data/format/igs_ssr_v1.pdf
It could be interesting to start the implementation of this format in Orekit11.0https://gitlab.orekit.org/orekit/orekit/-/issues/764Expose underlying UTC-TAI data in UTCScale2021-03-06T21:00:16ZAndrew GoetzExpose underlying UTC-TAI data in UTCScaleI would like an easy way to access the raw UTC-TAI offset data which underlie a `UTCScale`. I don't see any easy way of extracting that data right now. Thus, I would like to add a `getUTCTAIOffsets()` method to `UTCScale`.I would like an easy way to access the raw UTC-TAI offset data which underlie a `UTCScale`. I don't see any easy way of extracting that data right now. Thus, I would like to add a `getUTCTAIOffsets()` method to `UTCScale`.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/765Implement Geoid.projectToGround2021-03-09T21:01:33ZEvan WardImplement Geoid.projectToGroundImplement `Geoid.projectToGround(TSPVC, ...)`. The method currently throws an `UnsupportedOperationException`. Before that the JavaDoc for `BodyShape.projectToGround(TSPVC, ...)` should be clarified as what projection, if any, is perform...Implement `Geoid.projectToGround(TSPVC, ...)`. The method currently throws an `UnsupportedOperationException`. Before that the JavaDoc for `BodyShape.projectToGround(TSPVC, ...)` should be clarified as what projection, if any, is performed for the velocity and acceleration.https://gitlab.orekit.org/orekit/orekit/-/issues/766Setting AttitudeProvider to the BoundedPropagator generated via propagation2021-09-14T07:59:53ZGowtham SivaramanSetting AttitudeProvider to the BoundedPropagator generated via propagationFollow [this discussion](https://forum.orekit.org/t/setting-attitude-provider-to-a-boundedpropagator/1141) in the forum.Follow [this discussion](https://forum.orekit.org/t/setting-attitude-provider-to-a-boundedpropagator/1141) in the forum.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/767Feature Request: Add a generic `TwoVectorAttitudeProvider` interface2021-04-30T09:29:14ZGowtham SivaramanFeature Request: Add a generic `TwoVectorAttitudeProvider` interfaceIt can be interesting to work out a generic interface, say `TwoVectorAttitudeProvider`, where in we need two vectors or vector providers (like PVCoordinatesProvider), one for pointing and other for phasing.
This will make sure the `Cele...It can be interesting to work out a generic interface, say `TwoVectorAttitudeProvider`, where in we need two vectors or vector providers (like PVCoordinatesProvider), one for pointing and other for phasing.
This will make sure the `CelestialBodyPointed`, `NadirPointing` and `YawSteering` etc. can all implement this particular interface and simplify the architecture of Attitude computation in a whole.
More details on this [here](https://forum.orekit.org/t/sun-pointing-attitude-mode-with-nadir-constraint/1094/5)https://gitlab.orekit.org/orekit/orekit/-/issues/768Parse several types of ITRF specifications2021-03-15T14:50:26ZLuc MaisonobeParse several types of ITRF specificationsSeveral ways to specify ITRF versions are used in several contexts.
- some contexts allow years on two digits (CCSDS ODM before version 3, CCSDS ADM, CCSDS TDM, Orekit `itrf-version.conf`)
- all contexts allow years on 4 digits, some r...Several ways to specify ITRF versions are used in several contexts.
- some contexts allow years on two digits (CCSDS ODM before version 3, CCSDS ADM, CCSDS TDM, Orekit `itrf-version.conf`)
- all contexts allow years on 4 digits, some require them
- some contexts use "-" as separator (CCSDS, Orekit `itrf-version.conf`)
- some contexts use " " as separator (comments in IERS bulletins B)
- some contexts don't use any separators (CCSDS after ITRF2000)
- some contexts would be simpler if "_" was allowed as a separator (parsing from enumerates `name()` output)
- some contexts allow lower case (Orekit `itrf-version.conf`)
It would be simpler if Orekit allowed all these variations to be used, mainly in `itrf-version.conf` and in CCSDS parsing.
For consistency, the constants of the various enums (`org.orekit.frames.ITRFVersion`, `org.orekit.frames.HelmertTransformation.Predefined`, `org.orekit.files.ccsds.definitions.CelestialBodyFrame`) should all use 4 digits years instead of mixing two digits and four digits.11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/769Add SSR Ionospheric model2021-03-23T15:09:30ZBryan CazabonneAdd SSR Ionospheric modelSSR IM201 messages provides elements to compute the ionospheric delay acting on GNSS satellites for a given location. Details about the implementation of the model are given in: https://files.igs.org/pub/data/format/igs_ssr_v1.pdfSSR IM201 messages provides elements to compute the ionospheric delay acting on GNSS satellites for a given location. Details about the implementation of the model are given in: https://files.igs.org/pub/data/format/igs_ssr_v1.pdf11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/770Refactoring of supported RINEX files2023-07-20T06:56:02ZBryan CazabonneRefactoring of supported RINEX filesSince the implementation of the first RINEX format in Orekit (i.e. RINEX observation files represented by RinexHeader and RinexLoader classes), more and more other RINEX formats were added in Orekit: clock files and navigation files for ...Since the implementation of the first RINEX format in Orekit (i.e. RINEX observation files represented by RinexHeader and RinexLoader classes), more and more other RINEX formats were added in Orekit: clock files and navigation files for instance.
Furthermore, RINEX formats are part of the more generic IGS standards regrouping RINEX, ANTEX, and SINEX. All this formats are also supported in Orekit.
Many keys and elements are common between the formats. However, the factorization of these common elements has never been done in Orekit. It could be very useful to take advantage of these commun elements by implementing a more generic and factorized architecture of the RINEX and IGS standard.
Here some idea:
- Create `ObservationFileHeader`, `ClockFileHeader`, and `NavigationFileHeader` classes containing the specific data in the different RINEX formats.
- Create `RinexFileHeader` class containing the common data in the header of the RINEX format.
- Create `IgsFileHeader` class containing the common data in the header of RINEX, ANTEX, and SINEX files.
- Create `RinexParser` class containing the common parsing methods of RINEX formats
- Create `IgsParser` class containing the common parsing methods of IGS standard.
- Rename `RinexLoader` class in `ObservationFileparser` class.
- Create `ObservationFile` class to contain the specific date of RINEX observation files.
- Create `IgsFile` class to contain the common data in IGS files.
- Create `RinexFile` class to contain the common data in Rinex files.
This implementation can be inspired by what is currently done in issue- #474 branch for the factorization of common data.12.0https://gitlab.orekit.org/orekit/orekit/-/issues/771Test EventDetection with tolerance > integrator step size2021-04-30T09:30:02ZEvan WardTest EventDetection with tolerance > integrator step sizeif the tests fail to detect events decide if the fix is improved documentation or code changes. The lines in `EventState.evaluateStep(...)` that make me suspicious are:
```
if (FastMath.abs(dt) < detector.getThreshold()) {
...if the tests fail to detect events decide if the fix is improved documentation or code changes. The lines in `EventState.evaluateStep(...)` that make me suspicious are:
```
if (FastMath.abs(dt) < detector.getThreshold()) {
// we cannot do anything on such a small step, don't trigger any events
return false;
}
```
It seems then that events could be missed even if the g function was positive/negative for longer than `maxCheck` across several integrator steps.https://gitlab.orekit.org/orekit/orekit/-/issues/772Wrong Kepler contribution in FieldNumericalPropagator with OrbitType null2021-04-01T15:08:59ZAlberto FossàWrong Kepler contribution in FieldNumericalPropagator with OrbitType nullThe method `addKeplerContribution()` of the inner class `Main` of `FieldNumericalPropagator` does not correctly computes the velocity derivative if `superGetOrbitType == null`.
Lines 558-562 should read:
```
final FieldVector3D<T> posi...The method `addKeplerContribution()` of the inner class `Main` of `FieldNumericalPropagator` does not correctly computes the velocity derivative if `superGetOrbitType == null`.
Lines 558-562 should read:
```
final FieldVector3D<T> position = currentState.getPVCoordinates().getPosition();
final T r2 = position.getNormSq();
final T coeff = r2.multiply(r2.sqrt()).reciprocal().negate().multiply(mu);
yDot[3] = yDot[3].add(coeff.multiply(position.getX()));
yDot[4] = yDot[4].add(coeff.multiply(position.getY()));
yDot[5] = yDot[5].add(coeff.multiply(position.getZ()));
```
and not call the `getReal()` method of `T` type variables. The computed acceleration should match the one computed with `OrbitType.CARTESIAN` and given by the `addKeplerContribution()` method in `FieldCartesianOrbit`.https://gitlab.orekit.org/orekit/orekit/-/issues/773TimeStampedFieldAngularCoordinates should implements FieldTimeStamped2021-04-07T19:50:45ZBryan CazabonneTimeStampedFieldAngularCoordinates should implements FieldTimeStampedThe change is straightforward because the `getDate()` method is already implemented in the class.The change is straightforward because the `getDate()` method is already implemented in the class.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/774TimeStampedFieldPVCoordinates should implements FieldTimeStamped2021-04-06T12:03:36ZBryan CazabonneTimeStampedFieldPVCoordinates should implements FieldTimeStampedThe change is straightforward because the `getDate()` method is already implemented in the class.The change is straightforward because the `getDate()` method is already implemented in the class.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/775Bug : NullPointerException in the method named interpolate() in FieldSpacecra...2021-04-02T14:20:59ZGhost UserBug : NullPointerException in the method named interpolate() in FieldSpacecraftState.javaIn the method interpolate() in FieldSpacecraftState.java, the orbit field is used to make an array. However the orbit can be null is AbsolutePVCoordinates are used. Therefore we obtain in this case a NullPointerException.
the line : fin...In the method interpolate() in FieldSpacecraftState.java, the orbit field is used to make an array. However the orbit can be null is AbsolutePVCoordinates are used. Therefore we obtain in this case a NullPointerException.
the line : final T[] mm = MathArrays.buildArray(orbit.getA().getField(), 1);
could be change such as : final T[] mm = MathArrays.buildArray(date.getField(), 1);11.0