# Recognizing Events in Spatiotemporal Soccer Data
## 4 Game Event Detection Pipeline
### Detecting Passes and Shots on Goal  
When a ball-possessing player attempts to pass the ball to a teammate, we register the occurrence of a pass event. Some passes are successful, while others end with the ball out of bounds or intercepted by the opposing team. A passer, a target receiver, and a pass result (successful/failed) comprise pass event markup in our system. A simple approach for detecting a pass, therefore, can be based on detecting two consecutive basic events: (1) The ball leaves the immediate vicinity of a ball-possessing player; (2) the ball goes out of bounds or comes into the possession of another player (either a teammate or an opponent). In the case of the ST dataset, detecting whether the ball is intercepted by a certain player is not an entirely straightforward process due to the absence of a \(z\)-coordinate of the ball. Data does not show whether the ball approaches the player at a low trajectory or flies high above the player's head. A sharp change of the ball trajectory or speed near a player is a good indication of pass reception. However, passes that do not significantly alter ball movement are also common (for example, defenders often make forward passes to midfielders moving in the same direction). Thus, we use both change of ball speed/trajectory and the presence of a certain \"grace period\" (see Table 2) when the ball is near the potential receiver as indications of a pass event (see Listing 1). A ball going out of bounds is another indication of an unsuccessful pass event. Such passes have to be distinguished from shots on goal. We believe that for most practical tasks, it is enough to treat an event, which ends with a ball passing closer than a certain distance _GoalpostDistance_ (see Table 2) from the nearest goalpost, as a shot on goal, and all other \"out of bounds\" situations as resulting from unsuccessful passes. Since shots are characterized by a shot target point in our system (a single value, representing an offset from the goal center), we note the specific location where the ball crosses the goal line. If this point is outside the goal, we correct the value by moving it to the nearest goalpost and treat this new target as the true intention of the attacker. Finally, we need to identify a target receiver of an unsuccessful pass. This can be a challenging task even for a human observing the game, especially using 2D visualization. In the current system, we use the following heuristics: An intended receiver is the teammate closest to the ball at the moment when it has left the field or has been intercepted by the opponent. In addition, we filter out all \begin{table}
\begin{tabular}{l l l} \hline \hline
**Parameter** & **Value** & **Description** \\ \hline VicinityThreshold & 1.0 m & Minimal distance between the ball and the ball-possessing player \\ GracePeriod & 1.0 s & Time required for a player to be considered a ball receiver \\ GoalpostDistance & 5.0 m & Minimal distance from a goalpost for a kick to be considered a pass \\ MinFailedPassLength & 2.5 m & Minimal ball travel distance of an unsuccessful pass \\ MinTrChangeAngle & 12.5\({}^{\circ}\) & Minimal change in trajectory direction considered “significant” \\ MinSpeedChangeFactor & 1.5 & Minimal change in ball speed considered “significant” \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Initial experimental setup: Parameters. opponent-intercepted passes shorter than _MinFailedPassLength_ (see Table 2). Such situations are treated as tackles, and the ball is merely transferred from one team to another without a pass or shot attempt. As a result, in the current version of the system, we implement the following procedure for detecting passes and shots on goal (see Listing 2).