A Deterministic Spatial Representation Packet for Sports Trajectories Under Explicit Coordinate, Threshold, and Tolerance Assumptions

Imagine you are watching a video game character run through a forest. To a computer, that character isn't just "running"; it is a long list of numbers telling the screen exactly where the feet are at every single fraction of a second. In the real world, athletes wear special watches and sensors that do the same thing, recording their movements as a stream of data points. This field, called sports engineering, tries to turn those raw numbers into useful stories: "Did the player stop?" "Did they make a sharp turn?" "How fast were they going?"

But here is the tricky part: computers are very literal. If you ask a computer to find a "stop," it needs a very specific rule, like "speed must be under 1.5 meters per second for at least 2 seconds." If you don't write that rule down clearly, or if you forget to tell the computer what kind of map it's using (like whether it's measuring in miles or kilometers), the computer might find a "stop" that isn't really a stop, or miss one that is. The big question for scientists is: how can we make sure that when a computer says it found a pattern in an athlete's run, we know exactly what rules it used to find it, and that we can check its work later?

This paper introduces a clever new tool called a "Deterministic Spatial Representation Packet." Think of it as a super-detailed, unchangeable receipt for a sports analysis. Instead of just giving you the final answer (like "the player stopped 5 times"), this tool packages the answer along with the entire "recipe" used to cook it. It records every assumption, every threshold, and every tiny setting the computer used to turn raw GPS data into a list of events. The authors, working with two sample datasets—one from a skier and one from a runner—show that they can take messy, noisy movement data and convert it into a clean, auditable chain of evidence. They prove that if you write down your rules clearly, you can turn a jumble of coordinates into a "packet" of facts that anyone can inspect to see exactly how the conclusions were reached.

However, the authors are very careful to tell us what this tool doesn't do. It doesn't prove that the athlete actually stopped in real life, nor does it tell us if the sensor was perfectly accurate. It doesn't say, "This is the best way to coach a team." Instead, it acts like a transparent glass box: you can see the raw data go in, you can see the rules applied, and you can see the results come out. If the results look weird, you can look inside the box and say, "Ah, the computer found a 'turn' because the rule was set to 30 degrees, not 45." The study suggests that this level of transparency is crucial for sports engineering, allowing experts to trust the data they use without having to guess what hidden settings might have changed the outcome.

The "Receipt" for a Run

To understand why this paper matters, imagine you are a detective trying to solve a mystery about a runner's performance. You have a notebook full of scribbles (the raw data) and a final report saying, "The runner stopped 95 times." You want to know: Is that true? Did the runner actually stop, or did the computer just get confused?

In the past, getting the answer might have been like trying to read a receipt written in invisible ink. You'd see the total, but you wouldn't know what items were included, what tax rates were applied, or if the cashier made a typo. This paper builds a new kind of receipt. It takes the raw data from two athletes—a skier named "skiing_run_01" and a runner named "running_2026-04-09"—and runs them through a strict, step-by-step machine.

The machine starts by cleaning up the data. It noticed that the raw files had a lot of "ghost points"—places where the sensor recorded the exact same spot twice in a row. For the skier, almost half the data (48.9%) was just duplicate points. For the runner, it was even worse, with 68.6% of the data being duplicates. The machine removed these duplicates to create a "canonical" (or official) version of the path. It then projected the data from a global map (latitude and longitude) into a local, flat grid (East, North, Up) so that distances could be measured in meters, not degrees.

Once the data was clean and in the right format, the machine started looking for specific "events" using a set of rigid rules. It didn't guess; it followed a checklist.

• Stops: It looked for moments where the speed dropped below 1.5 meters per second and stayed there for at least 2.0 seconds.
• Turns: It looked for changes in direction greater than 30 degrees (0.5236 radians).
• Curves: It checked for tight curves where the path bent more than 0.1 radians per meter.

The result was a "packet" of artifacts. For the skier, the machine found 71 events, including 11 left turns and 1 stop. For the runner, it found 553 events, including 95 stops and 151 times the runner reversed direction. It also built a "symbolic graph," which is like a flowchart connecting all these events together.

The "Magic" of the Numbers

Here is where the paper gets really interesting, and where the "receipt" analogy shines. The runner's data produced a massive number of "topology candidates"—4,372 of them. These are events where the path crossed over itself or made a loop. A casual observer might think, "Wow, this runner crossed their own path 4,372 times!"

But the paper explicitly warns us not to take that number literally. The authors explain that this huge number is a result of the rules and the tolerance settings, not necessarily a reflection of reality. The machine was set to be extremely sensitive, looking for crossings with a tolerance of 1e-9 (a tiny, tiny distance). Because the runner's path was dense and self-crossing, the computer found thousands of tiny geometric overlaps. The paper clarifies that these are "tolerance-conditioned candidates," meaning they exist because the computer was told to look for them under very specific, strict conditions. They are not a count of "unique physical crossings" in the real world.

This is the core of the paper's contribution: it separates the artifact (the computer's finding) from the truth (what actually happened). The paper argues that we should treat these findings as "deterministic symbolic observations." In plain English, this means: "The computer found X because we told it to look for X using rule Y. It does not mean X is physically true in the way a human would see it."

Why This Matters (and What It Doesn't)

The authors are very humble about what they have achieved. They don't claim to have solved the problem of measuring athletes perfectly. They don't say their method is the "best" way to coach a team, and they don't claim their numbers are the final word on how fast a runner was. In fact, they explicitly rule out several things:

• They do not claim to fix sensor errors.
• They do not claim to know the "sport-specific meaning" of a turn (e.g., whether a turn was a tactical play or just a stumble).
• They do not claim their results work for every sport or every device without adjustment.

Instead, the paper suggests that the value lies in transparency. By packaging the data with its "coordinate contract" (the map rules), its "thresholds" (the speed limits), and its "tolerance" (how close is close enough), the authors create a system where anyone can audit the work. If a coach says, "The runner stopped too much," an analyst can open the packet and say, "Well, the computer found 95 stops because we set the rule to 1.5 m/s. If we change the rule to 2.0 m/s, the number drops to 40."

The study uses "staged sensitivity evidence" to show how fragile these numbers can be. They ran tests showing that if you change how the data is smoothed out, or if you fill in gaps differently, the number of "stops" or "turns" can change dramatically. This isn't a bug; it's a feature of the system. It tells us that these numbers are not absolute facts like the weight of a rock; they are conditional facts that depend entirely on the rules we set.

The Takeaway

In the end, this paper is a blueprint for honesty in sports data. It proposes a way to turn a messy, noisy stream of GPS points into a clean, inspectable "packet" that tells you exactly what the computer saw and exactly what rules it used to see it. It doesn't tell you who won the race, but it gives you the tools to understand exactly how the race was measured.

The authors demonstrate this with two samples: a skier with 338 clean points and a runner with 871 clean points. They show that with these samples, they can generate a complete chain of evidence, from the raw coordinates to the final graph of events. They admit that their method is just a "representation layer"—a middle step between raw data and final analysis. But by making the assumptions explicit, they hope to prevent the kind of confusion that happens when people treat computer-generated numbers as if they were unchangeable physical truths.

The paper concludes that finite sports trajectories can be converted into inspectable, deterministic artifacts, but only if we stop hiding the assumptions. We have to be willing to say, "This is what we assumed, this is the rule we used, and this is what the computer found." It's a call for sports engineers to stop guessing and start documenting, ensuring that every "stop," "turn," or "loop" in the data comes with its own little receipt, ready for inspection.