Sorry I did not have a lot of time recently to answer to this topic, I will resume the work on the IOD gauss. @Echulion thanks for the explanation of your work
What I was suggesting, if I remember, was not to limit the f and g definition of the first order of the Taylor Serie and use the definition of f and g found in Vallado equation 2-69 page 87. It should be more precise but maybe the tradeoff between the greater time computation and the gain of precision is not worth it. Anyway for the issue I will just do it at the first order.
For the development of Field, I guess I will have to do it Moreover, there is some duplication in the IOD Laplace and IOD Gooding with the lineOfSight method (and also now in the IOD Gauss) so I was thinking maybe reworking and cleaning the IOD package creating an abstract class and daughter classes. I will also try to take into consideration the proposition of @Serrof of giving the possibility of choosing between different versions.
What was a small issue is kind of becoming a bigger work
revamping the IOD package sounds like a good idea.
I also noticed methods in Gooding that are redundant w.r.t. what is already in Hipparchus’ Vector3D.
About the Lambert solver, there is already an open issue (#748) on it and it could benefit from a re-implementation I think.
So I completed the first part using the @Echulion values as a reference (congrats !) for the validation of my code, because I had the same issue with validating with the Vallado, and Curtis.
I will now work on refactoring the IOD classes and adding fields, so not for now for the merge request but sooner the better !
I was wondering, why do all the IOD methods return a KeplerianOrbit? Is that because only the elliptical case (and not the hyperbolic one) is treated in general? Even so, I think it should return non singular elements so certainly not Keplerian ones… Thoughts?
I’m not sure, I think it’s an oversight. In my opinion they should all return the generic type Orbit and not be limited to a specific type.
Now during the construction of the output orbit, instead of using KeplerianOrbit we could use for example CartesianOrbit. From what I’ve seen IodGibbs/Gooding/Lambert use PVs to construct a Keplerian orbit while a Cartesian would look more natural (Laplace already returns a Cartesian orbit).
You can open a bug but I think @jasquier is already taking care of this on his issue. Or maybe we should split since this would be an API-breaking modification ?
I am working on the iod package architecture so I will take care of the issue, as it was already identified with @MaximeJ. However, I tried to create a pertinent abstract class of the iod but all the iods have specific estimate method, even if looking alike. So it is hard without going deep into all the iods algorithms to do a good refactoring, and I have no time to do it right now.
About Fielding IOD Gauss, same I am stuck with the LaguerreSolver, which is not fielded, and so if I want to continue to field I will have to field a lot of things of Hipparchus about Solver, and same i don’t have the time right now, so i will put it aside for now.
So to summarise, working right now on the refactoring of the IOD architecture but not an ambitious one, putting aside fielding of IOD.
So maybe 2 issues to open about fielding the iod package + big refactoring of iod package.
Moreover, there is some duplication in the IOD Laplace and IOD Gooding with the lineOfSight method (and also now in the IOD Gauss) so I was thinking maybe reworking and cleaning the IOD package creating an abstract class and daughter classes. I will also try to take into consideration the proposition of @Serrof of giving the possibility of choosing between different versions.