feat: spatial_metrics_model

[VellaRo]

Added spatialMetricsModel with connvexhull plot (on pitch) and code to run an example.

[draabe]

Hi @VellaRo,

thanks for the feature addition.

Could you briefly explain how this PR differs from #79 ? That's also in the pipeline and quite ready, including convex hull models.

Also, please make sure to follow style conventions as described in the docs

Thanks!

[VellaRo]

Hi @draabe ,

this PR is a modified version of PR 79 to calculate the convex_hull_area and the effective_playing_space.

[manuba95]

Hi @VellaRo,
thanks for the contribution. I agree with @draabe that this is quite similar to #79 but since that seems to not have seen progress in quite some time, this may be a good opportunity to get this feature released.
I think generally the code is already well written and main changes depend on a bit more fundamental design choices that will also influence other Models (future and already released).

1. Flexibility regarding the passed XY-objects. I think this is the most fundamental design choice that will affect how the user can interact with the model. Right know, the user has the option to pass one or two XY-objects to the model to calculate either ConvexHull or EPS. This is similar to the DiscreteVoronoiModel, where the user has to pass two XY-objects (one per team). I think it would be nice if this could be done more flexible, i.e., that the user can pass a single or a list of XY-objects and the calculations get performed for any number. For this PR it would mean that ConvexHull and EPS are basically redundant. The model will calculate the ConvexHull of all XY-objects passed, which would be called EPS if there are two. Of course that would affect the way we approach different methods of the model, e.g., I see that writing the .plot() method that flexible may become interesting. Anyways I think we can use this model to try that approach and maybe decide if we want to apply it to other models, like Voronoi based on the experience. Any ideas from you on that @draabe ?
2. Handling of "invalid" frames. For basically any model, there is an edge case that leads to improper calculations. E.g., to calculate a convex hull with non-zero area, you need at least three points that are not on one line. The former condition gets currently checked in the .count_valid_pairs() method while the latter gets somewhat checked later. A generalized "invalidity" check is probably quite complicated (maybe except for all-nan frames) as the conditions depend on the respective model, but I think every model should have one designated step that checks if the input values will result in a valid output.
3. The role of the .fit() method. The .fit() method generally should fit the data to the model but that does not mean that it already produces the respective models results. Here, the .fit() method already calculates the ConvexHull().volume. This leads to the behavior, that the .plot()-method cannot access the already calculated ConvexHulls so it calculates them again. I think a better way to do this is to store the ConvexHull objects in the array and call the .volume or .vertices in the respective .plot() or .area() method.
   I think these are the main issues you should focus on first. You can find some more specific comments below.