+1 for 1a. If I understand correctly TimeStampedPVCoordinates would extend PVCoordinates, which would allow us to use the new class with old code. On a similar note, should we change the return type for PVCoordinatesProvider to TimeStampedPVCoordinates? It would create more backward incompatibilities because we are changing the return type of an interface, but the date information is available in this case. Best Regards, Evan On 06/11/2014 05:39 AM, MAISONOBE Luc 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. > >
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature