How to import a GPX file into QGIS

The short answer

In QGIS, go to Layer, then Add Layer, then Add Vector Layer, and browse to the .gpx file — or just drag the file onto the map canvas, which does the same thing. QGIS then shows a list of sublayers held inside that one file: waypoints, routes, route_points, tracks and track_points. For a hike recorded by a GPS app, the one to pick is tracks, which loads the walk as a single connected line, or track_points, which loads every recorded point separately with its own row of data.

Nothing about this needs a plugin or a file conversion. The GPX reader is built into QGIS, using the same underlying driver that reads dozens of other geographic formats, and a GPX file is a small enough piece of XML that even a long multi-hour recording opens close to instantly.

Why one file turns into five layers

A vector layer in QGIS, like in most GIS software, is built around a single kind of geometry — a table of points, or a table of lines, but not a mix of both sitting in one dataset. A GPX file does not respect that boundary at all: it can hold a list of standalone waypoints, one or more planned routes, and one or more recorded tracks, all inside the same file, and waypoints are points while tracks are lines. Rather than guess which of those you meant, or silently merge fundamentally different kinds of data into one confusing table, QGIS lists every kind it found and lets you load whichever one is actually relevant.

This is the same split covered in the guide to GPX tracks versus routes and the one on waypoints versus track points — QGIS is not inventing a new distinction here, it is just surfacing the one that was already sitting inside the file.

Picking the right layer for a recorded hike

tracks — the walk as one line

This layer holds one feature per <trk> in the file, drawn as a connected line running through every recorded point in order. For a single hike this is normally one line, the same shape you would see on a map inside a hiking app. Its attribute table carries track-level information — a name, sometimes a description — not a row for every individual point, because the whole line is a single feature.

track_points — every recorded point, on its own

This layer holds one feature per recorded point instead of one feature for the whole line, and each row keeps whatever the GPX file stored for that point — latitude, longitude, elevation, and a timestamp, if the original recording included them. This is the layer to use for anything that needs the individual readings rather than the shape: pulling elevation into a chart of your own, checking the time between two specific points, or filtering the recording down to one stretch.

waypoints and routes

These two exist in the same file list but rarely apply to a recorded hike. Waypoints are standalone marked locations, not a continuous recording, and routes are a planned sequence of stops rather than a trace of where someone actually went. A GPX file exported from a hiking app is built almost entirely from a track, so these layers usually come through empty or hold only a handful of points, if anything.

What comes across, and what does not

Position and, where the file has it, elevation and time all survive the import intact — QGIS does not round or discard anything the format itself carried. Elevation and per-point timestamps specifically live on the track_points layer, not on tracks, since a single line feature has no way to hold a different value at every vertex along it. Anyone who has opened the tracks layer expecting to see a time column and found the table nearly empty has usually loaded the line instead of the points by mistake.

What never comes across, regardless of which layer gets picked, is anything the GPX format itself has no field for. Photos, video clips and voice notes captured along a walk are separate files, not entries inside the GPX — the format only ever carries coordinates, elevation and timestamps. Bringing a hike into QGIS gets you the geometry and the numbers behind it, not the record of what the walk actually looked or sounded like along the way.

Things that trip people up

• Loading the tracks layer and finding no elevation or time in the attribute table — that data sits on track_points instead, since a whole-line feature cannot carry a different value at every point.
• A track that looks broken into several disconnected pieces — this usually means the original GPX had more than one track segment, often from a pause during recording, and QGIS is drawing each segment faithfully rather than joining them into a single unbroken line.
• Elevation values that look off by a large, consistent amount — check whether the source file stored elevation in metres or feet; QGIS displays exactly what is in the file and does no unit conversion of its own.
• Only a handful of scattered points appear where a full hike was expected — this is what happens when the waypoints or route_points layer gets picked instead of tracks or track_points, which holds a completely different, much sparser kind of data.

Where TrailCam fits in

TrailCam records a hike, walk or ride on an iPhone as a continuous GPS track, and exports it as GPX 1.1 — a single route or the whole history at once — or as a CSV summary. That GPX file is what a tool like QGIS is built to read, for anyone who wants to go past a map and a set of totals into custom analysis or a hand-built map of their own. The app itself already reports distance, moving time, pace and elevation gain, and replays the route with any photos, clips and voice notes pinned along it, for everything short of that kind of GIS work. Export is part of the optional TrailCam Pro upgrade; the app itself is free to download.