Orekit issueshttps://gitlab.orekit.org/orekit/orekit/-/issues2024-03-27T22:08:03Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/1359Add getFirstNonNullSpan and getLastNonNullSpan to TimeSpanMap2024-03-27T22:08:03ZLuc MaisonobeAdd getFirstNonNullSpan and getLastNonNullSpan to TimeSpanMapIt is possible to get the first and last `Span` in a `TimeSpanMap`.
However, one classical use case for `TimeSpanMap` is to build it first with a `null` object covering the full time range from past infinity to future infinity, and then ...It is possible to get the first and last `Span` in a `TimeSpanMap`.
However, one classical use case for `TimeSpanMap` is to build it first with a `null` object covering the full time range from past infinity to future infinity, and then to add one or several objects with limited time ranges. In this case, the first and last span are not meaningful because they correspond to the out of range parts that extends to infinity.
It would be more user-friendly to be able to retrieve directly the first and last spans that have non-null data. Of course, an exception should be thrown if all spans have null data.12.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1358Add native AdpatableInterval for ApsideDetector2024-03-28T08:15:10ZRomain SerraAdd native AdpatableInterval for ApsideDetector12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1356Various issues in Rinex clock file header parsing for mixed systems2024-03-22T23:27:33ZLuc MaisonobeVarious issues in Rinex clock file header parsing for mixed systemsClock file [JAX0MGXFIN_20202430000_01D_30S_CLK.CLK.gz](https://cddis.nasa.gov/archive/gnss/products/2121/JAX0MGXFIN_20202430000_01D_30S_CLK.CLK.gz) has mixed content (satellite system set to 'M' in the first header line.
This triggers se...Clock file [JAX0MGXFIN_20202430000_01D_30S_CLK.CLK.gz](https://cddis.nasa.gov/archive/gnss/products/2121/JAX0MGXFIN_20202430000_01D_30S_CLK.CLK.gz) has mixed content (satellite system set to 'M' in the first header line.
This triggers several errors when attempting to parse the header:
- an exception is thrown when attemptinf to set up a first version of time scale while parsing line 1 (despite it will be overridden later when "TIME SYSTEM ID" will be parsed)
- line "SYS / DCBS APPLIED" as no satellite system, as no corrections are applied, this triggers another exception
- line "SYS / PCVS APPLIED" as no satellite system, as no corrections are applied, this triggers another exception12.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1355Clock models should provide their validity interval2024-03-22T18:59:03ZLuc MaisonobeClock models should provide their validity intervalClock models retrieved from files (Rinex clock or SP3) have limited validity.
It should be possible to retrived it, in order to put several models in a `TimeSpanMap`Clock models retrieved from files (Rinex clock or SP3) have limited validity.
It should be possible to retrived it, in order to put several models in a `TimeSpanMap`12.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1354Parsing of SP3 files with missing agency in header2024-03-22T17:23:08ZLuc MaisonobeParsing of SP3 files with missing agency in headerSome SP3 files published by CDDIS (like [JAX0MGXFIN_20202440000_01D_05M_ORB.SP3.gz](https://cddis.nasa.gov/archive/gnss/products/2121/JAX0MGXFIN_20202440000_01D_05M_ORB.SP3.gz)) don't have an agency name at the end of the first header li...Some SP3 files published by CDDIS (like [JAX0MGXFIN_20202440000_01D_05M_ORB.SP3.gz](https://cddis.nasa.gov/archive/gnss/products/2121/JAX0MGXFIN_20202440000_01D_05M_ORB.SP3.gz)) don't have an agency name at the end of the first header line.
This triggers an exception in the SP3 parser.12.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1353SP3Parser guessFrame does not recognize ITR142024-03-22T15:22:10ZLuc MaisonobeSP3Parser guessFrame does not recognize ITR14Two problems here:
- SP3Parser::guessFrame fails on "ITR14" (because ITRFVersion.getITRFVersion fails)
- since frame guessing is also needed for other GNSS files (like RINEX), the method should be in some IGSUtils classTwo problems here:
- SP3Parser::guessFrame fails on "ITR14" (because ITRFVersion.getITRFVersion fails)
- since frame guessing is also needed for other GNSS files (like RINEX), the method should be in some IGSUtils class12.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1352Build clock models from samples2024-03-22T15:22:10ZLuc MaisonobeBuild clock models from samplesIt should be possible to build clock models from samples
- directly from user samples
- from Sinex clock files
- from SP3 files
The clock models should also include clock acceleration (currently they are limited to offset and rate)It should be possible to build clock models from samples
- directly from user samples
- from Sinex clock files
- from SP3 files
The clock models should also include clock acceleration (currently they are limited to offset and rate)12.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1351Remove inner private class JacobiPolynomials.JacobiKey2024-03-22T20:49:49ZMaxime JournotRemove inner private class JacobiPolynomials.JacobiKeySince [JacobiKey](https://github.com/Hipparchus-Math/hipparchus/blob/b8b88c512e0f6b30f4e43075a2089e1f14edcae9/hipparchus-core/src/main/java/org/hipparchus/analysis/polynomials/PolynomialsUtils.java#L270) is now a public class in Hipparch...Since [JacobiKey](https://github.com/Hipparchus-Math/hipparchus/blob/b8b88c512e0f6b30f4e43075a2089e1f14edcae9/hipparchus-core/src/main/java/org/hipparchus/analysis/polynomials/PolynomialsUtils.java#L270) is now a public class in Hipparchus (see Hipparchus [issue 322](https://github.com/Hipparchus-Math/hipparchus/issues/322)), there's no need to have it duplicated in Orekit class [JacobiPolynomials](https://gitlab.orekit.org/orekit/orekit/-/blob/master/src/main/java/org/orekit/propagation/semianalytical/dsst/utilities/JacobiPolynomials.java?ref_type=heads#L182)12.1Maxime JournotMaxime Journothttps://gitlab.orekit.org/orekit/orekit/-/issues/1350Changing return type of MeasurementBuilder.build2024-03-22T19:28:17ZLuc MaisonobeChanging return type of MeasurementBuilder.buildThe `MeasurementBuilder` interface is used by Orekit measurements generation feature. It is specialized for each measurement type. Its `build` method returns a specific `ObservedMeasurement<T>` (i.e `Range` for `RangeBuilder`, `Phase` fo...The `MeasurementBuilder` interface is used by Orekit measurements generation feature. It is specialized for each measurement type. Its `build` method returns a specific `ObservedMeasurement<T>` (i.e `Range` for `RangeBuilder`, `Phase` for `PhaseBuilder`…).
Internally, all implementations work by creating first a dummy `ObservedMeasurement<T>`, then call its `estimateWithoutDerivatives` to build an `EstimatedMeasurementBase<T>`, retrieve from this intermediate object the true measurement value and finally build another `ObservedMeasurement<T>` with the correct value. This second `ObservedMeasurement<T>` is then returned through a bunch of classes (`AbstractScheduler`, then an internal step handler, then `Generator`). At the end, it is passed to a `GeneratedMeasurementSubscriber`).
I have a use case where the information present in the `ObservedMeasurement<T>` is not sufficient; I would need to get the states of the spacecraft involved in the measurement, as they hold some additional states I need. I cannot just call again the propagators that are used by the `Generator` because doing this stalls the generation (probably some kind of dead lock or infinite recursion as the propagator calls the measurements generator which then would call the propagator back). Setting up another propagator also seems a waste of resources since the states have already been computed during the measurement generation; they were just thrown away when building the second `ObservedMeasurement<T>` from the `EstimatedMeasurementBase<T>`.
This issue intends to change the API of `MeasurementBuilder` and all the intermediate classes so the measurements that are built and returned to users are `EstimatedMeasurementBase<T>` rather than `ObservedMeasurement<T>`. It targets Orekit 13.0 milestone as it changes several public signatures. Partial backward compatibility is ensured as `ObservedMeasurement<T>` can be retrieved from the `EstimatedMeasurementBase<T>` using its `getObservedMeasurement()` method. The returned `EstimatedMeasurementBase<T>` contains much more information than `ObservedMeasurement<T>` (states, participants...).13.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1347No public constructor in Inertia and InertiaAxis classes2024-03-15T13:26:43ZMiyuNo public constructor in Inertia and InertiaAxis classesThere is no public constructor in Inertia and InertiaAxis classes, so it is not possible to create those objects.
(Posted this [here](https://forum.orekit.org/t/how-to-use-torquefree-attitude-provider/3369))There is no public constructor in Inertia and InertiaAxis classes, so it is not possible to create those objects.
(Posted this [here](https://forum.orekit.org/t/how-to-use-torquefree-attitude-provider/3369))12.0.2https://gitlab.orekit.org/orekit/orekit/-/issues/1346Rinex observation V4 can miss ANTENNA: DELTA H/E/N header line for receivers ...2024-03-15T13:26:43ZLuc MaisonobeRinex observation V4 can miss ANTENNA: DELTA H/E/N header line for receivers in vehiclesThis header line is replaced by ANTENNA: DELTA X/Y/Z for moving receivers.
However, when the END header marker is found, there are checks that ANTENNA: DELTA H/E/N has been parsed, so correct files are rejected.This header line is replaced by ANTENNA: DELTA X/Y/Z for moving receivers.
However, when the END header marker is found, there are checks that ANTENNA: DELTA H/E/N has been parsed, so correct files are rejected.12.0.2Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1345Add J2-only ForceModel2024-03-18T22:02:30ZRomain SerraAdd J2-only ForceModelFor performance, avoiding `HolmesFeatherAttractionModel` `gradient` and Earth rotationFor performance, avoiding `HolmesFeatherAttractionModel` `gradient` and Earth rotation12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1344HasNonKeplerianAcceleration is wrong in FieldOrbit2024-03-16T22:42:13ZRomain SerraHasNonKeplerianAcceleration is wrong in FieldOrbitDoesn't do the same check than in Orbit, which is the correct one.
The Field version is also slowing down creation of FieldOrbit, which is detrimental for the State Transition Matrix computationDoesn't do the same check than in Orbit, which is the correct one.
The Field version is also slowing down creation of FieldOrbit, which is detrimental for the State Transition Matrix computation12.1Romain SerraRomain Serrahttps://gitlab.orekit.org/orekit/orekit/-/issues/1343Generate Rinex observations in receiver clock2024-03-22T12:45:17ZLuc MaisonobeGenerate Rinex observations in receiver clockAs receiver clock time scale has been added as per issue #1342, it should be possible to use it when writing Rinex observation files.As receiver clock time scale has been added as per issue #1342, it should be possible to use it when writing Rinex observation files.12.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1342Build offset time scale from clock model2024-03-22T12:45:34ZLuc MaisonobeBuild offset time scale from clock modelGNSS signals are timestamped by satellite and ground clocks that can be associated with quadratic clock models.
`QuadraticClockModel` has been added recently to take this into account in measurements.
It would be interesting to allow bui...GNSS signals are timestamped by satellite and ground clocks that can be associated with quadratic clock models.
`QuadraticClockModel` has been added recently to take this into account in measurements.
It would be interesting to allow building an offset `TimeScale` from such a clock model, hence representing a local clock vision of time.12.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1341{set|get}ClkOffset in RinexObservationHeader is confusing2024-03-14T12:17:18ZLuc Maisonobe{set|get}ClkOffset in RinexObservationHeader is confusingThe name of the methods as well as its javadoc seem to imply the value is an offset (despite it is an integer), but it really is a flag corresponding to entry "RCV CLOCK OFFS APPL" in Rinex header.
So the names should read `{set|get}Cloc...The name of the methods as well as its javadoc seem to imply the value is an offset (despite it is an integer), but it really is a flag corresponding to entry "RCV CLOCK OFFS APPL" in Rinex header.
So the names should read `{set|get}ClockOffsetApplied` and the type should be a boolean.12.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1340SRP dependance on position only should be true for isotropic models2024-03-10T14:20:33ZRomain SerraSRP dependance on position only should be true for isotropic models`false` slows down STM computation so should be avoided if possible
Could be done at same time than #1337`false` slows down STM computation so should be avoided if possible
Could be done at same time than #133712.1https://gitlab.orekit.org/orekit/orekit/-/issues/1338Add a way to retrieve the effect of an EstimationModifier2024-03-06T22:13:39ZLuc MaisonobeAdd a way to retrieve the effect of an EstimationModifier`EstimationModifier` implementations use `setEstimatedValue` to update the current value.
There is no way to retrieve the original value before any modifications or to get the effect of each modifier independently, only the final updated...`EstimationModifier` implementations use `setEstimatedValue` to update the current value.
There is no way to retrieve the original value before any modifications or to get the effect of each modifier independently, only the final updated value is available.
Accessing these data should be possible.12.1Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/1337Add getter for RadiationPressureSensitive in SolarRadiationPressure2024-03-07T16:52:16ZRomain SerraAdd getter for RadiationPressureSensitive in SolarRadiationPressure12.1https://gitlab.orekit.org/orekit/orekit/-/issues/1336Add getBodyName in third bodies2024-03-07T20:10:35ZRomain SerraAdd getBodyName in third bodiesPossibly also factorize things like `dependsOnlyOnPosition` for `ForceModel`Possibly also factorize things like `dependsOnlyOnPosition` for `ForceModel`12.1Romain SerraRomain Serra