Thomas Neidhart <thomas.neidhart@gmail.com> a écrit :
On 01/24/2012 08:03 PM, MAISONOBE Luc wrote: I copied some text from the issue comments:The problem I see with an API providing only a PVCoordinates but no reference frame is that it is ambiguous. When conversions occur in other parts of Orekit, two approaches are typically used.I totally agree. One thing I really like about the AbsoluteDate is that it always contains the reference time system, which makes it trivial to convert between different time-scales.
Well, AbsoluteDate does not really store a referene to the time system, but rather converts everything to TAI internally. From a user point of view, this is completely equivalent, but from a computation point of view it allows much simpler handling since TAI is a regular scale.
What do you think about an AbsoluteCoordinate/AbsoluteVector class that resembles the idea of the AbsoluteDate?
This is an idea we had some time ago and dismissed. We are not sure though, so it is worth discussing it here again so everyone can give their opinion about that. So I have changed the subject of the message to focus on this point, I'll answer the rest of the message in another reply with the original subject restored.
The current design uses some small objects that are nested into larger objects. Some of these objects may have full-blown meaning and be self-sufficient, some others are simpler containers and lack some information, so they must be linked to something else.
Coordinates are somewhat in-between. It would be nice to be able to use them as-is, but as you write they lack frame reference.
Orbits are self-sufficient objects, they contain the parameters, the date, the frame, and even mu (which is another problem, I would be happy to get rid of mu in CartesianOrbit for consistency with CCSDS). They represent a fixed-time state, not something that evolves, evolving an orbit is requires much more data, as it depends on a complete dynamical model which can be very complex and there are many such models. So in fact despite being already self-sufficient, orbits are still very low-level objects.
Up to now, we have considered that coordinates with frame as an intermediate level object between PVCoordinates and Orbit did not bring sufficient added-value. So we did not set it up. Do people consider this intermediate class is useful ? If so, then it would be easy to add it. In this case, we should also have a look at the numerous methods and interfaces that already use PVCoordinates and decide whether they should still use PVCoordinates or the new intermediate class. One obvious interface to consider is almost the top-most one: PVCoordinatesProvider, and I guess it should be changed to provide the frame too. This will however introduce a large change in the API since it is used everywhere, but it may be worth doing it, especially for 6.0.
What do people think about this ? Luc
So I would suggest using Yannick API but to add a frame parameter.You mean the computeAcceleration signature would be something like this: Vector3D computeAcceleration(SpacecraftState s, Frame target) throws OrekitException; and the resulting Vector3D would be in the target frame? Thomas
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.