[FEAT] Add a pressure model about floodlight HOT 6 CLOSED

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?

from floodlight.

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?

from floodlight.

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.

from floodlight.