Re: [Orekit Developers] [SOCIS 2011] New snapshot with event detection

[Alexis Robert <alexis.robert@gmail.com>]

On Wed, Aug 17, 2011 at 10:24 PM, MAISONOBE Luc <luc.maisonobe@c-s.fr> wrote:
> I understand your frustration. Is the horizontal scrollbar necessary on
> phones ? Can we reduce horizontal width such that only vertical scrolling is
> needed ? We could perhaps split the table by days (if it span over more than
> one day) and display only the hours instead of the full date, it would
> reduce width a lot.

Yes but it's not a problem anymore, since the widget is working now
(and in the snapshot) with the horizontal and vertical scrollbars :)
But if you want to split the tables, it's not a problem.

> I don't think it's crappy. Perhaps our own decision to put these data under
> META-INF was wrong. I think it came from maven recommendation, I should
> check again. Anyway, as I see you did embed the data in the apk, it is fine
> with me. These are internal resources which users don't manage, so we can
> put them in any convenient place as long as it is bound to the code itself
> and the users don't have a risk to forget them or to use inconsistent
> versions of code versus data.

Great :)

About the other mail you sent, the assets/ folder is also an Android
standard. The Android documentations (
http://developer.android.com/guide/topics/resources/providing-resources.html
) says that res/raw/ doesn't allow to have subfolders and can only
refer a file by R.raw.file, where assets/ does, that's why I've put
them here so they can be handled by the Eclipse plugin.

Hmm ... if I unzip orekit-20110817.apk it seems that CERT.SF lists the
assets/ files here.

> The separation of events and station seems awkward to me. Playing with the
> application a little, it seems to complicated to use.
>
> In real life space systems, events are used to schedule many things for the
> mission. Telemetry donwlink and telecommands uplinks are bound to station
> visibility (we can connect to the satellite only when it is near one of the
> ground station of this mission network), battery charging using solar arrays
> are bound to eclipse events (we can't use solar arrays when we don't see the
> Sun) ... So people are already used to manage events and they already
> associate stations and visibility events for example. They don't say on one
> side: "I am interested in visibility events" and then "here are the stations
> I manage". They would rather say: "I want to manage Aussaguel station
> events", "I want to manage Kiruna station events", "I want to manage Sun
> eclips umbra events", "I want to manage Sun eclipse penumbra events" ...
>
> This means that when we add an event to be managed, we configure it
> completely. If it is a station visibility event, then the station
> coordinates and name will be configured right from the beginning. This also
> means that from the user point of view (i.e. in the user interface), the
> "Aussaguel station events configuration" is not the same instance as the
> "Kiruna station events detector".
>
> In the example above (with Aussaguel, Kiruna and eclipses), the user would
> set up 4 events, not 2.

Ok, I'll do that.

>>  6. The eventlog parameter is an EventLog instance, which is here to
>> enable passing back the data back to the UI, it will be described just
>> below.
>>
>> EventLog is very simple to use, you have a write method to write a
>> line in the table. It works that way eventlog.write("Visibility
>> Detection", new String[]{"key1", "value1", "key2", "value2"}); The
>> first argument is a tag to tell the user from which event detector the
>> event comes from, the second argument is an array where the even items
>> are keys, and the odd ones are values. Keys are column names.
>>
>> It has been written with the fact that columns might be shared between
>> event detectors in mind. By the way when you add columns A, B and then
>> C, B, it will not write A, B, C which may not respect the way the
>> author wants to display data, but it will write A, C, B (it inserts C
>> between the existing A and B instead of inserting it at the end). This
>> is not done when the write() method is called, but when the
>> renderTable() is called, which will return a String[][] instance
>> you'll feed to TableView.setTable().
>
> I'm afraid I did not understood what you meant here. Could you explain it
> again to me ?

It was just some description of how it handles writing to the table.
Since each event detector can have different column names, I've put
some code to merge the data given by the event detectors.

When an event detector wants to write a line on the table, he calls
the write() method of the EventLog instance he was given.

The module just need to call it that way :

   eventlog.write("Name of the module shown to the user in the final
table (not yet shown)", new String[] {"Column 1", "Data in column 1",
"Column 2", "Data in column 2"});

