FootPrintOverlapDetector aiming direction issue

Orekit usage
1

Hi !

I am having an issue using the FootprintOverlapDetector. For some regions I get the error :

org.orekit.errors.OrekitException: cannot compute aiming direction at singular point: latitude = … longitude = …

For example, I am using the method EllipsoidTesselator.buildSimpleZone to create the region in the following way:

var targetZone = EllipsoidTessellator.buildSimpleZone(1.0e-10,
new GeodeticPoint(Math.toRadians(30),Math.toRadians(-30),0),
new GeodeticPoint(Math.toRadians(-10),Math.toRadians(-30),0),
new GeodeticPoint(Math.toRadians(-10),Math.toRadians(20),0),
new GeodeticPoint(Math.toRadians(30),Math.toRadians(20),0));

Then I use the FootPrintOverlapDetector like this :

OneAxisEllipsoid earth = new OneAxisEllipsoid(Constants.WGS84_EARTH_EQUATORIAL_RADIUS, Constants.WGS84_EARTH_FLATTENING, FramesFactory.getITRF(IERSConventions.IERS_2010,true));

FootprintOverlapDetector detector = new FootprintOverlapDetector(fov, earth, targetZone, 80000.0).
withHandler(zoneAccessHandler).withMaxCheck(60);

This is giving me the error :

org.orekit.errors.OrekitException: cannot compute aiming direction at singular point: latitude = -9.079 longitude = 5

I really don’t understand the error since I am defining my region Counter Clock Wise as required and it’s not a region crossing th poles, so I don’t see how this can find a singular point …

Does someone have an idea ?

Thank you very much !

2

Hi @aPrz,

Welcome to the Orekit community !

That is weird indeed.
Could you provide us a running example (with orbit and FOV) so we can check why this happens.

Maxime

3

Hello ! Thank you very much for helping me with this issue

Here is a code example giving me the error:

// Define Zone
var targetZone = EllipsoidTessellator.buildSimpleZone(1.0e-10,
new GeodeticPoint(Math.toRadians(30),Math.toRadians(-30),0),
new GeodeticPoint(Math.toRadians(-10),Math.toRadians(-30),0),
new GeodeticPoint(Math.toRadians(-10),Math.toRadians(20),0),
new GeodeticPoint(Math.toRadians(30),Math.toRadians(20),0));

//Define Earth

OneAxisEllipsoid earth = new OneAxisEllipsoid(Constants.WGS84_EARTH_EQUATORIAL_RADIUS, Constants.WGS84_EARTH_FLATTENING, FramesFactory.getITRF(IERSConventions.IERS_2010,true));

// Event handler
var zoneAccessHandler = new ZoneAccessHandler(“Rectangle”);

// Field of View
FieldOfView fov = new CircularFieldOfView(Vector3D.PLUS_K,Math.toRadians(30),0.0);

// Initialization of the detctor
FootprintOverlapDetector detector = new FootprintOverlapDetector(fov, earth, targetZone, 80000.0).
withHandler(zoneAccessHandler).withMaxCheck(60);

So when I simply run these lines as a @Test, it triggers the error …

4

Hi @MaximeJ
The problem is in the targetZone which is around (0, 0), the error occurs in the constructor of FootprintOverlapDetector. We can see it by putting the given targetZone in the method testRightForwardView of the JUnit FootprintOverlapDetectorTest.
I don’t know how to fix it, even splitting the zone in 2, one west one east then joining them (with the RegionFactory) doesn’t solve the problem, we have to check this.

5

All right, thank you very much for the answer !

6

Hi,

@aPrz I think you found a bug ! Thank you.
@pascal.parraud and @luc could you look into it since I’m no expert on tesselation.

In my opinion the bug comes from the first line in the constructor of DivertedSingularityAiming

final S2Point outside = forbiddenZone.getEnclosingCap().getCenter().negate();

From the negate() method.

If we try to convert the center of the enclosing cap (using @aPrz inputs) to a GeodeticPoint we get:

center = {lat: 9,0794674733 deg, lon: -5 deg, alt: 0}

Which looks legit although I would have expected a latitude of +10° instead of +9.079…°
But that’s not the point. Now if we negate this S2Point like in the constructor of DivertedSingularityAiming, and convert it to a GeodeticPoint again we get:

outside = {lat: -9,0794674733 deg, lon: 5 deg, alt: 0}

Right in the middle of the zone !

I would have expected the outside point to be on the other side of the Earth, which is not what the S2Point.negate method do.
Javadoc of this method says Get the opposite of the instance which is a bit cryptic to me…
But when you look into the code, it does indeed change the sign of the lat/lon, not get the opposite point on the sphere.
I don’t know if it’s a bug in Hipparchus or the intended behavior but I think that’s not what we want in Orekit.

So, replacing:

final S2Point outside = forbiddenZone.getEnclosingCap().getCenter().negate();

By:

// Center point of the enclosing cap
final S2Point center = forbiddenZone.getEnclosingCap().getCenter();

// Opposite point on the sphere
final S2Point outside = new S2Point(MathUtils.normalizeAngle(center.getTheta() + FastMath.PI, FastMath.PI), FastMath.PI - center.getPhi());

in DivertedSingularityAiming constructor

Gives:

center = {lat: 9,0794674733 deg, lon: -5 deg, alt: 0}
outside = {lat: -9,0794674733 deg, lon: 175 deg, alt: 0}

and seems to fix @aPrz issue.

What do you think ?

Maxime

7

You have identified the problem well :slight_smile:
But I would like to have @luc 's opinion on how to fix it because the spherical geometry in Hipparchus remains for me a great mystery :frowning:

8

Aaaaarrrgggghhhh! This is a terrible and really stupid bug. I’m sorry for that.
In S2Point.java, line 171, one should change -theta with FastMath.PI + theta so that the new point is really on the other side.

Could you open an issue on Hipparchus for that? This is important and should be fixed ASAP, and probably before Orekit 11.3 is published.

Shame on me :flushed:

9

No problem Luc !! :smiley:

I will do it asap.

I don’t think you plan on doing an Hipparchus release soon. Am I wrong ?
I propose to open another issue in Orekit with the quick-fix provided above and aimed for version 11.3.
Should I add a @Deprecate tag so we remember to fix it when Hipparchus is fixed ?

10

I didn’t, but I could.

11

Feel free to do it but this will be extra work for you and Orekit can be fixed separately.

I’ve opened the issues:

12

Because it is a bug, maybe we could release a 2.2.1 version of Hipparchus?

13

Yes, we could do that, despite the governance in Hipparchus is slightly different from the one in Orekit

14

Ok,
I was preparing a merge request for the bug correction in Orekit but I’ll let you decide what you want to do first

15

Issue 208 in Hipparchus has been fixed.
A vote thread has been started to release Hipparchus 2.3 including the fix for this bug.

1 Like
16

Wow, that was fast! Thank you @luc.