Compute speed and acceleration

[probberechts]

This PR adds support for computing the speed and acceleration of the ball and the players from tracking data. For example, the code below adds the speed, acceleration and distance covered by the ball and each player to each Frame.

from kloppy import metrica

dataset = (
    metrica
    .load_open_data(match_id=1)
    .compute_ball_kinematics() 
    .compute_player_kinematics()
)

To be able to implement this efficiently for broadcast tracking data, I added the concept of a Trajectory which is a continuous track of the locations of a single player or the ball. A new Trajectory starts every time a frame is missing or a player/ball is not tracked in a frame.

>>> dataset.trajectories["ball"]
[Trajectory(trackable_object='ball', start_frame=1, end_frame=616, detections=[Detection(coordinates=Point(x=0.45472, y=0.6129100000000001), distance=nan, speed=nan, acceleration=nan, other_data={}),...]), ... ] 

I also had to change the interface of a Frame slightly. To be able to handle the ball data and player data uniformly, I renamed the PlayerData class to Detection (although I am not very happy with that name and suggestions for something better are welcome).

I do not think that there are any agreed-upon guidelines on how to filter the data before computing kinematics and the best approach is probably data-dependent, so I've added support for a lot of options (see parameters of compute_kinematics). Any suggestions on what the default parameters should be?

Once this is done, I should be able to finalize the event-tracking data synchronization.

[ussf-jbekkers]

Great work @probberechts!

Do you think there would be any merit to adding a separate smoothing window size for smoothing the ball trajectory, instead of using the same window size for player and ball?

[probberechts]

@ussf-jbekkers I am not sure. Both the ball trajectory and player trajectories are measured using the same sensors, so I assume that they require the same filters. Yet, that assumption might be naive. Data providers might apply different post-processing to the ball and player trajectories. Also, I've never seen code or papers in which people applied different preprocessing to the ball and player trajectories. Do you have experience with applying different filters to the ball and player trajectories? If no one does this, I would not add 5 additional parameters.

[UnravelSports]

@probberechts I personally never considered this until I had a discussion with someone at Dagstuhl about this. His take was really simple, if you smooth the ball the same as you would player trajectories you will see a lot of those situations occur where the ball will "bend away" from a player when they make a pass (for example a one-touch pass) because the moment is pretty rapid and thus the sharp angle the ball would make in 4 or 5 frames will get smoothed so much that it looks like the ball floats away from the player. (I hope this makes sense verbally, I don't have visual example at hand).
Additionally, even though the sensors are the same, the inherit movement of the ball is a lot more predictable and less prone to variation or "jitter" simply because the ball follows a (more or less) predetermined trajectory that doesn't change or deviate from a 2D/3D spline until it gets hit again. This is obviously very different behavior compared to human behavior that can be a lot more erratic.

I understand not wanting to add it, especially because I also didn't consider it until quite recently and it seems like nobody has ever really cared, but it might at least be worth considering or preparing for by choosing parameter names that can be appended with additional/specific ball smoothing parameters without introducing breaking changes in the future.

[probberechts]

@ussf-jbekkers Yes, that makes sense. I'll add the option to smooth the ball trajectory differently.

[probberechts]

I came across this paper that seems interesting: https://journals.sagepub.com/doi/full/10.1177/17479541221124036