this is for holding javascript data
Lucas Fidon edited subsubsection_Description_We_used_a__.tex
almost 8 years ago
Commit id: f103f3db7c85272c24fad40075fbf6f03c5527b8
deletions | additions
diff --git a/subsubsection_Description_We_used_a__.tex b/subsubsection_Description_We_used_a__.tex
index 23a7eb0..e7f6eae 100644
--- a/subsubsection_Description_We_used_a__.tex
+++ b/subsubsection_Description_We_used_a__.tex
...
For our experiments we used only data during a restricted period of several minutes beginning at arbitrary time of the play. Computationnaly we defined a trajectory as a set of ordered x and y-axis positions and accelerations regularly distributed in time.
Furthermore we will handle a set of synchronized trajectories. This synchronization is highly important since we will used it when we will approximate the joint probability distribution of positions or accelerations of two players.
Data are read and extracted with a
25Hz frequency
of 25 Hz which
correspond corresponds to the best frequency we could have if we were extracting
the trajectories directly from the videos of the soccer match. As each players is equipped with several
sensor sensors we combine their data to have one and only one trajectory per
player or ball. player.
Sometimes some data have been missed, we cope with this problem interpolating data so as to maintain synchronization between the different trajectories.
When a player goes out of the field we can't neither treat it as usual with positions out of the field because it would be non sense nor stop extracting the data because it would break the continuity of extracted player's position. Whereas the displacement of a player going and fetching the ball out of the field is non sense, the paths of other players at this while bring relevant information. Thus in this case we just consider that the outside player remain at the last read position on the field with a null acceleration.