> <mailto:
Luc.Maisonobe@c-s.fr>> wrote:
>
> Le 16/04/2012 22:59, Petrus Hyvönen a écrit :
> > Hi,
>
> Hi Petrus,
>
> >
> > I'm having a question if this is the right way to use
> getIntersectionPoint.
> > I'm trying to simulate the coverage of a relay satellite in
> > geostationary orbit.
> >
> > The geostationary satellite I have modelled as a GroundPoint with 6
> > earth radius altitude, and then transformed to an inertialFrame
> EME2000
> > frame.
> >
> > I have my two positions as Vector3D coordinates in inertialFrame.
> > geo_pos
> >
> > ref_pos
>
>
> I assume ref_pos is a point on ground, is this right ? If not, see the
> last remark at the end of this message.
>
> With such a model, you can use an Earth frame for both points instead of
> an inertial frame. It does not really matter, though as conversions will
> be done under the hood as needed.
>
> >
> >
> > Create a Line with
> > los = Line(ref_pos, geo_pos)
> >
> > ip = mysc.ore_earth.getIntersectionPoint(los, geo_pos,
> inertialFrame, time)
> >
> >
> > and if this is == None (Null) then it has a clear view I would think.
>
> No. If the result is null, then the line that joins your two points does
> not intersect the ore_earth BodyShape. This should not happen if your
> ref point is on Earth (except perhaps at limb as seen from geo_pos).
>
> If the result is non null, then the line enters Earth surface at the
> returned point (and exits at some other point further away).
>
> >
> >
> > The results are not what I expect them to be, no contacts in what I
> > would expect the coverage region and some at other locations.
> Would this
> > be the/a correct way to use getIntersectionPoint?
>
> It is a strange way, but it should work.
> As you already have a ground point ref_pos, a simpler way could be to
> build a TopocentricFrame from it and to use its getElevation method to
> check is it is above observation threshold.
>
>
> As a temporary solution I have used TopocentricFrame, projected the LEO
> satellite footprint on earth and used a slightly negative minimum
> elevation of the GEO satellite as critera in the subpoint topocentric
> frame. Not pretty but seems to work.
>
>
>
> > Is it ok that the Line
> > is in a different frame than the OneAxisEllipsoid, as long as it is
> > specified in the call?
>
> Yes, it's OK. Both los and geo_pos must be in the same specified frame,
> but this frame can be anything. These elements are converted to the
> BodyShape internal frame at the start of the computation.
>
> >
> >
> > I do not understand the Line object really, los.contains(geo_pos)
> gives
> > False, as well as los.contains(ref_pos). The los.origin gives a
> > different value than given in the constructor?
>
> This is strange. Could you send some numerical values with coordinates
> of the various points in all the involved frames (body shape and
> inertial) ? There was also a Line class up to version 5.x of the Orekit
> library, but now we use directly the class from Apache Commons Math
> (which has different and incompatible meanings in the construction
> parameters). What version do you use, Apache Commons Math 2.x/Orekit 5.x
> or Apache commons Math 3.0/Orekit development ? Note that you cannot mix
> these versions.
>
>
> I am using common math 3.0 downloaded using mvn and latest orekit 6.0
> SNAPSHOT. I am using this under Python, but I do not think/hope this is
> influencing the results, all calculations are done in the jvm.
>
> I am not sure if the intersection thing is related to this, but it seems
> like the distance threshold for Line is preset at 1e-10, which seems to
> be lower than my practical case:
>
> In [84]: p1 = Vector3D(163919.77, -6224471.67, -3350987.6)
> In [85]: p2 = Vector3D(18680140.69, -
40551236.16, -23192.4)
> In [86]: l = Line(p1, p2)
>
> In [87]: l.contains(p1)
> Out[87]: False
>
> In [88]: l.distance(p1)
> Out[88]: 5.45683966183878e-10