[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orekit Users] DihedralFielOfView with a Polygon instead of a PVCoordinatesProvider PVTarget point.
Le 31/01/2014 02:27, Hank Grabowski a écrit :
> Actually for a large enough area you will be missing a bunch. A brute
> force approach I would take would be to see if you have access to any of
> the boundary points defining the area. If you had access to any then
> you had access to the area. This is a lot easier said than done for
> cases like:
>
> 1. Fast moving satellite attitudes or sensor pointing profiles
> 2. Small sensors which will be between sample points
> 3. The case where the sensor is entirely within the boundary.
>
>
> As long as you are avoiding these sorts of cases, you should be able to
> come up with a reasonable approximation of accesses to the ground area
> using the method I mentioned above.
>
> Using the method described by Luc would be preferable, assuming you can
> get a reasonable sensor surface projection for each step. This type of
> calculation is profoundly different from the way these event detectors
> currently work however. It is possible to do similar calculations
> without the new Apache Math library, but it probably wouldn't handle all
> the edge cases the Apache Math algorithms would.
The algorithms I am working on with my Apache hat on will provides some
low level API that will probably help here. The idea would be to define
the area of interest (AOI) as a spherical polyhedron, first. Then given
a simple sensor field of view, user can loop over a few points on sensor
FOV and project each on ground. Here, two main options can be used:
- simply loop of the projected points and check the signed distance
between each points and the AOI
- or define the projected footprint of the sensor as a new region
and check if the two regions do intersect
There is an existing API for both cases. Tclass SphericalPolygonsSet in
package org.apache.commons.math3.geometry.spherical.twod, extends
AbstractRegion and hence implements the projectToBoundary(Point) method
that could be used for first option, and it can be used as an argument
to the RegionFactory intersection method that could be used for second
option.
The first method has the advantage that the return value from
projectToBoundary contains the signed distance (positive is point is
outside, negative if point is inside, 0 if point is crossing the
boundary) which can be used as a g function in an event detector. This
method has the drawback that you have to do the loop on FOV by yourself
and may have some missed events if your loop has a tool loose sampling
rate and your AOI has fine details (say the coast line of Norway for
example).
The second method as the advantage that even fine details will not be
missed, (you staill have to do the loop to define the region, though).
The drawbacks are that you don't have a g function but a binary output :
intersect/don't intersect and that you have to redefine a new region at
each time step, and take care by yourself of weird cases like a FOV that
goes over Earth limb and hence has one part without intersection with
Earth, even if another part does see Earth : you have to close the
footprint at the limb.
In both cases, some optimization can be added t avoid doing lengthy
computation when you are far away from the AOI, by using a simple
bounding cone around your regions, and a shortcut when the line of sight
is clearly outside of this bounding cone. I am working on a way to build
this bounding cone.
Also note that the time sampling of the propagator will also happen, so
the maxCheck is important here like in other event detectors.
I think that for simple FOV, the first method is much simpler and will
give good results. It may also be improved by not using simple projected
points but also link them together with edges, so simple FOV shapes can
be used with few sampling points and without losing too much accuracy.
In this case, the remaining inaccuracy would be the differential effect
of using a great circle on a sphere between projected points mapped from
an ellipsoid and a true projection on an ellipsoid.
Does this seems reasonable to you?
Luc
>
>
> PS. I'd be more than happy to contribute towards studying this problem
> further, FYI...
>
>
>
> On Thu, Jan 30, 2014 at 9:31 AM, Carlos Krefft <ckrefft@rsmas.miami.edu
> <mailto:ckrefft@rsmas.miami.edu>> wrote:
>
> Thank you for the valuable information. I'll keep my eyes open for
> the next release.
>
> In the meantime, I'll try to do something along the lines that Hank
> suggested. Detect Visibility on the AOI center point given possibly
> a negative mask as a buffer, record start and end times, generate
> corridors within those times, and finally intersect them with my
> AOI. I know, it sounds inefficient, I'm definitely looking forward
> to the new release.
>
> BTW: Great work on the orekit. We'll be using it for scheduling
> acquisitions in a production environment soon.
>
> Thanks!
> Carlos
>
>
>
> -----Original Message-----
> From: orekit-users-request@orekit.org
> <mailto:orekit-users-request@orekit.org>
> [mailto:orekit-users-request@orekit.org
> <mailto:orekit-users-request@orekit.org>] On Behalf Of MAISONOBE Luc
> Sent: Wednesday, January 29, 2014 3:45 PM
> To: orekit-users@orekit.org <mailto:orekit-users@orekit.org>
> Subject: Re: [Orekit Users] DihedralFielOfView with a Polygon
> instead of a PVCoordinatesProvider PVTarget point.
>
> Carlos Krefft <ckrefft@rsmas.miami.edu
> <mailto:ckrefft@rsmas.miami.edu>> a écrit :
>
> > I'm looking for a way to make a DihedralFielOfViewDetector detect
> > Visibility against an AOI polygon instead of PVTarget. Is this
> > possible?
>
> It will be possible in the next version, that will depend on Apache
> Commons Math 3.3. This version of Apache Commons Math includes a way
> to define arbitrary shapes on the sphere and to compute things like
> distance to the boundary and hence accurate crossing time. This work
> for simple polygons on the sphere, but also for more complex cases
> with zones defined in several disconnected parts, non-convex areas,
> areas with holes, areas including the pole ...
>
> This will be used for two things in Orekit :
>
> - creating an event handler for spacecrafts flying over zones of
> interest (say a country, even considering separate islands, or
> excluding inner lakes if you want)
> - creating an event handler for arbitrary shaped on-board fields
> of view.
>
> I think what you want is exactly what we are doing right now!
>
> The code for the first event handler is almost ready (it is just
> quite slow for complex shapes, so I have to improve it). The code
> for the second event handler does not exist but can be done in a
> matter of hours. The most important thing to remember is that this
> induces a dependency to Apache Commons Math 3.3, and this version of
> the library is not released yet. It is expected to be released soon,
> but we have no date.
>
> >
> > Any tips or help would be greatly appreciated.
>
> Hope this helps
> Luc
>
> >
> >
> > Kind regards,
> > Carlos Krefft
> > University of Miami
> >
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>