My daughter has an orienteering competition almost every week. When she finishes, the result is already known: her place, her total time, the protocol. For me, that is only the start of the analysis. What I want to know is where exactly the time was lost, why it happened, and whether the same problem repeats from start to start.
I used to use another service for this. It showed some of the data, but I couldn't georeference the map properly, mark control points on it, or automatically cut a GPS track into splits. Most importantly, I couldn't upload a competition protocol and compare each leg with the other participants.
So I had plenty of data and no answer to a simple question: what exactly should she work on?
That is why I built a portal for analyzing orienteering. It has one more unusual property: an AI agent wrote all of its code. I never saw a single line of the source. I set tasks, opened the result in a browser, checked it on real competitions, and formulated the next task.
Three inputs that live in different worlds have to end up in one model:
scanned map (an image) → georeferenced map → digitized course (start, CPs, finish)
GPX track from the watch → cut into splits: start → CP1 → CP2 → … → finish
official race protocol → best time per leg → "Ideal Leader" benchmark
A quick glossary: a control point (CP) is a checkpoint on the course, and a split is the time for one leg between two consecutive CPs.
An orienteering map is essentially a photo or scan of a sheet with the course printed on it. A GPS track is in geographic coordinates. To combine them, the map has to be georeferenced.
In the portal I upload the image, then mark at least three corresponding points on the orienteering map and on an ordinary base map. Internally the portal uses an affine transformation, calculated from those reference points, to place the whole image. After that I click the start, every CP, and the finish on the image, and each click is converted into geographic coordinates.
The input was a picture. The output is a digital route with a sequence of CPs.
Left: the original scan. Middle: the overlay on the base map. Right: the sequence of control points. The interface is in Russian.
Once the portal knows the coordinates of every CP, a GPX upload doesn't need any manual explanation of where one leg ends and the next begins. For each control point, the portal looks for the place where the track passes closest to its coordinates, and cuts the track at those points: start → CP1, CP1 → CP2, and so on to the finish.
This is where raw GPS points become something you can treat as a sports result. Each leg has a start, an end, a time, the length of the actual track, and a pace.
GPS is not perfect. At some starts a point can drift, and the moment of passing a CP is not always detected correctly. So the portal keeps manual correction of the markers: the automation does most of the work, and a person fixes the places where the real data is messy.
The official protocol is what tells me how well or badly each individual section went. Importing protocols turned out to be less tidy than I wanted. There is no single format. Over time the portal learned to parse several sources and variants of HTML, JSON, and PDF, and then separate cases appeared: multi-day starts, relays, other competition formats. A change on an external website can still break a particular importer. That is the price of integrating with other people's formats.
After the import, the portal takes each split separately and finds the participant with the best time on it. Those results are assembled into a synthetic row I call the "Ideal Leader".
It is not a real athlete. One person may have been fastest on the first leg, another on the second, a third on the third. The Ideal Leader is put together from the best splits actually posted across the whole course.
I prefer this to comparing with the winner, who may have made a mistake somewhere too. Every leg gets a local reference: the best time anyone actually posted on it. In the protocol I can see at once where the gap is small and where the main loss happened. Good and problematic sections are colored, and every cell opens a detailed analysis of that split.
The "Ideal Leader" collects the best time on each leg from different participants. Athletes' names are hidden. The interface is in Russian.
At the level of the whole run, the portal only highlights good and bad splits. A red split does not mean the program knows the cause of a mistake. It means: this is a section worth looking into. That already narrows the search. If a run lasted over an hour, I don't have to hunt manually for the few interesting minutes.
Opening a specific split changes the screen. The portal cuts out only the part of the map that belongs to the selected leg and shows the actual GPS track plus a straight line between the two CPs. It also draws a pace chart for this leg only.
Take an example where the straight line between two controls is 300 meters and the actual track is 820. That alone does not prove a mistake: in orienteering you can't draw a straight line through a swamp, a fence, or an impassable area. But a gap like that immediately makes you look carefully at the route choice.
On this screen I can also record the cause of the problem.
One split: the map and track show the route choice, the chart shows the pace, and the AI coach gives a short analysis. The interface and the AI coach's reply are in Russian.
For the same split I can launch an AI assistant. It does not receive the whole competition database or a sentence like "the fifth control went badly." The portal prepares the context itself: a PNG of exactly the part of the map shown on screen, with the track and the control points, the numeric parameters of the split, and a prompt. Then Claude is launched through the CLI and has to look at the section, try to identify problems in how it was run, and give recommendations.
What interests me is the context preparation more than the button. The portal has already selected the split, discarded the rest of the course, and prepared the map, the pace, the distances, and the gap. The AI receives an almost ready-made statement of a specific problem.
I don't consider this part solved. The AI can offer an explanation and recommendations, but whether they actually help change the training process and reduce such losses at future starts is a different question. The portal has not proven that.
One bad split can be an accident. So the main screen doesn't look at one run. On the left, the portal keeps a queue of problem splits still worth analyzing: sections with a noticeable gap and low pace. On the right, the causes of the problems I have already analyzed accumulate.
That gives information of a different level: not "there was a mistake on the fifth split last Sunday," but "this type of problem repeats more often than the others."
For example, the top problem in the current data can turn out to be not a navigation error but "low pace without a mistake." That is a very different conversation. If someone chooses the route correctly, doesn't lose the map, and doesn't drift off course, but systematically loses on pace, the next training hypothesis is nothing like the one for constant direction errors.
Once enough splits are analyzed, individual notes turn into statistics of recurring causes. Athletes' names are hidden. The interface is in Russian.
I am a developer, but on this project I deliberately did not work as one in the usual sense. I did not open the source and did not do code review. My work looked different: I saw a problem in real use and set a task, the agent implemented it, and I opened the portal, loaded real data, went through the user scenario, and checked whether my problem was solved. If not, I formulated the next task.
That is how georeferencing, GPX splitting, protocol import, split comparison, the analysis card, error causes, the dashboard, and the AI assistant appeared, step by step.
My acceptance criterion was not the code but a working product. The technical side was not left completely unchecked: the repository has automated tests, and on the state of the project I checked, a full run gave 109 passed. But I evaluated the system from the outside, as a user who knows what result is needed.
If the agent takes over writing the code entirely, the main question is no longer "how do I implement this?" but "what should be implemented next?" The agent did not answer that for me.
The portal now turns an image of a map into a digital course, cuts the GPX into splits, pulls in the official protocol, builds the Ideal Leader, shows where time was lost, helps classify the cause, and collects statistics on recurring problems.
Right after that I ran into a question I had barely noticed at the start: what do I do with the problem once I've found it?
Say the portal shows the main recurring factor is low pace without a navigation error. We know that. But what training action follows from it? Or the AI looked at several problem splits and gave recommendations. How do I tell whether they are right? How do I turn them into a specific exercise? How do I check, a few weeks later, that this particular problem occurs less often?
I don't have a good answer yet. At first I thought the main job was to collect data and find mistakes. That part is increasingly automated, and the difficulty is moving further along: from diagnosis to changing behavior and the training process.
I also can't say the portal has made my daughter's results better. I don't have the data for that conclusion. What I can say is that instead of a general assessment of a result, my family now has a concrete conversation about specific sections of the course.
The portal is open source: orienteering on GitHub. The full case study is on my site: hram.github.io/en/articles/orienteering.