TCX naar KML omzetten

Een TCX is dicht. Elke seconde van een sessie legt hij een positie vast, een hoogte, een lopende afstand, een hartslag, vaak een cadans en een vermogensgetal, gegroepeerd in ronden die elk hun eigen duur, afstand, calorietotaal en hartslaggemiddelden verklaren. Het is het informatierijkste bestand dat de meeste sporters ooit bezitten.

Een KML LineString is een lijst coördinaten. Dat is de hele bestemming, en de omzetting is dus geen vertaling maar een reductie: één stroom van de acht of negen overleeft, en de structuur eromheen niet. Gedaan om de juiste reden — je wilt de vallei zien waar de klim doorheen ging, of een route laten zien aan iemand die er nooit is geweest — is dat precies de juiste hoeveelheid data. Gedaan in de overtuiging dat een Google Earth-bestand een draagbare kopie van een training is, gooit het de training weg.

Per trackpunt: `<HeartRateBpm>`, `<Cadence>`, `<DistanceMeters>` en het `<Extensions>`-blok dat watt en looppas draagt. Per ronde: de totale tijd, de afstand, de maximumsnelheid, de calorieën, het gemiddelde en maximale hartslag, de intensiteit en de triggermethode. Per activiteit: de rondeverdeling zelf en elk blok dat het toestel noemt dat de opname maakte.

Wat wel overkomt is de positie van elk punt en zijn `<AltitudeMeters>`, wat de derde waarde van de coördinaat wordt. De reden is structureel en geen kwestie van moeite: KML modelleert een tekening, en een tekening heeft geometrie en uiterlijk en geen begrip van een meting op een moment. Er is geen element dat een hartslag zou kunnen dragen, dus is er geen versie van deze omzetting die er een houdt.

De tijdstempels gaan ook mee, wat mensen meer verrast dan de sensordata. Een LineString slaat coördinaten op en verder niets, dus wordt de `<Time>` op elk TCX-trackpunt weggegooid en legt de KML vast waar de lijn heenging zonder vast te leggen wanneer een deel ervan bereikt werd.

Het zichtbare gevolg in Google Earth is dat de tijdschuif — het bedieningselement waarmee je door een track kunt scrollen en hem zichzelf ziet tekenen — niet verschijnt voor het bestand. Die animatie wordt aangestuurd door een `gx:Track`-element met parallelle `<when>`-waarden, en deze omzetting schrijft een gewone LineString. Was het herbeleven van de sessie waar je op uit was, dan is de omzetting die tijd behoudt TCX naar GPX, en Google Earth opent een GPX rechtstreeks.

Wat Google Earth je geeft dat een tweedimensionale kaart niet doet, is reliëf. Kantel het beeld en de klim die je je als lang herinnert wordt een vorm met een helling, de afdaling heeft een muur aan één kant, en een parcours dat je nooit gereden hebt houdt op een abstractie te zijn. Voor een wedstrijdverslag, een verkenning, of uitleggen aan iemand waarom een stuk pijn deed, is dat echt nuttig en had niets van de weggegooide data geholpen.

De lijn wordt geschreven met een tessellatievlag aan, wat de renderer opdraagt elk segment te onderverdelen en de grond tussen hoekpunten te volgen. Zonder die vlag gaat een recht segment over een vallei onder het oppervlak door en verdwijnt de track in de heuvel — de mislukking oogt als een kapot bestand en is een renderartefact. Mét de vlag aan blijft de route over zijn hele lengte zichtbaar, wat de enige manier is waarop de terreinweergave de moeite waard is.

Elke coördinaat is een drietal, en de derde waarde draagt de hoogte uit `<AltitudeMeters>` in meters. Het hoogteprofiel van de sessie is dus aanwezig in de KML, en software die het als data leest zal het vinden.

Google Earth tekent het niet, omdat geen `<altitudeMode>` verklaard wordt en de standaard is de lijn aan het terrein vast te klemmen. Voor een GPS-track is die standaard juist: barometrische en satellietsatelliethoogte dwalen allebei tientallen meters, en een lijn die rafelig boven een rug zweeft oogt als een fout en niet als een meting. `<altitudeMode>absolute</altitudeMode>` met de hand toevoegen aan de LineString tilt hem de lucht in als je wilt zien hoe erg de ontvanger dreef, wat af en toe leerzaam is en nooit vleiend.

