KMZ naar KML omzetten

De eerste is handmatig. Hernoem het bestand van .kmz naar .zip, open het, en haal het document eruit — je houdt precies over wat de auteur opsloeg, met elke stijl, beschrijving en map intact, plus alle afbeeldingen die ermee meereisden. Er gaat niets verloren omdat er niets is geïnterpreteerd. Het kost ongeveer vijftien seconden en geen software.

De tweede is deze omzetting, die het document leest en een nieuw document schrijft met de geometrie en de namen. Dat is een kleiner en eenvoudiger bestand dan het origineel, en soms is dat precies wat je nodig hebt: een importtool die een complexe KML weigert, een script dat één vorm document verwacht, een bestand dat je met de hand gaat bewerken en liever niet doorworstelt. Weten welke van de twee je wilt is het grootste deel van de beslissing.

De uitvoer is een KML 2.2-document met één <Document>-element, een naam als de bron er een had, en een platte lijst met Placemarks. Elk punt in het archief wordt een Placemark met een <Point>; elke lijn wordt een Placemark met een <LineString> en een vlag <tessellate>1</tessellate> zodat hij het terrein volgt in plaats van erdoorheen te snijden. Namen worden op alle overgenomen.

Dat is het hele bestand. Er is geen <Style>-blok, geen styleUrl, geen <description>, geen <ExtendedData> en geen mapstructuur, wat het ongewoon eenvoudig maakt om te lezen en te bewerken: één placemark is vier of vijf regels, en de coördinaat vinden die je wilt wijzigen betekent scrollen naar een naam in plaats van een verwijzing volgen.

Archieven van organisaties zijn meestal gestileerd, omdat ze zijn gemaakt om bekeken te worden. Verwacht <Style>- en <StyleMap>-definities voor lijnkleuren en aangepaste iconen, <description>-ballonnen met HTML en soms hele tabellen, <ExtendedData> met de databasevelden waar elk kenmerk uit voortkwam, en een mapstructuur die kenmerken groepeert per laag of fase. Niets daarvan verschijnt in de uitvoer.

Twee dingen verdienen apart genoemd te worden. Een <GroundOverlay> — een gescand plan of een luchtfoto over het terrein gedrapeerd — wordt helemaal niet gelezen, dus een archief waarvan de echte inhoud een afbeelding is, zet om naar een bijna leeg document. En een <NetworkLink> bevat een URL in plaats van data, dus een KMZ die daaromheen is gebouwd levert geen placemarks op en meldt dat er geen spoor of waypoints zijn gevonden, wat klopt: de kaart zat nooit in het bestand.

Binnen heet het hoofdlid van het archief conventioneel doc.kml, aan de wortel van het archief in plaats van in een map. Dat is wat Google Earth schrijft en waar lezers eerst naar zoeken. Als een archief uit andere software komt, is het document soms genoemd naar de laag; de terugval is dan het eerste lid dat eindigt op .kml, en een archief zonder KML-lid stopt de omzetting met een melding die dat precies zegt.

Dit doet ertoe als je iets met de hand gaat inpakken. Een KMZ waarvan het document één map dieper zit, opent in sommige lezers en toont stilletjes een lege kaart in andere, en de gebruikelijke oorzaak is dat een map is gezipt in plaats van het bestand erin. Als je uitpakt, bewerkt en opnieuw inpakt, selecteer dan het document zelf en controleer daarna dat het archief het bovenaan vermeldt.

Als het archief een gx:Track bevat — Google’s geometrie voor GPS-sporen, met parallelle lijsten van <when>-tijdstempels en <coord>-posities — worden de posities gelezen en de tijden ermee. Maar de schrijver produceert een <LineString>, die alleen coördinaten opslaat en verder niets, dus de tijdstempels hebben nergens naartoe en vallen weg.

De uitvoer is dus een vorm waar het invoerbestand een opname was, en Google Earths tijdschuif verschijnt er niet voor. Als de tijden ertoe doen, is dit de verkeerde omzetting en is KMZ naar GPX de juiste, waar elk trackpunt een <time>-element heeft en de opname een opname blijft. Het is een ongewoon geval — de meeste KMZ-bestanden in omloop zijn getekend, niet opgenomen — maar het is het geval waar het verlies stil is en compleet.

