Open most GPX files and you get a line on a map: a list of points, each with a latitude, a longitude, and usually an elevation. That is the track. It is enough to draw the route and read off the distance and climbing, and for most planning it is all you need.
But a GPX file can carry a lot more than a line, and some do. A track exported for turn-by-turn navigation quietly embeds the directions themselves: which way to turn, where your planned stops are, even whether the surface underfoot is paved or not. The catch is that almost every tool throws that away the moment it opens the file. PitStopper used to as well. Now it keeps it.
The navigation is inside the track
Here is the part that surprises people. In a normal GPX file, anything "extra" - a marked stop, a note - lives in a waypoint (<wpt>), a separate object from the track. (If those terms are new, our anatomy of a GPX file walks through tracks, routes and waypoints and how they differ.) Turn-by-turn navigation tracks do something different: they hang the navigation off the trackpoints (<trkpt>) themselves. Every point that matters carries its own little payload.
A single trackpoint from one of these files looks like this:
<trkpt lat="50.78627" lon="4.10874">
<ele>47.73</ele>
<time>2026-07-26T16:50:02Z</time>
<sym>pass_place</sym>
<type>via</type>
<name>Staf</name>
<extensions>
<xsi:gpx>
<route_information>unpaved</route_information>
</xsi:gpx>
</extensions>
</trkpt>
Nothing there is exotic on its own - it is all valid GPX 1.1 - but taken together it is a complete navigation instruction pinned to a spot on the road. The rule the format follows is simple: a trackpoint that carries a recognised <sym> is promoted from an ordinary point into a navigation instruction. Three kinds of thing end up mixed in among the plain points:
- Turn cues. A
<sym>ofleft,right,left_slight,right_sharp,keep_left,straightand so on. Read in order down the track, they are your route sheet: turn left, turn left, keep right, turn right. - Viapoints. A
<type>ofvia, usually with a<name>- the stops you deliberately set when you planned the route ("Staf", "Den ijzeren man"), and announced by the app as you reach them. Alongside them sitshapingpoints (<type>shaping</type>), which nudge the router along a road you wanted but pass silently, with no announcement. - Surface and speed. An
<extensions>block with values likeroute_information(paved or unpaved) andmax_speed, describing the segment you are on.
One quirk worth calling out: the extension wrapper is <xsi:gpx>. The xsi prefix normally belongs to XML Schema, so this is a slightly unusual reuse of it as a generic "extra stuff" container. It is harmless - GPX explicitly allows any namespaced content inside <extensions> - and any app that does not recognise it simply skips over it. That is the whole trick: these files stay perfectly valid ordinary GPX, so a tool that only wants the line still gets the line.
Who makes these, and who reads them
This is a small, specific world, and an informal one. The convention is not an official part of the GPX standard - it was worked out and written up by the outdoor-navigation community on the Locus Map forum, where it has been documented and refined since 2017. It is best thought of as an agreed-upon experiment that a few tools chose to support.
The tracks are typically produced by BRouter, the open-source cycle and walking router, using its "Locus new style" export. BRouter works out the turns from the OpenStreetMap road network and writes them into the track as it builds the route. (It does not add street names to the instructions, unlike some routers - so you will see "Turn right" rather than "Turn right onto Bosstraat".)
On the reading side, the two apps that understand them best are Cruiser (a desktop map viewer for Windows, macOS and Linux) and Locus Map (a popular Android outdoor navigation app). They detect a navigation track by a recognised symbol on its very first point, then present the data as a turn-by-turn list and as markers on the map. A handful of other apps read parts of it; most do not read it at all.
That narrowness is the important caveat, and it is why PitStopper is careful to say so wherever these features show up: this is a niche GPX extension, read by only a few programs. If you export one of these files and load it into Garmin Connect, Komoot or Strava, the line will be there and the navigation will not. We would rather you knew that before you sent the file to a friend.
What they are actually good for
If you do use Cruiser or Locus, the payoff is real:
- Turn-by-turn on the device. The route talks you through the junctions without you having to memorise them or stare at the map at every fork - useful on a fast descent or a fiddly urban stretch.
- Your stops travel with the route. The viapoints are the places you meant to stop. They stay attached to the file, so the plan you made at your desk is the plan on your handlebars.
- Surface awareness. Knowing a segment is unpaved before you commit to it matters a lot on 32 mm tyres, and it is right there in the data.
What PitStopper does with them
PitStopper is a planning tool, not a navigation app. Its job is to help you find water, food, fuel and the rest along a route. So the question was: when someone loads one of these rich navigation tracks to scout their stops, what should happen to all that embedded navigation?
The old answer was "it disappears", because we imported tracks the usual way - through a converter that keeps latitude, longitude and elevation and drops everything else. Re-export the file and the navigation was gone. For anyone actually navigating with Cruiser or Locus, that quietly broke their route.
The new answer is: we keep what the file already holds. On import, if a track carries this kind of data, PitStopper sets the flattened line aside for its own charts and distances but also holds on to the untouched track in full. When you export, that original track is written back byte-for-byte, so a round-tripped file is still a working navigation track - every turn cue, every viapoint, every surface note in place. And it is not only the track: extensions hung off the file itself, off the metadata, or off any waypoints are kept and re-emitted too - right down to tags we do not recognise. (We also tightened our exporter so the whole file validates cleanly against the GPX 1.1 schema, extensions and all.)
It tells you the moment you import. Drop a navigation track on the front page and the import summary leads with a short note: what was found (viapoints, turn cues, surface), and a plain promise that PitStopper keeps it and re-exports it unchanged.
Keeping the data is one thing; we also surface it, so you can see what you are carrying.
The named stops become map pins. Each viapoint shows as a marker you can click for its name, distance along the route and surface.
Everything lives in one view. Under View > Navigation data (or a button on the map) is a tabbed panel. Turn-by-turn reads out the whole route sheet the way Cruiser does, viapoints slotted in where they fall. Viapoints lists just the named stops. Surface breaks the route into paved and unpaved sections. And the footer is honest about the rest - it names any extension data we keep but do not draw (max speed, custom colours) and reminds you it all re-exports unchanged.
And the surface can colour the line. Flip a switch and the route is painted the way Cruiser paints it - blue for paved, orange for unpaved, grey where the file does not say. Because a preserved track's shape never changes in PitStopper, the colours always line up.
We deliberately do not scatter a marker on every one of the dozens of turn points; that would bury the map. The stops go on the map because they are where you might pause; the turns go in a list because that is how you read a route sheet.
Where PitStopper earns its keep
A navigation track tells you which way to turn. It does not tell you where the next tap is, which village has a cafe open on a Sunday, or where to fill a bottle before a long dry stretch. That is exactly what PitStopper is for, and it is unchanged by any of this.
So the two halves fit together rather nicely. Bring in a BRouter or Cruiser track and you already have the turns; point PitStopper at it, search, and you get the water, food, fuel and shelter strung along the same line - dozens of categories, straight from OpenStreetMap. Add the ones you want as waypoints, and they leave in the same GPX alongside the navigation you arrived with. The turn-by-turn gets you round the corners; the POIs decide where you stop.
Here it is on the same Den ijzeren man track. The line still carries everything the file arrived with - painted by surface, blue turn arrows at every junction - and now PitStopper's finds sit on top: the pins are POIs it pulled from OpenStreetMap along the route, one open to show a bus stop 77m off the track, 6.67km in. The navigation and the stops share one map, and one exported file.
That is the pairing worth spelling out: these navigation extensions are not a reason to plan your stops somewhere else. The nav track knows the way; PitStopper knows what is along it. Together they are a more complete plan than either on its own.
The one trade-off: editing
There is a limit, and it is worth being precise about, because it is easy to describe wrongly. The turn cues are not pinned to the track by position - there is no fragile "the turn at point 214" arrangement that a reshuffle would break. Each cue is carried inside its own trackpoint, as part of that point's data. Leave a trackpoint alone and its instruction rides along with it, untouched, wherever it ends up in the file.
The catch is in how PitStopper edits. To draw the elevation chart, measure distances and let you drag the line, it works from a flattened copy of the track - just the coordinates. Those embedded cues are not in that flattened copy; they live in the original track, which PitStopper keeps verbatim alongside it. When you reshape the line, PitStopper rebuilds the track from the flattened copy and re-snaps the changed part to the road network - and that rebuilt track has no cues to carry across, so the navigation is dropped.
That is a limit of how PitStopper does the edit today, not of the format itself. Because the cues live in the points, and the router PitStopper edits with (BRouter) can work out the turns for a new stretch of road, keeping the untouched cues and regenerating the ones for an edited section is feasible - something we may add later.
Either way, PitStopper treats editing as a deliberate choice. Start editing a track that still carries navigation data and it asks first: editing will drop the embedded cues, continue? Say no and the track, and its navigation, is left untouched. Say yes and it becomes an ordinary track from that point on. Nothing vanishes without you choosing it.
The bigger point
GPX is often treated as a lowest-common-denominator format: a line, and not much else. It is actually richer than that, and different tools have quietly agreed on ways to carry more. The trouble is that "carry more" only works if the tools in the middle do not throw the extra away. A planning step should not silently strip the navigation out of a navigation file.
That is the principle we settled on: retain what the file already holds. If you brought turn-by-turn directions into PitStopper, they should leave with you.
The GPX navigation-track convention is documented and maintained by the outdoor-navigation community on the Locus Map forum (since 2017). Routing by BRouter; reading and on-device navigation by Cruiser and Locus Map. Track and structure examples from a Cruiser-exported GPX.
