Add distance/length and angle for events with end coordinates

[lode-mgp]

Would it be a good idea to add properties that can be derived from the start and end coordinates of an event?

I am thinking about two properties:

• distance (between start and end coordinates)
• angle to goal

There could be multiple conventions/orientations for the angle but I think the following would be a good default.

Do you think it makes sense to add these properties in kloppy or not because these properties do not really add extra information since they can be derived from the already existing properties?

[UnravelSports]

They are not very well documented I think, but they should already exist.

For example, as per this test, you should be able to do:

from kloppy.domain.services.transformers.attribute import (
    DistanceToGoalTransformer,
    DistanceToOwnGoalTransformer,
    AngleToGoalTransformer
)

dataset.filter("pass").to_records(
        "timestamp",
        "player_id",
        "coordinates_*",
        DistanceToGoalTransformer(),
        DistanceToOwnGoalTransformer(),
        AngleToGoalTransformer()
    )

[lodevt]

Hi,

Thanks for clarifying this! There seems to be a bug in the implementation of the AngleToGoalTransformer. I think this line (and other lines beneath) should reference 'pitch_width' and 'pitch_length' instead of just 'width' and 'length', as these attributes don't exist.

Also, the current implementation only allows to calculate Angle when the orientation is 'ACTION_EXECUTING_TEAM'.

I could create a PR to

• fix the bug
• add support to calculate Angle for other orientations
• add a new transformer to calculate the distance covered by an event (if start and end coordinates are present) as this is currently not available (only distance to goal/own goal), I think?

[UnravelSports]

I would not be surprised if this indeed is broken, because I think this is very old functionality. @koenvo would you mind chiming in on this?

I think having this functionality, as well as the delta x,y values makes sense would you agree?

Also @probberechts

[probberechts]

Yes, it makes sense to fix any bugs and add a transformer to compute the distance.

On the other hand, I've never used these attribute transformer myself. It's much more efficient to perform these feature computations in Pandas/Polars. Hence, personally, I don't think it's worth the effort to spend a lot of time on implementing more attribute transformers.

[koenvo]

Agree with Pieter. It would make more sense to implement those transformations as polars expressions, and add the columns right before returning the dataframe.

Two reasons why it could make sense:

1. you need to navigate (in a complex way) through events after/before the current one. Example could be DistanceCoveredSince(XYZ)
2. Checking of coordinate system is easier: coordinates need to be in meters (right?) for angles to be useful. Doing such a check in a polars expression is rather impossible.

[lodevt]

Hi, I think we indeed need the distance in meters (or another unit) to have meaningful results. Correct me if I am wrong, but I think that in the current implementation of the DistanceTo(Own)GoalTransformer, the following two points would have the same distance when using a normed coordinate system. Both points have a "normed" distance of 0.5 to the goal but obviously the distance in meters is not the same.

I must say that I don't have much experience with polars, but I could add the distance covered and angle_to_goal columns when returning the dataframe in pandas (right before returning the dataframe, so before this line). The coordinate system / pitch dimensions can also be taken into account.

[probberechts]

There are two possible workflows to compute features from the data:

• Do the computation with EventAttributeTransformer s on the object-oriented data model record-by-record and then export to a dataframe
• First export to a dataframe, then do the feature computation in Polars / Pandas. This can be on a dataframe that contains data from multiple matches.

The EventAttributeTransformer should support any coordinate system / pitch dimensions (or raise an error if it is really not possible). The PitchDimension entity provides support for doing the conversion to metric coordinates. In the alternative workflow, it is the responsibility of the user to pick a coordinate system that allows computing the features.

I like that kloppy supports both. Some features are indeed easier to compute from the object-oriented data model. Hence, sometimes they can be useful. However, typically, it is easier and more efficient to do the computation in Pandas / Polars.

It is good that we have a few very standard EventAttributeTransformers in kloppy and these can also serve as examples to illustrate how people can implement them. I would not bother implementing polars/pandas-based feature computations in kloppy. Rather, we should explain this option in the docs. I think that kloppy should not implement an extensive feature computation library. Feature computation can go in other packages. These can be application-specific (e.g., soccer-xg) or implement common features (e.g., soccer-feature-lib).

[lodevt]

Ok, then maybe I will just create a PR to fix the bug in the existing AngleToGoalTransformer ?