MatchLogger: The app continues

Jan 8

A web app for analytically visualizing soccer player movements and touches, prototyped with HTML, CSS, JavaScript, and Python.

One in a series of projects highlighting my progress as a self-taught programmer.

I began teaching myself Python, SQL, and GIS in spring 2023 — starting from zero. I therefore welcome feedback on these projects and review for errors. And I’d be interested in taking a crack at your own data and geospatial questions too. Please get in touch.

9 January 2024

Background

As of this writing, I call it v04, but this is my third post about MatchLogger, a web app I’ve been developing to track soccer player movements and touches over the course of a match—and to analytically visualize the player’s engagement with the game. Behold the evolution:

My first post described a grid-like UI for logging a player’s whereabouts on the pitch, which, with statistical manipulation, could yield an ok, but often blotchy, positional heat map…

… the second post explained a far more precise method for capturing x, y pitch coordinates (still with taps/clicks) and obtaining smoother visualizations…

Project outputs

… and this third post introduces a new feature: The option to categorize events on the pitch, from passes to shots to saves.

Events are time-stamped, allowing for temporal analysis, and my separate Python script (not yet incorporated into the app) now produces several new, customizable visualizations of the logged action:

Much of the UX/UI work from v02 to the current v04 is aesthetic, with the only technical addition a popup overlay of event categories. When this feature is enabled, users tap/click their screen twice for each event—once to log the location, once to log what happened. For each event, the exported csv reports location, category, a timestamp, and a unique event ID, which I figured might plausibly be useful at some point. My Python script also produces a glossary/key/legend for the event types—how human users interpret an event obviously will affect the data (e.g. should that awkwardly received pass and immediate challenge be logged a “miscontrol” or “duel”?).

User (my) trials will tell how realistic or frustrating it is to log a player’s match. For ease of use and consistency of data—hopefully—the current version tries to focus categorization around just four (almost) binary questions, with negative values immediately ending the particular moment of engagement:

First touch: Did the player collect the ball effectively? Control / Miscontrol
Possession: Did the player advance the ball at all, or were they dispossessed? Possess / Dispossessed
Last touch: Did the player play a successful pass? Pass / Pass incomplete
Defense: Did the player’s defensive action yield a positive or negative result? Contain / Dribble-past

The interface equally anticipates a Shot or 50-50 Duel as well as less frequent event types such as Goal, fouls, offside, goalkeeper saves/concessions, and match enter/exit.

The images above derive from my son’s first five minutes in a recent match—at, the visuals confirm, right wing—and I logged his play while watching a video recording on my desktop. I found it difficult to keep up (or tap/click properly) when the action got fierce, though had fewer issues when dialing the playback speed down to 1.5x. The Python script that plots the heat and lines maps includes an option to statistically jitter x, y coordinates to account for fat thumbs and manic tapping when the give-n-go passes are rolling.

Techniques

As with earlier version, the web app is structured with HTML, CSS, and JavaScript, with the painful part getting the event category overlay to fit nicely on the three different device displays in my household. An if/else statement in the js file monitors the “categorize events” checkbox and accordingly blocks the overlay (or not), and the data storage and csv export rely on a Blob function.

It took some fiddling with nameservers, GitHub, and the DigitalOcean cloud hosting service —and $12—but I secured matchlogger.com and established what I hope is a logical local staging->GitHub commit/push->matchlogger.com workflow for version tracking and future updates.

As for my match_mapper.py Python script and the data visualizations, matplotlib and seaborn libraries continue to do the heavy lifting, and ChatGPT helped me every step of the way with the “lines map” function that, in order to get the effect I wanted, needed to (i) use timestamps to create individual line segments between each successive pair of x, y coordinates and then (ii) apply my custom colormap across all segments as if it were a single line. ChatGPT also took some of the grunt work out of coding the dictionary of event types needed for the “heat+event map” function and corresponding legend file.

Finally, I still can’t settle on color schemes: