[FEAT] Add a pressure model

[Alek050]

Checklist

• [x] I believe the feature fits the scope of the project

Is your feature request related to a problem? Please describe. There is not really a problem, the package would just be more complete when a pressure model is added.

Describe the solution you'd like I want a pressure model to be added to the package. In 2016, Adrienko et al. published a paper with a pressure model for soccer specific purposes. The model makes an estimate of the pressure on a player based on the location of the defenders relative to the attacker and the distance between the defenders and the player. The parameters described in the paper are optimized for field soccer situations, but can of course be addapted to fit other field sports. Later Herold et al (2022) updated the model of Adrienko et al since they argued that the pressure parameters should change based on the location on the pitch: pressure is location dependent. A new model could be added to the floodligth package that calculates the pressure on a specific player during a specified time period based on tracking data.

sources:

• Andrienko, G., Andrienko, N., Budziak, G., Dykes, J., Fuchs, G., Von Landesberger, T. and Weber, H. (2017). Visual Analysis of Pressure in Football. Data Mining and Knowledge Discovery, 31(6), pp. 1793-1839. doi: 10.1007/s10618-017-0513-2
• Mat Herold, A. Hecksteden, D. Radke, F. Goes, S. Nopp, T. Meyer & M. Kempe (2022): Off-ball behavior in association football: A data-driven model to measure changes in individual defensive pressure, Journal of Sports Sciences, DOI: 10.1080/02640414.2022.2081405

Describe alternatives you've considered A alternative could be to calculcate the pressure of all players of both teams for the whole match. But I would argue this is not really computational efficient since pressure is mainly interesting during on ball events (take ons or 1-vs-1 actions). Calculating pressure for all players and teams would probably take to long and without any added value. However, if we can make the code computational efficient and fast enough it might make it easier to use since some of the other models also calculate everything for all players during the whole match (Kinematics model) if I'm not mistaken.

Additional context

[draabe]

Hi @Alek050!

Thanks for the suggestion. First off, I think this feature fits our scope and would be a great addition! We should probably include a new submodule along the lines of floodlight.models.pressure and give the model a descriptive name.

Regarding the implementation, my first thoughts are:

• You are correct in that the models are all set up to calculate values for each point in time when calling the fit()-method. This makes sense in that the position data-based models' output conforms to our general use of numpy arrays, where the first array dimension implicitly encodes the time steps. So if computationally feasible, this might be the more elegant solution.
• Alternatively, how would you ingest the "interesting" time points? E.g. as an Events object?
• In either case, what would you say the "interesting" output should look like? One pressure value for each player at each frame? So far, models return core objects, mostly Property and XY objects. Is there any good fit for what the intended output?
• Are you planning to incorporate both the Andrienko et al. and Herold et al. model or just the latter? If both, would you say two separate models are needed, or are the improvements of such a kind that they only minimally affect the computation?

[Alek050]

Hey @draabe ,

Thanks for you positive reaction!

The propper naming of variables is always a difficult subject of course. Maybe PlayerPressure would suffice, since it leaves the oppertunity to add a feature later on that finds the pressure on a whole team. A more descriptive name could be PressureOnPlayer, to make clear it is a metric for the degree of pressure a player 'receives' rather than 'gives'.

Regarding your first thoughts:

• I've implemented a version of this in my own code using Tracab soccer data. I've not been able to make it computational efficient enough to calculate it for all players during the whole match in a feasible time period. Let's hope my first try was not my best, because if it is possible, I would agree that this would be the cleanest solution. The main problem is that the calculation needs all opponents within a distance around a player, and the relative angle of those. This essentially means calculating distances for 11 players on every timestamp (rouglly 150,000 in a soccer match).
• I've used the pressure model in combination with a model that defined which individual player had posession of the ball (Vidal-Codina et al., 2022). Whenever a player gained posession of the ball, I could calculate the pressure on that player. I'm not a big fan of using the Event object as it is implemented now. To use that it needs to be synchronized to tracking data since often event and tracking data are poorly aligned based on the timing alone, see also this article. However, after synchronization it would be a nice object to add. Furthermore, it obligates the user to have both event and tracking data of the same match, but I would argue that the pressure metric could also be interesting when having only the tracking data.
• I think this code will fit in the models that are implemented now. As I see it now, the model will return a PlayerProperty with the same number of frames as the input frames. Pressure is a single value that ranges roughly from 0% to 200%. Note that the percentages are a bit vague, but one opponent can apply at its maximum 100% pressure on player, if 2 or three opponents are close, the pressure might range above 100% since the percentages are than summed. So every included player needs one column which fits perfectly in the PlayerProperty.
• I would suggest adding both since it would not add a lot of extra work. The main difference is that the version of Adrienko et al is static, while the verison of Herold et al. changes based on the location on the pitch. An extra argument could be added: model_type="static" or model_type="dynamic" (variable naming could be improved).

I would suggest starting on making a floodlight.models.pressure model PressureOnPlayer. It receives (a slice of) a xy.player() object, the xy object of the opponent team over the same timestamps, and parameters of the pressure model and it returns a PlayerProperty with the pressure of that specific player over that specific timestamp.

Any other suggestions or thoughts?

[draabe]

Hi,

sounds good to me. I'd opt for a bit more specific name (given that there are other pressure models that could be included in the future), but the naming part is rather cosmetic and shouldn't stop us from starting!

• Alright, let's try it this way first and see if we can pull it of. I have started on a "DyadicPlayerDistance" model that does this calculation for each pair of players, but I don't know when I will be able to include this. In the meantime, you could check out the _calc_cell_controls method in the floodlight.models.space.DiscreteVoronoiModel class - there is a distance calculation between two sets of points (all players to all mesh points) that is at least vectorized up to the outmost for-loop spanning time.
• Totally agree, it would be a waste to limit use cases to only situation where synced position and event data are available.
• Sounds good
• Agree

Also sounds like a good plan to get going. In case you haven't seen yet (it's a bit hidden), there is a BaseModel class that implements stuff like the @requires_fit decorator and also handles Pitch objects supplied by the user (see again the Voronoi model on how this looks like in action). This might be useful if you want to calculate distances to goals etc.

[draabe]

Hi @Alek050, closing this due to inactivity.

[Alek050]

Hi @draabe,

Thanks for the update and I understand that you are closing it. I was having problems with dependencies and poetry back when we discussed the issue. I see that the dependencies have been updated since, but have less time now to implement it in your package. I did implement the same idea here, so if you are still interested in the feature being added to Floodlight this could be a good starting point.

[draabe]

Hi @Alek050 , thanks for the heads up! I will look into it