Re: [Orekit Developers] Technical Description and Proposal - SOCIS/Orekit Demo App

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

Roberta Falone <robertafalone@gmail.com> a écrit :

> Dear Orekit Community,

Hi Roberta,

> as SOCIS selected student, I want to share with you the proposal for the
> project (that you can find in attached), which has, unfortunately,
> requested more time than estimated: it demanded a preliminary research of
> the proper support libraries (for wall display, open source and compliant
> with the purpose), the testing phase for all of them and the writing of the
> document just to provide the guidelines of the work.

Thank you very much for this report.

> Now I need your support to complete the list of Orekit's features you would
> like to see demostrated, the more useful ones and the best to show Orekit's
> capability. In the document you can find those I evaluated as the most
> significant ones.
>
> Hoping to receive your kind feedback,

Here are the comment I can made after reviewing your document.

Concerning the technologies used, Swing is now quite outdated for  
graphical components. IF you feel more comfortable with this  
framework, though, you can keep it as the focus of the project is more  
on the showcase of Orekit features than on visual aspects. In this  
case, however, I would ask you to separate the representation from the  
rest as much as possible so it can be replaced later on with other  
technologies.

Another point is chart4j, which I would prefer to avoid. The  
application may be run during showcase by people on the move who may  
not be allowed to connect to a network, so the application must be  
able to run as a standalone application.

Yet another choice is the database. As the licensing terms for MySQL  
do not agree wich our scheme, and as the demo should not need too much  
set up, what about using a standalone system like sqlite?

In section 3.4.1, the configuration for events is missing (despite  
they are listed in section 3.4.3 later on). A simple list of  
predefined events that user can toggle on or off would be sufficient  
(say eclipse, node crossings and the like).

In section 3.4.3, sensors footprint would be really interesting, but  
beware it may require some computation on top of Orekit, so it's not  
as immediate (and as demonstrative) as other parts. User should also  
be given some control parameters for the display (either tabular or  
plots), with a selection (probably large) of possible parameters to  
display. The user could select them and remove them easily (and  
perhaps even during the simulation if possible). The list should  
include all geometry parts (Cartesian coordinates in variours frames,  
orbital parameters), but also some derived parameters (norm of the  
velocity, which could be interesting for maneuvers, distance to  
station, distance to other satellite, ...).

The screen shots mock-up are neat, I like them. Please consider having  
several plots with different scales. For example some parameters could  
be function of times but have different units, some plots could be  
parameter 1 function of parameter 2.

As a conclusion, despite there are some things to adapt, I am happy  
with your proposal, you have done a good work.

best regards,
Luc

> my best regards,
>
> Roberta



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.