Re: [Orekit Users] transformation

[pascal parraud <pascal.parraud@c-s.fr>]

Dear Vincent,

The altitude of a GeodeticPoint is defined with respect to some BodyShape.
If you usually construct the central body, namely the Earth in your case, as a OneAxisEllipsoid,
the only implementation of a BodyShape in Orekit, then the altitude is defined with respect to the underlying geoid.
By the way, the latitude is a geodetic one, it is not geocentric.

Best regards,

Pascal

Le 10/10/2011 10:19, Vincent Rivola a écrit :

Dear all,

I have a question about the altitude considered inside Orekit.
When I create a point with "new GeodeticPoint(lon, lat, alt)", what is the altitude to enter? Is it with respect to the sea, or with respect to the geoid? Or even something else?
While propagating the trajectory, I also use the function "getAltitude" and I have the same question about this. What type of altitude does it return?
Thank you for your help.

Vincent



-----Original Message-----
From: MAISONOBE Luc [mailto:luc.maisonobe@c-s.fr] 
Sent: 09 October 2011 21:38
To: Martin
Cc: orekit-users@orekit.org
Subject: Re: Re: [Orekit Users] transformation

Martin <martin.spel@rtech.fr> a écrit :

Dear Luc, thank you very much for the idea.
It is giving the same results as something we were doing before, but this is
more elegant.
For anybody interested, the velocity vector in the ENU frame is build as:

	//velocity expressed in ENU referential
	double cosI = Math.cos(inclinationAngleRad);
	double sinI = Math.sin(inclinationAngleRad);
	double cosFPA = Math.cos(pFlightPathAngleRad);
	double sinFPA = Math.sin(pFlightPathAngleRad);
	double vE = pVelocity * cosI* cosFPA + relativeVelocity.getX();
	double vN = pVelocity * sinI* cosFPA;
	double vU = pVelocity * sinFPA;

The main issue we had is that this gives an orbit with an inclination in the
earth fixed frame. Plotting orbit->getI() gives a different  
inclination due to
the east component being different in the inertial frame. The problem is that
in the input we have velocity and FPA being relative, and inclination in the
inertial. We now solved the problem by only allowing all parameters to be
either in the earth fixed frame or in the inertial frame. No more mixing!

One more question: defining an equatorial orbit going westward seems  
to pose a
problem. I'm getting errors that the minimum step size is reached. Is this a
known issue?

Yes, perfectly equatorial orbits that are also retrograde cannot be  
represented with the current implementation of EquinoctialOrbit. There  
is an extension of EquinoctialOrbits that can handle retrograde  
equatorial orbits, but it is not in Orekit yet (it will be in the  
future). Meanwhile, if you use the current development version of  
Orekit from the Git source repository, you can use the numerical  
propagator with any orbit types, including Cartesian. Up to Orekit  
5.x, numerical propagation always used EquinoctialOrbit internally, so  
you hit the retrograde/equatorial problem.

The development version of Orekit depends on the development version  
of Apache Commons Math, and will be released only when Apache Commons  
Math 3.0 will be released, and this as not yet been decided.

So if you must have equatorial retrograde orbits, you must use both  
development versions. If you can use only released versions, you will  
not be able to handle equatorial retrograde orbits. I'm sorry about  
this.

best regards
Luc

Kind regards,

Martin

--

Pascal PARRAUD CS Systèmes d'Information - Division Espace & Renseignement Département Dynamique du Vol et Simulation Parc de la Grande Plaine - 5, Rue Brindejonc des Moulinais - BP 15872 31506 Toulouse Cedex 05 - FRANCE Tel : +33 561 17 65 15 Email : pascal.parraud@c-s.fr