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

Re: [Orekit Developers] TimeStamped PVCoordinates/AngularCoordinates

Hi Hank, and Evan

[I combined your two messages to answer both options]

Hank Grabowski <hank@applieddefense.com> a écrit :

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>

This is interesting, but prevents using the new objects in place of the older one were it makes sense. I have started to look at the implications and used inheritance, which is the same thing Evan proposed below.

Evan Ward <evan.ward@nrl.navy.mil> a écrit :

+1 for 1a. If I understand correctly TimeStampedPVCoordinates would
extend PVCoordinates, which would allow us to use the new class with old

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.

I started exactly this way: having the new classes extend the existing ones using the classical pattern: a TimeStampedXxx "is a" Xxx.

As the class considered are really used in many places, it seemed appropriate, and also avoids partly the redundancy as some methods can be inherited. It is not magic, and some methods (mainly the ones that return a new instance) must be overriden so they build the new object type.

You are right about PVCoordinatesProvider, it would really make sense to change its return type. As next version will be a major one, we could porbably do this change. In fact, it will not be too cumbersome for existing code that simply use providers as the new objects will still be a PVCoordinates. It will break code that implements the interface, but I think there are far less new implementations than uses.

best regards,

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,

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

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