[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orekit Developers] Ephemeris Writer Interface
"Ward, Evan" <Evan.Ward@nrl.navy.mil> a écrit :
All,
Hi Evan,
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
I just reviewed this. It is a great work, thanks a lot for it.
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 thing you added and is also very interesting is the
AggregatedBoundedPropagator,
which could also be used directly in some users applications
(sayturning on of off
some force models at some points for example).
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.
With some examples, it is acceptable. Java syntax with generics can
be quite ugly.
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.
+1 for NaN.
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.
I think what you provided is smart enough. As users can pass their
own frame builder in the SP3Parser constructor, special frames could
be covered. If of course we already know some widely used strings,
we could perhaps add a few cases in the default implementation,
perhaps using HelmertTransformation.
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.
As we are clearly heading to 9.0, I think it would be better to remove
this interface now just as you have done.
I also didn't do any work on incorporating attitude through CCSDS AEM files.
This can wait a little loner and we can even ship 9.0 without it.
Thanks a lot for this great feature!
best regards,
Luc
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<mailto:luc.maisonobe@c-s.fr>> wrote:
Evan Ward <evan.ward@nrl.navy.mil<mailto: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