Beyond the core
Extensions let another schema add information without changing GPX itself.
GPX 1.1 defines a compact set of common fields for geographic exchange. The <extensions> element is its escape hatch for information that is useful to one device or service but absent from the core standard.
The official schema allows elements from another XML namespace inside that container. A namespace identifies who defines those added element names and prevents them from being mistaken for standard GPX fields. An exporter might use extensions for sensor readings, display styling, activity categories or application-specific route details.
Extensions can appear in several places, including the document, metadata, a waypoint or track point, a route, a track and a track segment. Their location helps associate the added data with the correct GPX object.
The important boundary
A valid extension is not automatically portable.
Standard GPX fields have shared definitions. A receiving app knows that <trkpt> is a track point and <ele> is elevation in metres because the GPX schema says so. An extension gets its meaning from a different schema or the documentation of its creator.
- Recognised extensionThe importer understands the namespace and can use the additional value as intended.
- Unknown extensionThe importer may retain or ignore the added element while still reading the standard route geometry.
- Missing definitionA plausible element name does not establish units, allowed values or semantics. The defining documentation is needed.
- Extension-only featureIf a capability exists only in proprietary data, it may disappear when the file moves to software that reads core GPX alone.
The GPX schema uses lax processing for extension contents. This allows a document to carry an extension even when the extension schema is unavailable to the validator. It does not certify that every extension value is correct.
Across an export
Conversion often preserves the line before it preserves the extras.
A service can import standard coordinates and then write a fresh GPX file using only the fields it supports. The result may still draw the same route while losing heart-rate samples, course-point categories, colour choices or other extension data.
The reverse can also happen. Two files may have identical core track points but different extension blocks, so one service shows more metrics than another. Comparing file size alone does not reveal whether the extra bytes are useful, redundant or simply verbose XML.
Portability is strongest in the shared GPX core. Extension data travels only as far as receiving software understands it.
A practical reading
Follow the namespace before guessing at the field name.
- Locate
Find each
<extensions>container.Note whether it belongs to the whole file, a route, a track, a segment or an individual point.
- Identify
Read the prefix and namespace declaration.
The namespace URI, not a short prefix chosen by the file, identifies the extension vocabulary.
- Verify
Use the creator's schema or documentation.
Do not infer units or meaning from labels such as speed, temperature or category.
- Test
Compare the original and exported copy.
If the extra data matters, confirm that it survives the exact handoff you intend to use.
Sources & scope
What this answer is based on.
The sources define GPX extension containers, lax processing and XML namespaces. The meaning of any particular extension must come from its own schema or publisher.