[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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,

my best regards,


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