[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Orekit Developers] [SOCIS 2011] improved specifications
- To: Orekit developers <orekit-developers@orekit.org>
- Subject: [Orekit Developers] [SOCIS 2011] improved specifications
- From: Luc Maisonobe <Luc.Maisonobe@c-s.fr>
- Date: Thu, 04 Aug 2011 12:05:05 +0200
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110626 Lightning/1.0b2 Icedove/3.1.11
Hi Alexis,
Here are some improved specifications for the android application. It is
a work in progress and we ask you to review them, help defining the
right choices and organize them in a few work packages, hopefully with
some estimated schedule.
This includes more features than initially planned, but of course not
everything will be developed during this project. We put it there only
to give the big picture and to help decide on the user interface, even
if some parts will still be missing at the end.
From a functional point of view, the application should allow the user
to select between a few separate functions:
- orbits conversions
(Keplerian, circular, equinoctial, Cartesian)
- frames conversions
(position/velocity, with Orekit predefined frames)
- dates conversions
(Orekit predefined time scales)
- events detection
(ground stations, eclipses, apogee/perigee, node ...)
- impulse maneuver computation
(velocity increment in any frame, including local orbital frames)
- orbit visualizing
(2D on a map, with ground track and sensors footprints)
- attitude visualizing
(3D-wireframe unit sphere with axes, planes and angles toggling)
From a data point of view, the application should be able to use updated
data sets (copying files to SD-card is fine). For first users setup,
having a default initial set of data installed when the application is
installed is mandatory. If some functions can process TLE data, then
downloading TLE from the net should be possible. User should also be
able to store some data they use frequently (typically station
coordinates or orbits) and select them from drop lists. Users should be
able to manually edit the parameters and store them for later reuse.
When setting up an orbit, users should be able to use any supported type
(i.e. they can input an orbit in Keplerian, circular, equinoctial or
Cartesian parameters at will). For ground point definition, if the
device supports it the current rough location should be available for use.
best regards,
Luc and Pascal