Een trackpunt zonder `<Position>` kan geen coördinaat worden en valt weg. Horloges blijven hartslag bemonsteren door tunnels, onderdoorgangen en parkeergarages, dus die stukken bestaan in de TCX als geldige punten met een tijd en geen locatie — en in de KML bestaan ze als niets.

Op de globe verschijnt dat als een rechte lijn tussen de laatste fix voor de belemmering en de eerste erna, dwars over wat er ook tussenin ligt. Het is geen corruptie en er is niets te herstellen; het bestand heeft de tussenliggende posities nooit gehad. Een indoor-sessie, waar geen enkel punt een fix heeft, levert geen geometrie op en de omzetting meldt dat er geen track of waypoints gevonden zijn, wat de correcte beschrijving is van een training die nergens heenging.

Elke activiteit wordt één Placemark, en de naam komt uit het `Sport`-attribuut — beperkt door het TCX-schema tot een korte lijst, dus in de praktijk `Running`, `Biking` of `Other`. Dat is wat er in de zijbalk van Google Earth verschijnt.

De titel die je de sessie in Garmin Connect of Strava gaf, hoort bij de database van dat platform en maakt geen deel uit van de export, dus kan hij niet worden overgedragen. Komen meerdere sessies in hetzelfde Earth-project terecht, dan wordt de zijbalk een kolom identieke woorden, en het `<name>`-element in de KML achteraf hernoemen is de oplossing — een bewerking van één regel per placemark, en het bestand is bewust platte tekst zodat zulke bewerkingen triviaal zijn.

Rondegrenzen worden platgeslagen tot één doorlopende lijn. Een KML-placemark kent geen begrip van een onderverdeling binnen een lijn, dus leveren twaalf intervallen en één gelijkmatige inspanning visueel identieke geometrie op, en niets op de kaart markeert waar een herhaling begon of eindigde.

Is het doel van het tonen van de route om de structuur van de training uit te leggen, dan moet dat op een andere manier — losse placemarks met de hand getekend in Google Earth, of aantekeningen achteraf toegevoegd. De TCX splitsen in één activiteit per interval voordat je omzet, geeft losse lijnen, maar de moeite die dat kost is meestal groter dan gewoon zeggen welk deel van de kaart het zware stuk was.

Hetzelfde geldt voor alles wat het bestand nog wist en de kaart niet. Waar de wind draaide, waar de groep splitste, waar de pech gebeurde: niets daarvan zit in een lijn gecodeerd, en Google Earth biedt geen manier om het af te leiden. Een placemark neergezet op de plek met twee regels omschrijving doet meer voor een lezer dan welke hoeveelheid geometrie ook, en het kost een paar seconden zodra het bestand al open staat.

Gemeten op een track van 7.200 punten met tijd en hoogte, kwam een TCX in deze vorm uit op ongeveer 2,2 MB en de bijbehorende KML op ongeveer 258 KB — ruwweg 315 bytes per trackpunt tegen 36 voor een coördinaat. Een echte Garmin-export met hartslag en cadans op elk punt is nog groter, dus is de krimp in de praktijk meestal meer dan een factor acht.

Niets daarvan is compressie, en het als efficiëntie lezen zou de verkeerde conclusie zijn. Het is een vrij directe meting van wat het bestand niet meer bevat: de tagnamen, de tijdstempels en de sensorwaarden. Is het kleinere bestand wat je wilde, prima — bewaar dan de TCX, want de KML kan niet worden teruggezet.

De TCX wordt gelezen en de KML geschreven in dit browsertabblad. Geen verzoek draagt het bestand ergens naartoe, wat het netwerkpaneel bevestigt terwijl een omzetting draait, en de pagina werkt met de verbinding uit zodra hij geladen is.

Het bestand dat omgezet wordt is gezondheidsdata en locatiedata in één document — hartslag tegen tijd, positie tegen tijd, meestal beginnend bij de voordeur van de sporter. De uitvoer is minder blootstellend, want de sensorstromen en de klok zijn weg, maar de route tekent nog steeds een leven. De kaart lokaal maken betekent dat het rijkere origineel nooit vertrekt op weg naar het armere plaatje.