Re: [Orekit Developers] Ephemeris Writer Interface

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

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

> On 11/03/2016 04:57 AM, MAISONOBE Luc wrote:
> > I noticed we do not provide any user-friendly way to go from a parsed OEM
> > to a usable ephemeris-based propagator. Use has to get the blocks, and then
> > to get the lines and set up the interpolation. We should probably add this.
> > Does anyone has some code already available for this part too or should I
> > write it? It is quite straightforward to do?
>
> I was planning to start a discussion about going from an ephemeris  
> file to a Propagator, but it looks like you beat me to it. :) Here  
> are my thoughts on modifying the OrbitFile interface. They're only  
> ideas so any comments changes are welcome.
>
> I think the current OrbitFile interface could be improved by adding  
> a getPropagator() method and removing some of the SP3 specific items  
> from the interface, as well as a few other changes.

+1. This should return a BoundedPropagator.
I guess this should use a default attitude provider and user
would call setAttitudeProvider if needed before starting propagation.

We should also add parsing of CCSDS AEM files for attitude. This has
been in the pipe for a while but is still not done.

> Modifications to OrbitFile:
>  - remove accuracy in SatelliteInformation
>  - replace SatelliteTimeCoordiante with TSPVCoordinates
>  - add getFrame() method to return an Orekit frame
>  - change getTimeSystem() to return a String
>  - add getTimeScale() to return an Orekit TimeScale
>  - add getMu()
>  - add getInterpolationSamples()
>  - a method to determine if velocity and acceleration are present,  
> perhaps using CartesianDerivativesFilter.
>
> With these modifications there should be enough information  
> available to create a propagator.
>
> Many of the getXxx(String id) methods of OrbitFile act like a map,  
> so it may be useful to replace them with a method that returns a map  
> from the satellite ID to the information about that satellite.

Not sure if the getCoordinateSystem is really related to sat ID, as
the same satellite could be used in several systems. Your new getFrame
is a very interesting replacement for this.

> I'm planning to have a little time to work on this next week. What  
> do you think?

This seems good to me.

best regards,
Luc

> Best Regards,
> Evan
>
> > Luc