Measurement Class Redesign Question

Question for the PMC in general, but for @luc @Serrof @MaximeJ @Vincent in particular since you’re the ones I’ve been working with on this project.

Now that we have the generic Observer interface for objects that are working with the ObservableSatellite being estimated to perform the measurement, I was thinking it might be a good idea to have a generic function getObservers() added to AbstractMeasurement similar to the getSatellites() function for the ObservableSatellite values. This function would return a list of Observer values, and the order of the Observer values in the list would be determined by the measurement class in question. For example, Range would have a single Observer and BistaticRange would have two, with the emitter being first and the receiver being second. The reason this would be handy is that it would allow the Observer values to be called via a generic function present in every measurement class automatically. On the other hand, I could see how a generic retrieval function could be confusing when every measurement class behaves a little differently.

What do you think? Add generic function to AbstractMeasurement, or keep retrieval of the Observer values solely in the child classes?

I think a generic getObservers() is a good thing. In some cases, we loop over different kind of measurements (say when we look at a complete set over a time range), so the method would be handy in such a loop.

Hello @baubin,

I think it is a good idea. As Luc said, it would be very useful when we loop over measurements.

Cheers,
Vincent

I am coming back to the Observer design.

Currently, both ObservableSatellite and ObserverSatellite are classes. The Java language does not allow multiple inheritance.

How can we deal with constellation handling with inter-satellite measurements where the same satellite can be both? One use-case I have in mind is when a link is established between two satellites, and depending on a schedule they alternate roles.

I mean ObservableSatellite could be made an interface no? With a couple static method returning a basic implementation.

Note that there is already Observer above ObserverSatellite so it’s also possible for users to go back a level.

Cheers,
Romain.

Currently intersatellite measurements accept ObservableSatellite as both observer and observed. It’s the only case where I didn’t do much to touch the overall code structure, because of this exception. Do you have a reason to believe this would change?

I will try to work around that.
I have custom multi-dimensional GNSS measurements and I need to extend base Orekit classes. Basically, my measurements handle all observables at once (code, phase, Doppler but also signal strength, and this for all signals, so I can end up with dimension 20 in some cases).
I will see if I can just change the constructors for AbstractInterSatellitesMeasurement and AbstractOneWayGNSS to allow non scalar values.

If you have an actual case for what you’re doing, then I can use that as an example to see what would be the best rework. Want to have a conference call or something?