Document- en Folder-elementen worden recursief doorlopen, dus een placemark drie niveaus diep wordt gevonden — nodig, want exports uit kaartsoftware begraven hun kenmerken routinematig. Wat de doorloop niet doet, is bewaren waar ze zaten. Alles komt in één platte lijst naar buiten.

Voor een KMZ georganiseerd per laag is dat een echt verlies van structuur: "Fase 1 / Bevestigd / Locatie 14" en "Fase 3 / Voorgesteld / Locatie 14" worden twee placemarks genaamd "Locatie 14" naast elkaar. Als de groepering informatie is die je nodig hebt, moet die vóór het omzetten in de placemarknamen worden gevouwen, of het archief met de hand worden uitgepakt zodat de mappen blijven bestaan.

Een KMZ is kleiner dan de KML die het bevat, dus het uitpakken kost altijd bytes. Gemeten hier comprimeerde een document van ongeveer 258 KB tot circa 47 KB binnen het archief, een factor van vijfenhalf — coördinatentekst is bijna het beste geval voor deflate, omdat elke regel een voorvoegsel deelt met de vorige.

Het weer opblazen is het grootste deel van wat deze omzetting doet, en het loont om de groei te verwachten in plaats van erdoor verrast te worden. De praktische grens is het plafond van 100 MB dat op het archief zoals het binnenkomt wordt toegepast, maar het getal dat je bij een grote publicatie het eerst tegenkomt is het geheugen van je browsertabblad.

Het genormaliseerde document is eenvoudig met de hand te bewerken. Coördinaten worden geschreven als drietallen "lengtegraad,breedtegraad,hoogte", één per regel binnen het <coordinates>-element, met lengtegraad eerst — omgekeerd aan GPX en aan de meeste andere dingen, en het detail dat het vaakst fout gaat als je een vervanging met de hand typt. Zes decimalen is wat de schrijver produceert, ongeveer 11 centimeter, en meer toevoegen heeft geen voordeel.

Stijl toevoegen is een kleine klus als je dat wilt: één <Style>-blok met een <LineStyle>-kleur en -breedte bovenaan het document, en een styleUrl op elk placemark dat die moet gebruiken. Google Earth doet het ook interactief — open de KML, wijzig het uiterlijk in het eigenschappenvenster en bewaar de locatie, wat de stijl in het bestand schrijft.

Software die zegt KML te lezen, verschilt enorm in hoeveel ervan daadwerkelijk is geïmplementeerd, en de weigeringen clusteren rond een kort lijstje: een <Schema> met getypeerde <ExtendedData>-velden, een gx:-genaamruimte geometrie die de lezer niet herkent, een <NetworkLink> die hij niet volgt, een <StyleMap> die naar een icoon wijst dat niet in het archief zit. Elk daarvan kan een foutmelding geven die geen ervan bij naam noemt.

De genormaliseerde uitvoer bevat niets daarvan — één namespace, twee geometrietypen, namen en coördinaten, en geen verwijzing naar iets buiten het bestand. Dat is wat deze omzetting biedt boven het archief handmatig uitpakken, en het is de reden om het te proberen wanneer een import om onduidelijke redenen mislukte.

Het archief wordt uitgepakt, geparst en herschreven binnen dit browsertabblad. Er wordt niets verzonden, wat het netwerkpaneel tijdens een omzetting laat zien, en de pagina blijft werken met de verbinding uit zodra hij geladen is.

Dat is het praktische antwoord op een veelvoorkomende ongemakkelijkheid. Een KMZ van een klant, een aannemer of een overheidsinstantie komt vaak met voorwaarden over waar het bewaard mag worden, en de snelste manier om erin te kijken is meestal een webtool die die voorwaarden ongemerkt zou schenden. Hier is geen derde partij in de keten en geen verwerkersovereenkomst op te zoeken voordat je je eigen bijlage kunt lezen.