TCX naar KMZ omzetten

Een TCX is voor de meeste mensen onopenbaar. Het heeft een extensie die niemand herkent, het is XML in plaats van iets dat een dubbelklik rendert, en de software die het correct leest is het trainingsplatform dat de ontvanger misschien niet gebruikt. Zo’n bestand naar een clubsecretaris of wedstrijdleider sturen levert een antwoord op met de vraag wat het is.

Een KMZ levert een wereldbol met een lijn erop op. Dat verschil — tussen een bestand dat uitgelegd moet worden en een dat opent — is de hele reden voor deze omzetting, en het is de moeite waard om helder te zijn dat het een presentatiebeslissing is en geen datakwestie. Er verbetert niets aan de route. Wat verandert is of de persoon aan de andere kant hem kan zien zonder dat iemand het uitlegt.

Gemeten op een sessie van 7.200 punten — twee uur op één sample per seconde, met tijd en hoogte — was de TCX zo’n 2,2 MB, de tussenliggende KML zo’n 258 KB, en de definitieve KMZ zo’n 47 KB. Dat is ruwweg 315 bytes per trackpunt teruggebracht tot minder dan zeven.

Twee losse effecten worden gestapeld en het is de moeite waard ze uit elkaar te houden. De eerste daling, bijna negen op een, is het trainingsbestand dat een tekening wordt: de uitgebreide `<Position>`-markup, de tijdstempels en de sensorelementen verdwijnen allemaal, en niets daarvan is herstelbaar. De tweede, vijf-en-een-half op een, is de deflate, en die is volledig omkeerbaar. Alleen de tweede is compressie, en het geheel compressie noemen zou suggereren dat het origineel er nog ergens in zit.

Hernoem de uitvoer naar `.zip` en open hem, en er verschijnt één enkel lid genaamd `doc.kml` aan de root van het archief. Die naam en die positie zijn wat elke KML-lezer als eerste zoekt, dus het bestand opent zonder terugvallogica.

Er zit verder niets in — geen afbeeldingenmap, geen iconen, geen tweede document, geen manifest. De meeste KMZ-bestanden die circuleren dragen bijlagen naast de KML, waarvoor het formaat is ontworpen; deze doet het smallere werk van één document naar één bestandsnaam comprimeren. Het maakt het archief ook triviaal controleerbaar: wil je exact weten wat je coach gaat zien, pak dan dat ene bestand uit en lees het.

Alles wat een trainingsplatform leest, ontbreekt. Hartslag, cadans, vermogen, de lopende afstand op elk punt, calorieën, de rondeverdeling en elk gemiddelde per ronde worden weggelaten, want een Google Earth-document heeft geen element dat iets daarvan kan bevatten. Er is dus geen analyse te doen op het bestand, alleen een route om naar te kijken.

De tijdstempels gaan mee weg, wat het verlies is dat mensen verrast. De tijdslider van Google Earth — de bediening die een track afspeelt — heeft een gx:Track met parallelle `<when>`-waarden nodig, en deze omzetting schrijft een gewone LineString. Wil de ontvanger de sessie echt bestuderen, stuur dan de TCX zelf, of zet om naar GPX, wat de klok behoudt en wat de meeste trainingssoftware importeert.

Eén placemark per activiteit, benoemd naar de sport — `Running`, `Biking` of `Other`, want een TCX-activiteit heeft geen naamveld en de platformtitel die jij kent, leeft in een database in plaats van in de export. De lijn volgt het terrein in plaats van het te doorkruisen, want er staat een tessellatievlag op elke LineString, en hij wordt getekend met de standaardweergave van Google Earth, aangezien er geen stijl geschreven wordt.

Er zijn geen spelden. Een TCX heeft geen waypointconcept, dus wordt niets in het bestand een marker, en de ontvanger ziet een kale lijn in de zijbalk. Moet een start, een top of een ontmoetingspunt uitgelicht worden, dan is de praktische route de placemarks toevoegen in Google Earth na het openen en het bestand terug opslaan — een minuutje werk dat een beter briefingdocument oplevert dan welke omzetter dan ook zou kunnen maken.