It will tell to add a line with "Data in column 1" in the column
"Column 1" and "Data in column 2" in the column "Column 2". EventLog
will take care of organizing the columns and the data when rendering
the final table.

I know it's a little bit odd since it's basically like a
HashMap<String, String> but using a String[] and storing
key|value|key|value|key|value, but it has the advantage of being light
and keeping the order of inserted data. Maybe there is a better way of
having a HashMap-like but which keeps the order of the inserted data
(so that column order keeps the same), but I haven't found it.

> Using the application, I found something I forgot to tell. Some events are
> switches, they correspond to changes of a state. Visibility for example
> correspond to swiches between visible state and not visible state. Eclipses
> entry and exit are similar.
>
> There are two different ways to represent these events.
> The first way is to display all events chronologically and use one column to
> identify the type, as follows:
>
>   AUS 2011-08-17T20:01:33  AOS
>   PBD 2011-08-17T20:03:15  AOS
>   AUS 2011-08-17T20:10:33  LOS
>   PBD 2011-08-17T20:10:56  LOS
>
> The second way is to match the event pairs and display the two events in a
> single line as follows:
>
>   AUS 2011-08-17T20:01:33  AOS 2011-08-17T20:10:33  LOS
>   PBD 2011-08-17T20:03:15  AOS 2011-08-17T20:10:56  LOS
>
> The current application is somewhat a mix of both, as it uses one column for
> AOS and another one for LOS, but use a separate line for both, thus having
> either an empty first column or an empty second column.
>
> Would it be possible to have either the first or the second approach
> implemented instead of a mix ? Of course, the best would be to allow the
> user to select the output type he prefers, but that is probably to complex
> for this application. I guess the simplest approach is the first one, and it
> also reduces the width of the display, hence leveraging the need for
> horizontal scrollbar.

Ok, I'll do the first one. But if you want the second one, I can do it
as well as scrollbars are not a problem anymore.

>> Currently, on a phone you have so much info vertically that you can't
>> use the form vertically : the listview doesn't have the room to show 1
>> element, and the "+" button doesn't have the room to show its content.
>
> If we don't split the configuration in one stations list and one events
> list, I hope we will reduce this effect and have something manageable.

Yes this will fix it :)

>> * Also, if you want some benchmarks about event detection on my Nexus
>> One (1GHz CPU, Android 2.3 with JIT enabled, with a cold Orekit
>> cache). 56 seconds to load data, 16 seconds to run the simulation.
>> I've set maxCheck to 5 sec hoping to improve that, but is it ok ?
>
> Yes, it's OK for station visibilities. It could even be set to a larger
> value like 60 seconds for example. This setting is used as a minimal gap
> between checks. When set to 5 seconds, it ensure that an AOS followed more
> than 5 seconds later cannot be missed, but an AOS followed 3 seconds later
> may be missed (but can also be detected, depending if by chance one of the
> checks occurs between the vents). for station visibilities, we are often not
> interested in short duration visibilities. First, we don't have much time to
> do anything interesting with the satellite (retrieving telemetry, sending
> telecommands) and second the signal would probably be less reliable since
> the spacecraft would be only slightly above horizon, at detection threshold.
> In many operational systems, we consider visiblities only when they are at
> least one minute long, so we can safely put the maxCheck threshold at 60
> seconds and save some computation.

Ok :)

>> Should I make it a setting ?
>
> It would be interesting, as the maxCheck selection would probably not be the
> same for other events types like eclipses.

For event types, maxCheck is used only in the .load() method of the
EventProxy instance, so the one used on EventVisibilityProxy can be
different from the one used in EventEclipseProxy (which all inherit
from the EventProxy class).

>> By the way, as there is only visibility detection right now, what
>> would you want me to implement as an event detector in order to try ?
>> :)
>
> Yes, I would like to have eclipses too. Users should be able to set up a
> detector for umbra entry/exit (full eclipses) and another detector (if they
> want) for penumbra entry/exit (partial eclipses).

Ok I'll do that :)

Alexis