|
All,
First apologies for the ugly email. I've finished with the new EphemerisFile interface to replace the OrbitFile interface and applied it to the OEM and SP3 formats. Because I'm away from my desk and don't have access to my keyring so I've pushed up my changes to [1]. I would appreciate your comments and if it looks acceptable we can merge it in to the main repository. [1] https://github.com/wardev/orekit/tree/ephem The bit new features are support for multiple segments in an ephemeris file and a getPropagator() method to view the ephemeris as a BoundedPropagator. During implementation a few smaller issues came up and I'll discuss them below. I'm open to other perspectives and solutions for these. Even though there are a couple rough spots I think effort was successful and the new EphemerisFile interface will be very flexible to accommodate new ephemeris file formats. One issue in the EphemerisFile interface is using <? extends X> in the return types of some methods (i.e. getSatellites(), getSegments(), getCoordinates()). The downside to this is that it makes client code verbose. One advantages are that it allows implementors to add additional information which is used by SP3 and OEM. The other advantage is that it creates a compile time error/warning if client code tries to write to one of the returned collections. The existing SP3, OEM, and unit test code uses 0.0 or Vector3D.ZERO to denote missing data. I think it would be better to switch to using NaN to indicate missing data because zero is a plausible value in some ephemeris files. For example the velocity of a GEO satellite in an Earth fixed frame. In the current code I left zero as the missing data indicator. The mapping between IGS frames in SP3 files and Orekit frames could be smarter. Currently the default is to use the ITRF with 2010 conventions, with the option for the user to provide their own String to Frame conversion. As part of my changes I removed the OrbitFile interfaces and the supporting classes created for it. If instead we wish to maintain backward compatibility we can restore these files and deprecate them, but it will take some addition work to re-implement the OrbitFile interface for SP3 and OEM files. We would also have to rename the getSatellites() method in EphemerisFile because the return type clashes with a method in OrbitFile. I also didn't do any work on incorporating attitude through CCSDS AEM files. Best Regards, Evan From: orekit-developers-request@orekit.org [orekit-developers-request@orekit.org] on behalf of Hank Grabowski [hank@applieddefense.com]
Sent: Thursday, November 03, 2016 1:31 PM To: orekit-developers@orekit.org Subject: Re: [Orekit Developers] Ephemeris Writer Interface These sound good to me.
On Thu, Nov 3, 2016 at 11:21 AM, MAISONOBE Luc
<luc.maisonobe@c-s.fr> wrote:
|