Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions Regarding the use of _add_dribbles #798

Open
GeonHeeJo2000 opened this issue Aug 19, 2024 · 5 comments
Open

Questions Regarding the use of _add_dribbles #798

GeonHeeJo2000 opened this issue Aug 19, 2024 · 5 comments
Labels
enhancement New feature or request

Comments

@GeonHeeJo2000
Copy link

GeonHeeJo2000 commented Aug 19, 2024

Hello,
I am currently conducting research on VAEP and have a few questions regarding the _add_dribbles function. I would greatly appreciate your insights on the following points:

  1. Rationale Behind Using _add_dribbles
  • I am curious about the reasoning behind the implementation of the _add_dribbles function. Is it primarily used to account for cases where dribble events are not explicitly recorded? Considering that StatsBomb data includes a carry event, I would like to understand why _add_dribbles is still necessary in this context.
  1. Criteria for Connecting Dribble Locations
  • I am seeking clarification on why the _add_dribbles function connects dribbles between the end location of one event and the start location of the next event. Dribbling is typically defined as controlling the ball while moving. Given this definition, wouldn't it be more accurate to connect the start of a dribble to an action where a player gains control, such as receiving a pass or recovering the ball? This would imply that the dribble should start from the location where the ball is controlled, extending to the start location of the next event. Specifically, in the case of StatsBomb data, where events such as Ball Receipt* and Ball Recovery are recorded, wouldn't it be more appropriate to base the addition of dribbles on these control events?

  • My concern arises from situations where, for example, shot is deflected off the goalpost and returns to a player. In such cases, the action recorded might not be a pass received or recovery, but rather a Miscontrol. If _add_dribbles is applied in this scenario, it could incorrectly add a dribble from the goalpost location (the end location of the shot) to the start of the next event (the start location of the miscontrol). This could result in a situation where a player is erroneously credited with a successful dribble, despite having miscontrolled the ball. Wouldn't it be more logical to limit the addition of dribbles to instances where a control action has occurred?

  1. Differences Between Opta and StatsBomb
  • I also noticed that while Opta has a _fix_recoveries function, StatsBomb does not. Could you please explain the reasoning behind this difference?

Thank you for your time and attention to these questions. I look forward to your response and any clarification you can provide.

@probberechts probberechts added the question Further information is requested label Aug 23, 2024
@probberechts
Copy link
Member

Dribbles are added to fill gaps in the event stream. These are periods in which a player moves the ball without any real pressure from an opponent. Not all providers explicitly annotate this as an event. But since moving the ball changes the game state value, we have to add an action for it.

StatsBomb indeed has the "Carry" event for this purpose. I would have to look into it since this is not something that I implemented myself, but I assume that StatsBomb is a bit more selective on when a dribble should be added. Hence, there are still some instances in which socceraction adds one to ensure consistency in the SPADL representation between all providers. If you are curious to see in which instances socceraction adds dribble events, you can look for dribbles without an "original_event_id".

The implementation of add_dribbles could definitely be improved. Currently, it is implemented on the SPADL representation which means that the same code can be used for all providers. However, the Ball Receipt* event is not available in this representation. See also #51, which is somewhat related. Currently, this does not have a high priority for me, but if you would like to work on provider-specific implementations of the add_dribbles function, feel free to create some pull requests :).

@GeonHeeJo2000
Copy link
Author

GeonHeeJo2000 commented Aug 23, 2024

Thank You! @probberechts

Thank you for your response. I now have a better understanding of the conditions under which dribbles are added. However, the issue I presented remains unresolved. For instance, in the case of a shot that hits the post, the end location of the shot would be the goalpost, while the starting position of the player who retrieves the rebounded ball would be some distance away from the post. In this scenario, a dribble is often added, which I believe is inappropriate.

To explain more clearly, when a shot+ bad_touch sequence occurs and the distance between the shotand bad_touchis greater than 3 meters, a dribble is automatically inserted, resulting in a shot+ dribble+ bad_touch sequence. However, this situation involves a rebound off the post, and I do not think a dribble should be added in such cases. Therefore, I have considered introducing a possession-based approach to adding dribbles.

The concepts of ball receipt and recovery are defined according to StatsBomb's criteria. If we were to implement a possession-based approach, Opta and Wyscout would also need to adapt their definitions accordingly. I am aware that this is not a simple task, as there are various scenarios where a dribble might be added, such as in a take_on + pass sequence.

If we do not adopt this approach, we would need to address this issue within the SPADL framework. However, I am uncertain whether SPADL can adequately represent situations where the ball rebounds off the post. I would appreciate any advice you could provide on this matter. While I agree that addressing this within SPADL would bring consistency, the potential penalties associated with this issue are significant. For instance, in the case of a bad_touchaction occurring immediately after a shot near the goal, a substantial penalty should be imposed. However, if a dribble is added, the dribble may receive a positive VAEP, likely due to the proximity to the goal.

@GeonHeeJo2000
Copy link
Author

Adding a dribble after a shot requires a more cautious approach. To illustrate this point, I’ve provided an example:

Example:

Starting at 31:53 in the video, you can see Iniesta taking a shot that is blocked by Ramos, causing the ball to rebound. Since SPADL does not account for the block action, the next action after the shot is recorded as Jordi Alba gaining possession of the ball. Consequently, an incorrect dribble is added by the _add_dribbles function. While this example involves a block, similar issues can occur when a shot rebounds off the goalpost. Currently, these situations are not being properly addressed.

If such an event were to occur near the goal, the _add_dribbles function could lead to an incorrect VAEP estimation. To resolve this issue, it might be necessary to handle such cases for each provider before converting to SPADL.

image
image

@probberechts
Copy link
Member

Thanks for the example! I am aware that the _add_dribbles function can sometimes add invalid dribbles. However, I do not see an easy solution for this. It would require reimplementing the function for each provider on the original event data representation. Currently, I do not have the capacity to spend time on that. I also don't think it would have a big impact on a player's action values. Dribbles in general have a low value and the instances where invalid dribbles are added are rare.

@probberechts probberechts added enhancement New feature or request and removed question Further information is requested labels Aug 26, 2024
@GeonHeeJo2000
Copy link
Author

Thank you for your response. I understand that these actions aren’t very common, but if the block action were incorporated into SPADL, I believe it could significantly reduce the occurrence of such situations. Currently, block isn’t converted into a tackle or interception because its primary purpose is to restrict the space behind the opponent’s attack rather than to regain possession. I’m curious, though—could you share the reasoning behind the decision not to include block?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants