Re: [Orekit Developers] Ephemeris Writer Interface

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

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

> On 10/26/2016 08:30 AM, MAISONOBE Luc wrote:
> > > > For the most part it seems that the OrekitFixedStepHandler could be used
> > > > as the interface for an EphemerisWriter.
> >
> > Do you imply that EphemerisWriter would extend OrekitFixedStepHandler? What
> > would be the additional methods in this case? So do you intend  
> > something like:
> >
> >  OEMWriter writer = new OEMWriter(file, metaData1, metaData2, ...);
> >  writer.method1();
> >  writer.method2();
> >  propagator.setMasterMode(step, writer);
> >  propagator.propagate();
> >  writer.close();
>
> For the most part, yes. To provide a couple more details of what I'm  
> thinking:
>
> Appendable out = ...;
> Frame frame = ...;
> TimeScale scale = ...;
> OEMWriter writer = new OEMWriter(out, frame, scale, metadata);
> Propagator propagator = ...;
> propagator.setMasterMode(step, writer);
> propagator.propagate();
> // close out if necessary
>
> The EphemerisWriter interface could provide methods such as  
> getFrame(), and getTimeScale(), but these methods don't seem  
> especially necessary. I think the writer can use the isLast  
> parameter of handleStep(...) to figure out when to write the footer,  
> if the file format has one.

Very good! I did not thought about this.

> Do you see a case where we would need an explicit close() or flush()  
> method for the EphemerisWriter? If it turns out that we don't need  
> any additional methods beyond those in OrekitFixedStepHandler then  
> we can just use that interface, with some documentation explaining  
> the intended usage.

No, I don't see why we should close the EphemerisWriter ourselves. If the
Appendable used also implements Closeable, the user should still close it
after the ephemeris is completed.

> > > > One piece of information that is
> > > > missing is the step size, but that could easily be added to the init(...)
> > > > method call.
> >
> > Yes, but if we use constructor for other meta-data, we could also  
> > provide the
> > step size this way.
>
> I pushed up a commit that added the step size to the init(...)  
> method. I think this helps reduce the duplicated information that  
> could become mismatched.

This is fine with me. With this change and Pascal's change about
atmosphere, I guess next version will be 9.0.

I will also add a big bunch of code written by an intern I supervised
for the last few months on a new feature. More on this in a week or two.
My intern will present his work during an ESA mini-symposium at ESTEC,
I do not want to spoil his presentation.

best regards,
Luc

> > > > Additional meta data could be passed in through the
> > > > constructor of the EphemerisWriter, such as frame, time scale, and center
> > > > name. Given the wide variety of metadata accepted by different formats I'm
> > > > not planning on standardizing an interface for setting the metadata. I
> > > > think covariance output could also be supported by providing an initial
> > > > covariance and a suitable mapper to extract the STM from the
> > > > SpacecraftState.
> > > >
> > > > Hank, are you still interested in contributing your OEM writer and would
> > > > it fit with the described interface?
> > > >
> > > > Are there any other formats that would need to be supported by the
> > > > EphemerisWriter interface?
> >
> > I guess the interface should be designed so we provide a few implementations
> > for well-known formats, but also to let people implement it really easily
> > for their own mission-specific formats. That is it should be something
> > closer to OrekitFixedStepHandler, OrekitStepHandler (user-oriented  
> > interfaces)
> > rather than IAUPole or PropagatorConverter (interfaces mainly  
> > intended for internal use)
>
> Agreed.
>
> Best Regards,
> Evan