[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] TimeStamped PVCoordinates/AngularCoordinates



What if instead of 1A do a TimeStamped decorator class?  That way we could turn anything into TimeStamped without having potentially redundant class definitions.  It can make the type definition a bit long with nested generics of course, but from an architecture standpoint it would be cleaner.  So you could do something like:

TimeStamped<PVCoordinates> or TimeStamped<AngularCoordinates>


On Wed, Jun 11, 2014 at 5:39 AM, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:
Hi all,

One of the lowest level data structure we use extensively in Orekit is PVCoordinates. It simply holds two vectors and thats all. The class was not intended to be used alone, as people most often need to associate it with both time (typically either an AbsoluteDate instance of an offset from some reference) and a Frame instance. When these more complete data are needed, we use slightly higher level objects, like CartesianOrbit for example. Another similar structure is AngularCoordinates, all the discussion below applies to both cases.

However, I wonder if another intermediate level would be useful or not, with the date already associated with the two vectors (or rotation), but still without frames? There are several places in Orekit where this intermediate level is used, but up to now we relied simply on Pair<AbsoluteDate, PVCoordinates>, using the Pair<K,V> class provided by Apache Commons Math. This is cumbersome, and it does not implement TimeStamped, thus preventing us to collect a bunch of instances in a TimeStempedCache. As we often deal with a full ephemeris of PVCoordinates were all elements have a different date but all are in the same frame, letting the frame out of this seems fair to me.

I can see several different ways to implement it:

 1a) new classes TimeStampedPVCoordinates, TimeStampedAngularCoordinates ...
 1b) internal classes : PVCoordinates.TimeStamped ...
 1c) changing current PVCoordinates to add time

I would personnally prefer 1a as it is simpler than 1b and allow to keep also non-dated PVCoordinates which are useful when the date is either not meaningful for constant positions or when it is in some upper level structure and could lead to some consistency problems if 1c were chosen.

If time-stamped versions of these classes were available, we could also simplify the signature of the static interpolation methods (and probably move them to the new classes).


What do you think about a new class at this level?

best regards,
Luc

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.