GPX, as free flight actually uses it.

GPX — the GPS Exchange Format — is an XML schema published by Topografix in 2004 and supported by essentially everything: watches, phones, mapping sites, flight instruments. That universality is why free-flight tools read and write it, and the reason to be precise about which subset you mean.

A GPX file can hold three different kinds of point collection, and a file can hold all three at once:

GPX is not a flight-log format for our purposes. A GPX track is lossy compared with IGC — no pressure altitude, no recorder identity, no security record — which is why We-Fly ingests flights only as IGC and uses GPX purely for planning.

<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.1" creator="we-fly.cloud XC planner"
     xmlns="http://www.topografix.com/GPX/1/1">
  <metadata><name>Chabre out and return</name></metadata>
  <rte>
    <name>Chabre out and return</name>
    <rtept lat="44.278000" lon="5.635000"><ele>1320</ele><name>D01188</name></rtept>
    <rtept lat="44.285000" lon="5.740000"><ele>1834</ele><name>B02</name></rtept>
    <rtept lat="44.362000" lon="5.715000"><ele>1420</ele><name>B15</name></rtept>
    <rtept lat="44.319000" lon="5.826000"><ele>560</ele><name>A02</name></rtept>
  </rte>
</gpx>

1.0 vs 1.1

For the subset here they are nearly identical — wpt, rte, trk and their coordinate attributes are unchanged. The differences that can bite:

• 1.0 put file-level metadata directly on <gpx> (<name>, <desc>, <author>); 1.1 moved them into <metadata>. Look in both places.
• 1.0 had a fixed <url> / <urlname> pair; 1.1 replaced them with <link>.
• 1.1 added the <extensions> element, which is where every vendor now puts everything the schema does not cover.

GPX defines far more than this. These are the ones that survive a round trip through free-flight tools — everything else is either presentation or vendor-specific.

A file with a route, a track and waypoints is perfectly legal, and a route importer has to pick one. The precedence that matches what pilots expect:

• <rte> first. A route is a deliberate, ordered plan — if the file has one, that is the answer. Take the first route; ignore any others.
• Then <trk>. Concatenate every <trkseg> of the first track in document order. A track is ordered, so it makes a usable line.
• Then loose <wpt>. Last resort: use document order and hope it is meaningful. It usually is, because the tool that wrote them wrote them in order.
• Fall through all three with nothing usable → reject the file, naming all three containers in the error so the pilot knows what was looked for.

A waypoint-collection importer does something different and simpler: it reads <wpt> only, and takes every one of them. Route points are part of a line, not a database of places — pulling them into a waypoint collection would fill it with the same turnpoint under three different route names.

A competition waypoint has a short code (B61130, D01188) and a readable name. GPX gives a point only two text slots — <name> and a comment/description — so comp tools settled on a convention:

On import, promote <name> to a code when it looks like one — 2–8 alphanumeric characters with at least one digit — and the secondary slot holds something different. The digit requirement keeps ordinary short names (Goal, Home, Top) out of the code field.

<wpt lat="44.278000" lon="5.635000">
  <ele>1320</ele>
  <name>D01188</name>
  <cmt>Chabre launch</cmt>
  <desc>Chabre launch</desc>
</wpt>

Writing the same text into both <cmt> and <desc> is deliberate: different tools read different ones, and duplicating costs a few bytes rather than a lost name.

Shows what each container holds, which one a route importer would choose, and every point decoded. Parsed with the browser's XML parser — nothing is uploaded.

• lat/lon are attributes, <ele> is a child. And ele is metres, always — GPX has no unit attribute.
• Single elements are not arrays. One <wpt> collapses to an object in most XML-to-object libraries. Force-array wpt, rte, rtept, trk, trkseg, trkpt.
• Don't require the namespace. Real files omit it or carry the wrong one. Match local names.
• A track has many segments. Concatenating only the first <trkseg> silently truncates a file that was split at a signal gap.
• Elevation is optional and often absent, and a 0 is genuinely ambiguous — it can mean sea level or "the writer had nothing". Treat a missing <ele> as unknown; do not substitute zero.
• <extensions> is a free-for-all. Vendors put heart rate, air temperature and their own waypoint types in there. Never fail on unrecognised extension content.
• Strip the BOM. A leading U+FEFF from a desktop editor makes strict XML parsers reject an otherwise valid file.
• Validate coordinates. Latitude beyond ±90 or longitude beyond ±180 means swapped fields or a mis-detected format — reject the point rather than plotting it.

Everything is parsed in the browser; an imported route or collection is only stored when you explicitly save it. Files are written as GPX 1.1, six decimal places of coordinate precision (≈ 0.1 m), MIME type application/gpx+xml.

GPX is never accepted as a flight track. Every flight enters We-Fly as IGC — a GPX track has no pressure altitude and no security record, so accepting one would put unverifiable flights in the logbook next to verifiable ones.

The same collections also round-trip through the three .wpt dialects, KML and SeeYou .cup.