## Earth inertial frame obtained from CelestialBodyFactory is wrong

The following code generates a wrong output:

final Frame earthFrame =
CelestialBodyFactory.getEarth().getInertiallyOrientedFrame();

final Frame base = FramesFactory.getGCRF();

final Rotation quarterPlus = new Rotation(Vector3D.PLUS_K,
Vector3D.PLUS_I,

Vector3D.PLUS_K, Vector3D.PLUS_J);

final Rotation quarterMinus = new Rotation(Vector3D.PLUS_K,
Vector3D.PLUS_I,

Vector3D.PLUS_K, Vector3D.MINUS_J);

for (double dt = -60; dt <= 60; dt += 1.0) {

final AbsoluteDate date = AbsoluteDate.J2000_EPOCH.shiftedBy(dt);

Rotation rotation = base.getTransformTo(earthFrame,
date).getRotation();

System.out.println(dt + " " + Rotation.distance(Rotation.IDENTITY,
rotation) +

" " + Rotation.distance(quarterPlus, rotation) +

" " + Rotation.distance(quarterMinus, rotation));

}

According to the "Report of the IAU/IAG Working Group on Cartographic

Coordinates and Rotational Elements of the Planets and Satellites" the
Earth

frame should be almost aligned with GCRF, so the code above should
display

a first column with an angle of almost 0 and second and third colums
should

display angles of about π/2. However, the first column is about π/2, the
second

column starts with almost zero for dates before J2000.0 and jumps to π
after J200.0,

and the third column starts with π for dates before J2000.0 and drops to
0 after J200.0.

The problem is due to computation of the Q node vector (as per the
report of the IAU/IAG working

group), which is performed on current Orekit using a cross product, and
fails for the Earth

body since its pole is almost aligned with GCRF. There is already a
protection against exactly

aligned poles, but its threshold is far too low.

*(from redmine: issue id 355, created on 2017-08-22, closed on 2017-11-25)*