One issue I’ve been having working with OreCZML is with displaying sensor cones when no part of the sensor body is intersecting with the Earth. Under these circumstances, the underlying Orekit code will not return any groundpoint data (for the obvious reason that it doesn’t exist), but what then happens on the OreCZML side is that without any footprint information, the simulation breaks down. This means that when I am trying to model a space sensor looking at a space target, I cannot actually generate a simulation where the sensor cone is pointing at my target.
In order to fix this, I would like to add an additional setting to the FieldOfView code that would give the user a choice between footprint generation modes:
The old FOV generation mode, where no ground point is generated when the sensor code does not interact with the central body and a sensor that never hits the central body will generate an error as before.
A new FOV generation mode where, if a sensor line does not interact with the central body, a ground point is generated an arbitrary length away from the origin of the sensor field so that the sensor code will point an arbitrary distance away into space.
The default interface for the FOV code would remain unchanged, and the “pointing into space” feature would only be activated when specifically called upon by the user.
Agreed Luc, I would say as a rule of thumb that it’s the visualization software that must adapt to the physics library, not the other way around. Surely this special case can be handled in OreCZML?
Normally I’d agree with this default assessment (and in fact, it was the exact argument I made to my intern when he proposed this change). However in this particular case, the locations of the ground points are calculated in Orekit, not OreCZML. In order to handle this on the OreCZML side, the calculations would either have to be moved there entirely (and duplicated), or split between Orekit and OreCZML (again, with a duplication of the math involved). Given that changing Orekit to accommodate this doesn’t actually require a change to its default interface, just a minor extension, I thought I’d float the idea of doing it this way instead of trying to split the math calculations between two code bases.
My intern @akilgore-he360 actually already wrote up this code change for our internal use. If you’d like to take a look at what he did and why, I made a draft MR so that his changes would be easy to view.
Bumping this up for visibility. After getting a chance to view the draft of the orekit changes, is the verdict of “don’t alter orekit for oreczml” still the same?