GPX is a well-liked XML format for operating or biking tracks with geocoordinates. It is a how-to for cleansing up a GPX file by eradicating undesirable or privacy-sensitive data.
Many apps that report exercise routes and might export them as GPX information embrace extra knowledge than the plain GPS coordinates. For example, a GPX file from my favourite recording app, Guru Maps, appears to be like like this:
<?xml model="1.0" encoding="utf-8"?>
<gpx model="1.1" creator="Guru Maps/4.5.2"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.topografix.com/GPX/1/1"
xmlns:gom="https://gurumaps.app/gpx/v2"
xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd https://gurumaps.app/gpx/v2 https://gurumaps.app/gpx/v2/schema.xsd">
<trk>
<identify>Barnimer Dörferweg</identify>
<kind>TrackStyle_FF7F00C8</kind>
<trkseg>
<trkpt lat="52.6254614634" lon="13.4092010169">
<ele>54.238586451</ele>
<time>2020-05-10T05:30:38.997Z</time>
<hdop>4.6875</hdop>
<vdop>3.375</vdop>
<extensions>
<gom:pace>5.5661926282</gom:pace>
<gom:course>329.1938658731</gom:course>
</extensions>
</trkpt>
…
<!-- hundreds of monitor factors -->
This monitor consists of the next properties for every monitor level:
- Geocoordinates (latitude and longitude)
- Elevation
- Timestamp
- Horizontal and vertical dilution of precision (hdop/vdop)
- Present pace
- Present course/heading
Plus, Guru Maps makes use of the monitor’s <kind>
attribute to encode the colour of the monitor as displayed within the app in a non-standardized format (TrackStyle_FF7F00C8
).
Some apps additionally embrace coronary heart price or different health measurements.
All this knowledge is beneficial for archiving tracks or importing them into one other app. However earlier than sharing this monitor publicly, I’d need to clear the info up first:
- The one actually necessary items of data are the coordinates and presumably the elevation.
- Timestamps are non-public knowledge. I don’t need to share these.
- The opposite measurements are largely irrelevant.
GPX information can turn out to be fairly giant (hundreds of monitor factors is widespread), so decreasing the quantity of information can be good for file sizes and parsing efficiency.
Necessities
-
XmlStarlet
I take advantage of Xml to do many of the XML processing. On macOS, you possibly can set up XMLStarlet by way of Homebrew:
-
xmllint
One non-compulsory processing step makes use of xmllint, which comes preinstalled on macOS.
-
XSLT file for eradicating unused namespaces
Lastly, obtain this XSLT file
remove-unused-namespaces.xslt
, both from this Gist or from my server. We’re gonna use it in a single processing step to strip unused namespaces from the GPX file.Unique supply: Dimitre Novatchev on Stack Overflow.
Operating the command
Assuming your supply file is called enter.gpx
and the XSLT file you downloaded above is within the present listing, that is the complete command to course of the GPX file and save the outcome to output.gpx
:
xmlstarlet ed
-d "//_:extensions"
-d "/_:gpx/_:metadata/_:time"
-d "/_:gpx/_:trk/_:kind"
-d "//_:trkpt/_:time"
-d "//_:trkpt/_:hdop"
-d "//_:trkpt/_:vdop"
-d "//_:trkpt/_:pdop"
-u "/_:gpx/@creator" -v "Shell script"
enter.gpx
| xmlstarlet tr remove-unused-namespaces.xslt -
| xmlstarlet ed -u "/_:gpx/@xsi:schemaLocation" -v "http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"
| xmllint --c14n11 --pretty 2 -
> output.gpx
This sequence performs the next steps:
- Delete all
<extensions>
components. - Delete the timestamp from the file’s
<metadata>
part if current. - Delete the
<trk><kind>
component. - Delete the
<time>
,<hdop>
,<vdop>
, and<pdop>
components from all monitor factors. - Set the file’s
creator
attribute. - Now that extension fields are gone, take away all unused XML namespaces from the file header.
- Delete all
xsi:schemaLocation
entries besides the one for the GPX schema. -
Run the file by way of xmllint for formatting. The
--c14n11
choice performs XML Canonicalization (C14N). Amongst many different issues, canonicalization replaces numeric character entities within the XML with their regular Unicode characters, which is necessary for my use case.For instance, the textual content “Dörferweg” within the supply would turn out to be “Dörferweg”. I discovered that a number of the instruments I take advantage of insert non-ASCII characters as numeric codes and different instruments don’t show these accurately.
The processed GPX file appears to be like like this:
<gpx xmlns="http://www.topografix.com/GPX/1/1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
creator="Shell script" model="1.1"
xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">
<trk>
<identify>Barnimer Dörferweg</identify>
<trkseg>
<trkpt lat="52.6254614634" lon="13.4092010169">
<ele>54.238586451</ele>
</trkpt>
<trkpt lat="52.6255090307" lon="13.4091548326">
<ele>53.9600219977</ele>
</trkpt>
…
The processing steps above are those that work for me given the apps I take advantage of. Your mileage could differ in case your instruments add different knowledge to your GPX information. Be at liberty to edit the command accordingly. XmlStarlet makes use of XPath syntax to pick out which components to function on. The xmlstarlet sel
command is beneficial for inspecting a supply file and making an attempt out the required XPath incantations.
Validation
Lastly, it’s a good suggestion to validate the processed GPX file in opposition to the official GPX schema:
xmlstarlet val --quiet --err --xsd
http://www.topografix.com/GPX/1/1/gpx.xsd
output.gpx
Joyful processing!
PS: For those who’re ever in Berlin, it is a good lengthy bike route (55 km) with minimal automotive site visitors. Begins and ends at Hauptbahnhof. Obtain the (sanitized) GPX file.