The Right Format for Every Job: GPS Files in Real Life

Every geographic file arrives with a pedigree, and the pedigree tells you what it will survive. The KML from a friend's Google My Maps trip carries names, descriptions and the folder structure of memory — but treat its styling as decoration, because converters may drop it. The GPX from your bike computer carries timestamps and elevation point by point. The GeoJSON from a colleague carries data — properties, categories, the raw material of analysis. Knowing what each format does well tells you what each conversion can cost.

My three-step intake ritual

• Open it locally and read the validation line before anything else — feature counts by type, bounding box, and a glance at three random property rows.
• Check the bounding box carefully: a planet-spanning box can mean one corrupt vertex; a box in the wrong ocean can mean swapped columns.
• Only then convert, and note any expected loss: for example, polygons represented as boundary tracks or styling that does not survive the target format.

The ritual exists because the failure modes are consistent. A KMZ that 'won't open' is a ZIP archive containing KML and possibly other assets. A CSV map of the wrong hemisphere is often a lat/lng swap, visible quickly on the map and hard to spot in a spreadsheet. A noisy GPX elevation profile can also reflect a rough GPS fix rather than broken arithmetic.

And keep the originals. Conversions can be lossy; originals are your audit trail. The day someone asks 'but what did the file actually say?', the person holding the untouched source can answer. That is the point of data hygiene — and local browser processing helps because you choose what leaves your machine.

Treat every incoming file as untrusted until you inspect it

A geographic file can be perfectly valid XML or JSON and still be wrong for your project. The classic failures are not dramatic parse errors; they are quiet mistakes such as one swapped coordinate, a track recorded in the wrong time zone, elevation in unexpected units, or a polygon that crosses the antimeridian and makes the bounding box look enormous. That is why visual inspection belongs at the start of the workflow, not the end.

Open GPX in the GPX Viewer, KML in the KML Viewer, or GeoJSON in the GeoJSON Viewer before editing anything. A map preview plus feature counts will catch a surprising amount of bad input.

Keep an untouched original and create working copies

The original file is evidence. Rename it with the date and source if necessary, then stop editing it. Make conversions and cleanup changes on copies. This sounds overly cautious for a weekend GPX track, but the habit scales well when files become client deliverables, field data or research inputs. When somebody asks which values came from the source and which were changed later, you have an answer.

Timestamps are easy to break because they look simple

A track can contain UTC timestamps while the app that recorded it displays local time. If you shift or strip timestamps without understanding the source, speed and duration calculations can become nonsense. Daylight saving transitions add another trap: two local-looking times can be ambiguous on the night the clocks move back. For analysis, preserve absolute timestamps when possible and convert only for display.

Elevation needs its own sanity check

GPX elevation may come from a barometric sensor, satellite-derived height, a digital elevation model or a mixture depending on the device and app. Sharp one-point spikes are often measurement noise rather than cliffs. Before computing ascent, inspect the profile and ask whether the data source justifies the precision being reported.

Use the GPX Route Stats or elevation-related tools after inspecting the shape of the data. A summary is only trustworthy when the underlying points make sense.

CSV is often the bridge between mapping and ordinary office work

Teams frequently receive geographic data as a spreadsheet rather than a dedicated GIS format. A CSV can be excellent for attributes and manual review, but it has no universal geographic schema. One file may use lat/lon, another latitude/longitude, another separate eastings and northings. Before mapping, identify the coordinate columns and confirm their order and units.

The CSV to Map tool is useful for visual validation, and the CSV Coordinate Validator helps catch range and formatting issues before those rows are imported elsewhere.

Write down what the conversion was supposed to preserve

• Geometry: points, tracks, routes or polygons.
• Identity: names, IDs and labels used to match records later.
• Time: timestamps and time-zone assumptions.
• Vertical data: elevation and its source or units.
• Styling: icons, colors and folders if presentation matters.
• Custom fields: device or project-specific extensions that generic converters may drop.

That list becomes the acceptance test. A conversion that opens successfully but loses the one field your workflow needs is still a failed conversion. Treating map files like ordinary data rather than mysterious blobs makes the entire process more predictable.