Trackpunten zonder `<Position>` worden weggelaten, en het horloge legt ze vast telkens als de ontvanger geen zicht op de hemel heeft: tunnels, onderdoorgangen, parkeergarages, diepe straatcanyons. In de KMZ ontbreken die stukken, dus de lijn loopt recht van het laatste vastgestelde punt naar het eerste erna, soms dwars door een rivier of een heuvel.

Het oogt als een fout en dat is het niet — het bestand bevatte die posities nooit, en geen omzetting kan ze herstellen. Een zin in de begeleidende e-mail is de moeite waard als de route een duidelijk voorbeeld heeft, want het alternatief is dat de ontvanger concludeert dat het bestand kapot is. Een volledig binnensessie heeft nergens vastleggingen en levert helemaal geen geometrie op, waarna de omzetting zegt dat er geen track of waypoints zijn gevonden — wat de correcte beschrijving is.

Stuur de KMZ als de vraag is "welke kant ben je op gegaan" en de ontvanger geen trainingsplatform is. Stuur de TCX als de vraag over de sessie gaat — tempo, inspanning, splits — en de ontvanger software heeft die het leest. Stuur beide als je het niet zeker weet, want samen zijn ze nog steeds ruim onder de drie megabyte en de onduidelijkheid kost meer tijd dan de bytes.

De combinatie die je beter kunt vermijden is alleen de KMZ sturen en die als archief van de sessie behandelen. Dat is het niet, en het kan niet worden teruggezet: de trainingsdata bestaat niet in het bestand en geen enkel gereedschap kan het reconstrueren. Bewaar de TCX waar je je gegevens bewaart, en zie de KMZ zoals je een PDF geëxporteerd uit een document zou zien.

Een KMZ kan niet ter plekke bewerkt worden. Om de placemark te hernoemen, de lijn te kleuren of een dwaalpunt te knippen, hernoem het bestand naar `.zip`, pak het document uit, bewerk de XML, en herzip het met dat document aan de root van het archief in plaats van in een map. Dat rootdetail is wat mensen fout doen, en het symptoom is een bestand dat in sommige lezers opent tot een lege kaart en in andere prima werkt.

Verwacht je meer dan één ronde wijzigingen, bewaar dan een KML als werkkopie en produceer elke keer een KMZ als je er een verstuurt. Dat is dezelfde discipline als een brondocument bewaren en ervan exporteren, en het voorkomt dat de enige kopie van een gecorrigeerde route in een archief zit dat iemand anders al heeft.

Een TCX gedownload als bulkexport van een trainingsplatform kan veel activiteiten in één document bevatten, en elke wordt zijn eigen placemark in het archief. Ze nemen allemaal hun naam van de sport, dus een maand fietsen landt in de zijbalk van de ontvanger als een kolom items die allemaal `Biking` lezen, boven op elkaar getekend op de wereldbol zonder aan te geven welke dinsdag is en welke zondag. Ze een voor een aan- en uitzetten om de juiste te vinden is de enige weg erdoorheen, en het is een armzalig ding om iemand te geven.

Splitsen voor het omzetten is de oplossing. Activiteitgrenzen zijn onmiskenbaar in de XML — elk `<Activity>`-element opent met zijn eigen `<Id>`-tijdstempel — dus het bestand in één sessie per document knippen is mechanisch werk, en ze apart omzetten geeft één archief per rit met een bestandsnaam die zegt welke. Waar ze echt bij elkaar horen, is het alternatief om de `<name>` van elke placemark in de KML te bewerken voor hij gezipt wordt, wat ongeveer even lang duurt en een zijbalk oplevert die iemand daadwerkelijk kan lezen.

De TCX wordt geparseerd, de KML geschreven en het archief gezipt, allemaal in dit browsertabblad. Geen verzoek verstuurt het bestand ergens naartoe, wat het netwerkpaneel tijdens een omzetting laat zien, en de pagina werkt met de verbinding uitgeschakeld zodra hij geladen is.

Het alternatief waar de meeste mensen naar grijpen is een webomzetter of een compressiesite, wat betekent dat een document met je hartslag en je huisadres door de machine van een vreemde gaat zodat een e-mailbijlage kleiner wordt. Je gaat het resultaat sowieso naar iemand sturen; dat is één ontvanger die je zelf kiest. Het lokaal omzetten houdt het bij die ene.