Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2018-08-07T09:44:06Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/198DTM20002018-08-07T09:44:06ZSébastien HerbinièreDTM2000Would it be possible to get the original Fortran routine of DTM2000
getDensity(...) method ?
Thanks
*(from redmine: issue id 198, created on 2015-04-23, closed on 2015-05-21)*Would it be possible to get the original Fortran routine of DTM2000
getDensity(...) method ?
Thanks
*(from redmine: issue id 198, created on 2015-04-23, closed on 2015-05-21)*https://gitlab.orekit.org/orekit/orekit/-/issues/199improve eclipse event handling in DSST Solar Radiation Pressure2020-09-22T07:54:30ZLuc Maisonobeimprove eclipse event handling in DSST Solar Radiation PressureEclipses are currently ignored in this force model.
*(from redmine: issue id 199, created on 2015-04-30)*Eclipses are currently ignored in this force model.
*(from redmine: issue id 199, created on 2015-04-30)*https://gitlab.orekit.org/orekit/orekit/-/issues/200compute attitude derivatives in PartialDerivativesEquations.computeDerivatives2018-08-07T09:44:08ZLuc Maisonobecompute attitude derivatives in PartialDerivativesEquations.computeDerivativesFor now, the attitude/orbit coupling is not considered in the partial
derivatives.
*(from redmine: issue id 200, created on 2015-04-30, closed on 2017-07-27)*For now, the attitude/orbit coupling is not considered in the partial
derivatives.
*(from redmine: issue id 200, created on 2015-04-30, closed on 2017-07-27)*https://gitlab.orekit.org/orekit/orekit/-/issues/201Grid generation2018-08-07T09:44:08ZPascal ParraudGrid generationThe computation of grids of regularly spaced points over zones of
interest would nicely complete the tesselation package.
*(from redmine: issue id 201, created on 2015-05-11, closed on 2016-02-10)*The computation of grids of regularly spaced points over zones of
interest would nicely complete the tesselation package.
*(from redmine: issue id 201, created on 2015-05-11, closed on 2016-02-10)*https://gitlab.orekit.org/orekit/orekit/-/issues/202SaastamoinenModel with negative height2018-08-07T09:44:09ZEvan WardSaastamoinenModel with negative heightUsing the SaastamoinenModel with a negative height causes an
OutOfRangeException. E.g.
<sub></sub>~
Exception in thread "main"
org.apache.commons.math3.exception.OutOfRangeException: -0 out of \[0,
5\] range
<sub></sub>~
While most...Using the SaastamoinenModel with a negative height causes an
OutOfRangeException. E.g.
<sub></sub>~
Exception in thread "main"
org.apache.commons.math3.exception.OutOfRangeException: -0 out of \[0,
5\] range
<sub></sub>~
While most ground stations are above sea level it is quite possible to
have a ground station that is below sea level or below the ellipsoid. I
don't know the details of the model, but I think using sea level values
would be acceptable for these cases.
*(from redmine: issue id 202, created on 2015-05-13, closed on 2017-07-27)*https://gitlab.orekit.org/orekit/orekit/-/issues/203Eventdetection fails with horizon mask2018-08-07T09:44:10ZPetrus HyvönenEventdetection fails with horizon maskIt seems like there is some problem with ElevationDetection and detailed
horizon mask.
The attached example fails at 2012-02-11T06:55:33.867 using orekit 7.0
and apache math 3.4.1.
The failure is detected when EventState.EvaluateStep c...It seems like there is some problem with ElevationDetection and detailed
horizon mask.
The attached example fails at 2012-02-11T06:55:33.867 using orekit 7.0
and apache math 3.4.1.
The failure is detected when EventState.EvaluateStep calls
solver.solve(maxIterationcount, f, dtA, dtB,
AllowedSolution.RIGHT\_SIDE), but where dtA is higher than dtB:
dtA 60.0
dtB 59.999976098797426
Regards
*(from redmine: issue id 203, created on 2015-05-18, closed on 2016-02-10)*
* Uploads:
* [LongVisibilityCheckBug.java](/uploads/454a446059c704b477fb195145d96a86/LongVisibilityCheckBug.java) Example that failshttps://gitlab.orekit.org/orekit/orekit/-/issues/204DTM2000 test cases2018-08-07T09:44:12ZSébastien HerbinièreDTM2000 test casesIn the DTM2000 test cases (DTM2000Test class), there are 6 test cases.
The four first ones are OK, bu the two last ones are not passed.
Actually, when I run these two last tests, I get results different from
the expected.
Could you...In the DTM2000 test cases (DTM2000Test class), there are 6 test cases.
The four first ones are OK, bu the two last ones are not passed.
Actually, when I run these two last tests, I get results different from
the expected.
Could you explain why these tests have been withdrawn, maybe an error in
the reference results ?
Also, the coverage of these test is quite poor (geomagnetic indices
equal to 0 for instance...)
Thanks
*(from redmine: issue id 204, created on 2015-05-22, closed on 2016-02-10)*
* Uploads:
* [DTM2000Test.java](/uploads/ab81de07b6037a6302650a0eb7861f3d/DTM2000Test.java)https://gitlab.orekit.org/orekit/orekit/-/issues/205SecularAndHarmonic does not clear observations when resetting the fitting2018-08-07T09:44:14ZJavier Martin AvilaSecularAndHarmonic does not clear observations when resetting the fittingIn the runup to Orekit 7.0 being released, the implementation of
org.orekit.utils.SecularAndHarmonic changed to accomodate the
reorganization of code in the Apache Commons Math library, with the
subsequent deprecation of the old ACM clas...In the runup to Orekit 7.0 being released, the implementation of
org.orekit.utils.SecularAndHarmonic changed to accomodate the
reorganization of code in the Apache Commons Math library, with the
subsequent deprecation of the old ACM classes. In the old
implementation, the Orekit class used a CurveFitter object that
contained the observations, while in the new version the
SecularAndHarmonic class contains the observed points itself, generating
an anonymous fitter and least squares problem on the fly when the fit
function is called.
The problem is that this new list of observed points is not cleared when
a call to resetFitting is made. In my case, I was using the class to fit
some elements of a GEO orbit in a series of cycles. Once a cycle was
finished, I would reset the fitting but keep the current fit parameters
as the initial guess for the new cycle. I noticed that the fitting
showed a regression if I used the same SAH object, but not if I created
a new one for each cycle, even if I copied the fit parameters from the
old one.
The fix is a one-liner and restablishes the behaviour previous to the
7.0 release: resetting the fit clears the observed points. This case was
not tested for in the new SecularAndHarmonicTest file, and the fix does
not change the result of those tests.
*(from redmine: issue id 205, created on 2015-05-26, closed on 2016-02-10)*
* Uploads:
* [orekit70-SAH-clear.diff](/uploads/15a30129523d995890316970e0915edd/orekit70-SAH-clear.diff) SecularAndHarmonic patch
* [orekit70-SAH-clear-test.diff](/uploads/ebfa79c70cffabbcff751526b21c6616/orekit70-SAH-clear-test.diff) Hastily put together testhttps://gitlab.orekit.org/orekit/orekit/-/issues/206AttitudesSequence does not manage backward propagation consistently2018-08-07T09:44:15ZLuc MaisonobeAttitudesSequence does not manage backward propagation consistentlyIt is possible to use AttitudesSequence with backward propagation, but
it is quite difficult.
When calling addSwitchingCondition, the user has to revert the
before/after attitude providers,
but should *not* reverse the switchOnIncrea...It is possible to use AttitudesSequence with backward propagation, but
it is quite difficult.
When calling addSwitchingCondition, the user has to revert the
before/after attitude providers,
but should *not* reverse the switchOnIncrease and switchOnDecrease
flags.
The API should better be made consistent with events detection (and in
particular with the
increasing flag), i.e. everything should be defined as if propagation
were forward, and internally
the implementation should adjust itself for backward propagation. This
way, the same natural
definition is used regardless of the propagation direction, and once a
sequence is defined, it
doesn't need to be modified if the user navigates back and forth in time
when performing search
algorithms.
*(from redmine: issue id 206, created on 2015-06-04, closed on 2016-02-10)*https://gitlab.orekit.org/orekit/orekit/-/issues/207Access to SGP4 and DeepSDP4 propagators2018-08-07T09:44:15ZPetrus HyvönenAccess to SGP4 and DeepSDP4 propagatorsHi,
I propose that the SGP4 and DeepSDP4 propagators are made public instead
of currently private. Today one can use selectExtrapolator to get the
propagator that is supposed to be used with the TLE but in some cases
the TLE's are speci...Hi,
I propose that the SGP4 and DeepSDP4 propagators are made public instead
of currently private. Today one can use selectExtrapolator to get the
propagator that is supposed to be used with the TLE but in some cases
the TLE's are specified to be used with a certain propagator.
Not sure ifthe SDP4 class needs to be public, seems to be DeepSDP4 that
is the final orbit used if deep space is selected.
*(from redmine: issue id 207, created on 2015-06-05, closed on 2016-02-10)*
* Uploads:
* [patch.diff](/uploads/452e9654ec8d767eba7cecaa0b0088ea/patch.diff) make DeepSDP4 and SGP4 class publichttps://gitlab.orekit.org/orekit/orekit/-/issues/208PropagatorBuilder should allow any orbit type2018-08-07T09:44:16ZLuc MaisonobePropagatorBuilder should allow any orbit typeThe buildPropagator from PropagatorBuilder expect only Cartesian
parameters
as the first 6 elements of its parameters array.
It would be easier to use if orbit type and position angle type were
customizable.
*(from redmine: issue id...The buildPropagator from PropagatorBuilder expect only Cartesian
parameters
as the first 6 elements of its parameters array.
It would be easier to use if orbit type and position angle type were
customizable.
*(from redmine: issue id 208, created on 2015-06-09, closed on 2016-02-10)*Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/209Allow EGM96Reader to optionally initialize with WGS84 coefficients2018-08-07T09:44:17ZHank GrabowskiAllow EGM96Reader to optionally initialize with WGS84 coefficientsSome propagation models are setup with WGS84 coefficients for ae and mu,
rather than the standard EGM96 ones. The rest of the coefficients are
the same, so simply overriding the coefficients at load time creates the
appropriate gravity m...Some propagation models are setup with WGS84 coefficients for ae and mu,
rather than the standard EGM96 ones. The rest of the coefficients are
the same, so simply overriding the coefficients at load time creates the
appropriate gravity model.
*(from redmine: issue id 209, created on 2015-06-09, closed on 2016-02-10)*https://gitlab.orekit.org/orekit/orekit/-/issues/210Exception when accessing ephemeris state on start date2018-08-07T09:44:18ZEvan WardException when accessing ephemeris state on start dateIn the following test case ephemeris.getPVCoordinates(startDate, eci)
will throw an exception. This is a bug because the ephemeris should be
valid starting on startDate. The issue seems to be the imprecision in
StateMapper.mapDoubleToDat...In the following test case ephemeris.getPVCoordinates(startDate, eci)
will throw an exception. This is a bug because the ephemeris should be
valid starting on startDate. The issue seems to be the imprecision in
StateMapper.mapDoubleToDate(). This causes the the ephemeris's start
date to be slightly different from startDate, sometimes greater and
other times less, resulting in unpredictable behaviour.
I'm not sure the best way to fix it. Any ideas?
As a work around I started using a start date 1 second before and an end
date 1 second after my actual start and end dates.
<sub></sub>~
@Test
public void testEphemerisDates() throws OrekitException {
//setup
TimeScale tai = TimeScalesFactory.getTAI();
AbsoluteDate initialDate = new AbsoluteDate("2015-07-01", tai);
AbsoluteDate startDate = new AbsoluteDate("2015-07-03",
tai).shiftedBy(-0.11);
AbsoluteDate endDate = new AbsoluteDate("2015-07-04", tai);
Frame eci = FramesFactory.getGCRF();
KeplerianOrbit orbit = new KeplerianOrbit(
600e3 + Constants.WGS84\_EARTH\_EQUATORIAL\_RADIUS, 0, 0, 0, 0, 0,
PositionAngle.TRUE, eci, initialDate, mu);
double\[\]\[\] tol = NumericalPropagator
.tolerances(1, orbit, OrbitType.CARTESIAN);
Propagator prop = new NumericalPropagator(
new DormandPrince853Integrator(0.1, 500, tol\[0\], tol\[1\]));
prop.resetInitialState(new SpacecraftState(new CartesianOrbit(orbit)));
//action
prop.setEphemerisMode();
prop.propagate(startDate, endDate);
BoundedPropagator ephemeris = prop.getGeneratedEphemeris();
//verify
TimeStampedPVCoordinates actualPV =
ephemeris.getPVCoordinates(startDate, eci);
TimeStampedPVCoordinates expectedPV = orbit.getPVCoordinates(startDate,
eci);
MatcherAssert.assertThat(actualPV.getPosition(),
OrekitMatchers.vectorCloseTo(expectedPV.getPosition(), 1.0));
MatcherAssert.assertThat(actualPV.getVelocity(),
OrekitMatchers.vectorCloseTo(expectedPV.getVelocity(), 1.0));
MatcherAssert.assertThat(ephemeris.getMinDate().durationFrom(startDate),
OrekitMatchers.closeTo(0, 0));
MatcherAssert.assertThat(ephemeris.getMaxDate().durationFrom(endDate),
OrekitMatchers.closeTo(0, 0));
}
<sub></sub>~
*(from redmine: issue id 210, created on 2015-07-01, closed on 2016-02-10)*
* Changesets:
* Revision d5089565ae98d08eb474555e46ead94a07c5fefd by Evan Ward on 2015-08-27T14:32:44Z:
```
Fix ephemeris start and end dates
Previously a generated ephemeris may not have been available at the start and
stop times used for propagation because of numerical precision issues. Now the
real start and end AbsoluteDates are used if they are equivalent to the double
representation of time. The public interfaces ModeHandler and StateMapper were
changed. Includes test cases for the numerical and DSST propagators.
Fixes #210
```
* Revision d5089565ae98d08eb474555e46ead94a07c5fefd by Evan Ward on 2015-08-27T14:32:44Z:
```
Fix ephemeris start and end dates
Previously a generated ephemeris may not have been available at the start and
stop times used for propagation because of numerical precision issues. Now the
real start and end AbsoluteDates are used if they are equivalent to the double
representation of time. The public interfaces ModeHandler and StateMapper were
changed. Includes test cases for the numerical and DSST propagators.
Fixes #210
```
* Revision d5089565ae98d08eb474555e46ead94a07c5fefd by Evan Ward on 2015-08-27T14:32:44Z:
```
Fix ephemeris start and end dates
Previously a generated ephemeris may not have been available at the start and
stop times used for propagation because of numerical precision issues. Now the
real start and end AbsoluteDates are used if they are equivalent to the double
representation of time. The public interfaces ModeHandler and StateMapper were
changed. Includes test cases for the numerical and DSST propagators.
Fixes #210
```
* Revision d5089565ae98d08eb474555e46ead94a07c5fefd by Evan Ward on 2015-08-27T14:32:44Z:
```
Fix ephemeris start and end dates
Previously a generated ephemeris may not have been available at the start and
stop times used for propagation because of numerical precision issues. Now the
real start and end AbsoluteDates are used if they are equivalent to the double
representation of time. The public interfaces ModeHandler and StateMapper were
changed. Includes test cases for the numerical and DSST propagators.
Fixes #210
```
* Revision d5089565ae98d08eb474555e46ead94a07c5fefd by Evan Ward on 2015-08-27T14:32:44Z:
```
Fix ephemeris start and end dates
Previously a generated ephemeris may not have been available at the start and
stop times used for propagation because of numerical precision issues. Now the
real start and end AbsoluteDates are used if they are equivalent to the double
representation of time. The public interfaces ModeHandler and StateMapper were
changed. Includes test cases for the numerical and DSST propagators.
Fixes #210
```
* Revision d5089565ae98d08eb474555e46ead94a07c5fefd by Evan Ward on 2015-08-27T14:32:44Z:
```
Fix ephemeris start and end dates
Previously a generated ephemeris may not have been available at the start and
stop times used for propagation because of numerical precision issues. Now the
real start and end AbsoluteDates are used if they are equivalent to the double
representation of time. The public interfaces ModeHandler and StateMapper were
changed. Includes test cases for the numerical and DSST propagators.
Fixes #210
```Evan WardEvan Wardhttps://gitlab.orekit.org/orekit/orekit/-/issues/211Density derivatives w.r.t. position in drag models2018-08-07T09:44:19ZEvan WardDensity derivatives w.r.t. position in drag modelsCurrently in DragForce.accelerationDerivatives(...) the derivatives of
atmospheric density w.r.t. the satellite's position are ignored. The
computed derivatives will be slightly more accurate if density gradient
is accounted for. I think...Currently in DragForce.accelerationDerivatives(...) the derivatives of
atmospheric density w.r.t. the satellite's position are ignored. The
computed derivatives will be slightly more accurate if density gradient
is accounted for. I think this is a low priority since the differences
are probably not large.
Perhaps a quick fix would be to use a simple exponential gradient with
all atmospheres.
*(from redmine: issue id 211, created on 2015-08-03, closed on 2016-02-10)*https://gitlab.orekit.org/orekit/orekit/-/issues/212EclipseDetect event is not triggered2018-08-07T09:44:21ZSerkan DuralEclipseDetect event is not triggeredEclipseDetectorEvent is not triggered when the initial date is entered
as any date after “29th of July 2015”. Other events such as
EquatorCrossings, Visibility events are working properly.
I’ve used numerical propogator and added the Ec...EclipseDetectorEvent is not triggered when the initial date is entered
as any date after “29th of July 2015”. Other events such as
EquatorCrossings, Visibility events are working properly.
I’ve used numerical propogator and added the EclipseEvent as follows:
<sub></sub>~
NumericalPropagator propagator = null;
EventDetector rawDetector = null;
EventsLogger logger1 = new EventsLogger();
try
{
TimeScale utc = TimeScalesFactory.getUTC();
AbsoluteDate initDate = getAbsoluteDate(utc);
// Orbit construction as Keplerian
keplerOrbit = new KeplerianOrbit(keplerianA, keplerianE,
FastMath.toRadians(keplerianInclination),
FastMath.toRadians(keplerianOmega), FastMath.toRadians(keplerianRaan),
FastMath.toRadians(keplerianAnomaly),
keplerianPositionAngleType,
inertialFrame, initDate, Constants.EGM96\_EARTH\_MU);
SpacecraftState initialState = new SpacecraftState(keplerOrbit,
spacecraftMass);
// Use adaptive Step integrator
if(stepSizeType == ADAPTIVESS)
{
final double\[\]\[\] tolerances =
NumericalPropagator.tolerances(positionTolerance, keplerOrbit,
orbitType);
AdaptiveStepsizeIntegrator integrator =
new DormandPrince853Integrator(stepSizeValue1, stepSizeValue2,
tolerances\[0\], tolerances\[1\]);
//integrator.setInitialStepSize(100.0);
// Propagator
propagator = new NumericalPropagator(integrator);
propagator.setOrbitType(orbitType);
if(isGravitationalForceUsed)
{
NormalizedSphericalHarmonicsProvider provider =
GravityFieldFactory.getNormalizedProvider(10, 10);
ForceModel holmesFeatherstone =
new
HolmesFeatherstoneAttractionModel(FramesFactory.getITRF(IERSConventions.IERS\_2010,
true),
provider);
propagator.addForceModel(holmesFeatherstone);
}
OneAxisEllipsoid earth = new
OneAxisEllipsoid(Constants.GRS80\_EARTH\_EQUATORIAL\_RADIUS,
Constants.WGS84\_EARTH\_FLATTENING,
inertialFrame);
if(isAtmosphericDragUsed)
{
final org.orekit.forces.drag.Atmosphere atm = new
HarrisPriester(CelestialBodyFactory.getSun(), earth, 6);
final SphericalSpacecraft ssc = new
SphericalSpacecraft(spacecraftCrossectionArea,
spacecraftDragCoefficient, 0., 0.);
propagator.addForceModel(new DragForce(atm, ssc));
}
propagator.setInitialState(initialState);
// add handleStep event handler
propagator.setMasterMode(masterModeStep, new
PropogatorFixedStepHandler(masterModeStep, ephemeris, JD\_TT0,
keplerianPositionAngleType, orbitPath, ephemerisPath));
final PVCoordinatesProvider sun = CelestialBodyFactory.getSun();
final PVCoordinatesProvider earthInEclipseEvent =
CelestialBodyFactory.getEarth();
final SortedSet<String> output = new TreeSet<String>();
////////////////////////////////////////////////////////////////
// Set event handlers
BufferedWriter buffWriterEvents = new BufferedWriter(new
FileWriter(eventFilePath));
if(isEclipseEventSelected)
{
dayNightEvents = new DayNightEventHandler(buffWriterEvents);
// Detector : eclipse entry
final EventDetector dayNightEvent =
new EclipseDetector(sun, Constants.SUN\_RADIUS, earthInEclipseEvent,
Constants.WGS84\_EARTH\_EQUATORIAL\_RADIUS).
withHandler(dayNightEvents);
propagator.addEventDetector(dayNightEvent);
}
////////////////////////////////////////////////////////////////
// PROPOGATE
SpacecraftState finalState = propagator.propagate(new
AbsoluteDate(initDate, duration));
<sub></sub>~
And I define eclipse detector event handler as given below
<sub></sub>~
public class DayNightEventHandler implements
EventHandler<EclipseDetector>
{
int\[\] dayEnd = new int\[6\];
int\[\] dayStart = new int\[6\];
private TimeSeries dayNightCrossingSeries = new TimeSeries("Gündüz Gece
Geçişleri");
private List<XYAnnotation> annotationList = new
ArrayList<XYAnnotation>();
private Second startSecond;
private Second endSecond;
private BufferedWriter buffWriterEvents;
public DayNightEventHandler(BufferedWriter buffWriterEvents)
{
this.buffWriterEvents = buffWriterEvents;
}
public Action eventOccurred(final SpacecraftState s, final
EclipseDetector detector, final boolean increasing)
{
if(increasing)
{
keepLog(" Olay (UTC *00) : "* s.getDate() + " Night to Day pass");
}
else
{
keepLog(" Olay (UTC *00) : "* s.getDate() + " Day to night pass");
}
return Action.CONTINUE;
}
private void keepLog(String logText)
{
try
{
buffWriterEvents.write(logText + "\\n");
System.out.println(logText);
}
catch (Exception ex)
{
System.out.println("Uydu olay dosyasında güncellenemedi" +
ex.toString());
}
}
public SpacecraftState resetState(EclipseDetector detector,
SpacecraftState oldState)
{
return oldState;
}
public TimeSeries getTimeSeries()
{
// return visibility events which are kept in TimeSeries
return dayNightCrossingSeries;
}
}
<sub></sub>~
*(from redmine: issue id 212, created on 2015-08-18, closed on 2015-08-20)*https://gitlab.orekit.org/orekit/orekit/-/issues/213Apogee and Perigee Detection in near circular orbits (eccentricity = 0.00127)2018-08-07T09:44:23ZSerkan DuralApogee and Perigee Detection in near circular orbits (eccentricity = 0.00127)What is the most accurate way to determine apogee and perigee crossings
in near circular orbits (such as ecc = 0.00127) ?
ApsideDetector is not accurate enough for near circular orbits.
*(from redmine: issue id 213, created on 2015-0...What is the most accurate way to determine apogee and perigee crossings
in near circular orbits (such as ecc = 0.00127) ?
ApsideDetector is not accurate enough for near circular orbits.
*(from redmine: issue id 213, created on 2015-08-25, closed on 2016-02-10)*https://gitlab.orekit.org/orekit/orekit/-/issues/214JB2006 model2018-08-07T09:44:24Z Carlos CasasJB2006 modelHi,
I was playing around today with Orekit 7 (the version in maven CR). In
particular, with propagations down to the surface of the Earth. Using no
atmosphere model seems to works fine. Using a simple exponential model
also works ok. W...Hi,
I was playing around today with Orekit 7 (the version in maven CR). In
particular, with propagations down to the surface of the Earth. Using no
atmosphere model seems to works fine. Using a simple exponential model
also works ok. When I try to use DTM, I get an exception explaining that
the model is not applicable under 120km (which is the expected behaviour
since the model is not defined for lower altitudes).
The problem comes with JB model. When I propagate down to the surface, I
start getting strange results at around 90km, which eventually make the
integrator crash with a very misleading exception message. Is the JB
model applicable for those altitudes? If it is not, then I think an
exception similar to the one of DTM should be thrown. That would make
the exception simpler to trace.
Keep up the good work!
*(from redmine: issue id 214, created on 2015-09-01, closed on 2016-02-10)*https://gitlab.orekit.org/orekit/orekit/-/issues/215ellipsoid tessellation sometimes fails with either NullPointerException or Ap...2018-08-07T09:44:25ZLuc Maisonobeellipsoid tessellation sometimes fails with either NullPointerException or Apache Commons Math exceptionsWhen the tolerance with which the geographic zone is defined is too
large (1.0e-6 or above in the examples),
tessallation fails. In some cases a NullPointerException is triggered in
EllipsoidTessellator.recurseMeetInside,
in other ca...When the tolerance with which the geographic zone is defined is too
large (1.0e-6 or above in the examples),
tessallation fails. In some cases a NullPointerException is triggered in
EllipsoidTessellator.recurseMeetInside,
in other cases an Apache Commons Math exception is triggered.
One such case is tesselating the following zone, tolerance at 1.0e-6
triggers the NPE, tolerance at 1.0e-4
triggers the Apache Commons Math exception.
final ConstantAzimuthAiming aiming = new
ConstantAzimuthAiming(ellipsoid,
FastMath.toRadians(-168.178485));
EllipsoidTessellator tessellator =
new EllipsoidTessellator(ellipsoid, aiming, 16);
SphericalPolygonsSet small = buildSimpleZone(tolerance, new
double\[\]\[\]{
{ -0.01048739, 0.01598931 }, { -0.00789627, 0.01555693 }, { -0.00558595,
0.01430664 },
{ -0.00380677, 0.01237394 }, { -0.00275154, 0.00996826 }, { -0.00253461,
0.00735029 },
{ -0.00317949, 0.00480374 }, { -0.00461629, 0.00260455 }, { -0.00668931,
0.00099105 },
{ -0.00917392, 0.00013808 }, { -0.01180086, 0.00013808 }, { -0.01428546,
0.00099105 },
{ -0.01635849, 0.00260455 }, { -0.01779529, 0.00480374 }, { -0.01844016,
0.00735029 },
{ -0.01822323, 0.00996826 }, { -0.01716800, 0.01237394 }, { -0.01538882,
0.01430664 },
{ -0.01307850, 0.01555693 }
});
final double maxWidth = 40000.0;
final double maxLength = 40000.0;
final List<List<Tile>>tiles =
tessellator.tessellate(small, maxWidth, maxLength, 0, 0, false, true);
where buildSimpleZone is the utility method from
EllipsoidTessellatorTest.
*(from redmine: issue id 215, created on 2015-09-06, closed on 2016-02-10)*https://gitlab.orekit.org/orekit/orekit/-/issues/216Event to detect GeodeticPoint or an Area of Interest with pitch ond roll angle2018-08-07T09:44:26ZSerkan DuralEvent to detect GeodeticPoint or an Area of Interest with pitch ond roll angleHi,
It could be good to have an event which is triggered when the satellite
approaches to a specific geodetic point or a geographical zone with an
angle (pith and roll angle).
*(from redmine: issue id 216, created on 2015-09-11, close...Hi,
It could be good to have an event which is triggered when the satellite
approaches to a specific geodetic point or a geographical zone with an
angle (pith and roll angle).
*(from redmine: issue id 216, created on 2015-09-11, closed on 2016-02-10)*https://gitlab.orekit.org/orekit/orekit/-/issues/217Units of covariance matrix read from OPM/OMM2018-08-07T09:44:26Z Carlos CasasUnits of covariance matrix read from OPM/OMMWhen reading data from an OPM or OMM, the state vector is read in m and
m/s, but the covariance matrix is read in km^2, km^2/s and km^2/s^2. I
think inconsistency should be avoided, so I propose you to change the
ODMParser class to read ...When reading data from an OPM or OMM, the state vector is read in m and
m/s, but the covariance matrix is read in km^2, km^2/s and km^2/s^2. I
think inconsistency should be avoided, so I propose you to change the
ODMParser class to read the covariance matrix also in m^2, m^2/s and
m^2/s^2.
*(from redmine: issue id 217, created on 2015-09-30, closed on 2016-02-10)*