trailmap
The beauty of gravel is that there is an almost endless supply of new roads, trails and places to explore. It is hard to get bored, and great rides turn up in surprising places. Someone also thought to add gamification to the exploring — collecting tiles or roads instead of Pokémon. It works and it hooks you, but it often leads to a kind of riding that not everyone enjoys.
In this post I present an idea for a different kind of gravel game. It also produces a smarter gravel map, useful for all gravel route planning — but let's start with how the current games work.
If tile hunting or Wandrer are unfamiliar, the short version:
Two ways to gamify exploring: on the left the tile hunting grid, on the right Wandrer's "ride every road" road network.
The appeal of both is real. They give you a reason to head for new scenery and a bit further afield, they turn the dark winter season into something with a goal, and they reward you for filling in the map in a way that hooks you. For many they are exactly the spark that gets you to try something new instead of the usual route.
The problem is not in the execution but in what the game rewards. When the goal is coverage — every tile or every road — certain phenomena inevitably follow from the riding:
The end result may be that the flow disappears and riding turns into working through a checklist. These are not faults of the games but a direct consequence of what they reward. It has been written about well even in media that is otherwise full of praise for the games (links at the end).
What if the game rewarded riding that you would do anyway? The kind where the pace and the flow stay intact?
The idea is simple: the targets of the game are only ways that suit gravel well and are reachable via the road network (or via a short, slightly more awkward connecting trail). Not random tiles and not every city back street, but specifically the ways a gravel rider wants to ride: quiet gravel roads, recreational paths, ski trail beds and easy forest roads that link up into a route that flows.
So how do you identify ways like that? Not one at a time by hand, but automatically from the map data. Modern map data holds a surprising amount of information about every road and trail: surface, width, condition, and how the ways connect into a network. The app can read this and, with some inventive graph algorithms, pick out exactly the stretches that suit gravel and are genuinely rideable end to end — and discard the dead ends and the hike-a-bike sections.
The assumption is that these segments are ridden in full — and since the unsuitable stretches have already been weeded out, riding them in full is enjoyable rather than pushing your bike. Dead ends are not forced on you. At most you run into "islands" where you have to ride some shortish stretch back and forth — but that is a conscious compromise, not the rule.
This is quality before quantity: less to conquer per unit of area, but every target is worth riding and some of the new ways will end up becoming parts of your favourite routes.
The crucial thing is that the same engine — the same automatic gravel classification that reads the map data (more on this below) — produces two benefits at once:
This is not an idea plucked out of thin air. The foundation is OpenStreetMap (OSM) — an open map of the world maintained by volunteers together, a sort of Wikipedia of maps. Trailmap already has a "virtual" gravel classification that infers the rideability of each way from OSM data. That classification is exactly the engine that produces the viable gravel segments automatically — as long as the OSM data in the area is in order.
The idea resembles GravelMap, which also collects gravel segments. The difference is that GravelMap leans on proprietary data drawn by hand by users: coverage depends on volunteer effort, the data grows slowly and unevenly, quality is quite variable, the service barely develops and it has no route planning, for instance. (There is an apt piece on why a gravel map put together this way is not just a weakish solution but also closes the door on a smarter one.)
An OSM-based solution turns this around:
There is one more lovely side effect here. When the game is based on OSM data, it also motivates people to improve it: the player notices where data is missing or wrong, and fills it in. That benefits all users of OSM data, not just this game.
Gravel segments on the Trailmap app's map.
Finland's comprehensive MTB trail map came about in exactly this way — as the work of the community, trail by trail, over more than ten years, with astonishing results (I wrote about this separately in the OSM mapping 2025 post) — and for it the geospatial professionals' association ProGIS awarded the community and Trailmap an honourable mention. A game that steers mapping in a better direction would be a natural continuation of that story.
Even a good idea has its rough edges. The biggest compromise is quantity: because there are fewer targets than in tiles, and especially than in Wandrer, in many areas the nearest ways will sooner or later all have been ridden. After that you have to go further afield — everyday rides no longer cut it, and exploring takes weekends. The same phenomenon applies to traditional tile hunting too, of course.
And that is part of the appeal of Wandrer and Squadrats: they offer plenty to conquer close to home as well — with the familiar negative consequences described above.
There is, however, a partial solution to the quantity problem — a bit like the way smaller tiles (squadratinhos) bring more to conquer in tile hunting. The rules of the game can be adjustable. In the basic mode the targets are only pleasantly rideable gravel ways reachable with normal riding, with no dead ends. But every parameter can be tweaked: loosen the limits and rougher segments come into play, ones you might have to push your bike up a slightly awkward trail to reach, and with certain definitions dead ends too. That way the supply in your local area grows as well, once you are willing to take on more challenge. It is a conscious trade: more to conquer in exchange for less guaranteed gravel flow.
There are other open questions too: how to build a fair scoring system, and how much all of it leans on the quality of OSM data area by area.
For now this is an idea and a possible new app in the Trailmap family — and at the same time an opening for discussion. There is already a demo, though. Before I carry on building, I would like to know whether there is interest in something like this and what should be taken into account:
Tell me your thoughts in the "Trailmap Suomi" Facebook group or by email. I will take the idea forward based on the feedback.