KML in KMZ umwandeln

Ein Wanderverein oder eine Kommune, die Wanderwege oder Schutzgebietsgrenzen digital veröffentlicht, exportiert die Daten häufig als KML aus einem GIS-Programm oder aus Vermessungsdaten des Bauamts. Beim Hochladen in ein Bürgerportal oder beim Versand als E-Mail-Anhang stößt die Datei dann an eine Größenbeschränkung, obwohl inhaltlich nichts Ungewöhnliches darin steht.

Diese Umwandlung packt das Dokument in ein einzelnes komprimiertes KMZ und schrumpft es dabei üblicherweise deutlich. Bevor man umwandelt, lohnt sich aber ein Blick auf das, was dabei verloren geht — bei einem reinen Wegverlauf mit Namen ist das nichts, bei einer aufwendig gestalteten Karte mit Symbolen und Infotexten durchaus etwas.

KMZ wurde für ein Verpackungsproblem entwickelt. Ein KML, das eigene Symbolgrafiken, ein Foto-Overlay oder einen georeferenzierten Kartenausschnitt einbindet, verweist auf diese Dateien über einen relativen Pfad — sobald das Dokument allein verschickt wird, brechen diese Verweise, und die Karte bleibt leer. Dokument und Zusatzdateien gemeinsam in ein Archiv zu packen behebt genau das.

Der zweite Grund ist einfacher: Ein KML ist ausführlicher Text, und Text lässt sich gut komprimieren. Enthält das eigene Dokument keine externen Zusatzdateien — eine Reihe von Punkten, ein gezeichneter Weg, ein Export aus einer Datenbank —, geht es hier ausschließlich um die Dateigröße, nicht um das Verpacken. Welches der beiden Motive vorliegt, lohnt sich vor der Umwandlung zu klären.

Bei einem Wegverlauf mit mehreren tausend Stützpunkten und Höhenangaben je Punkt liegt die Ersparnis regelmäßig bei einem Faktor von fünf oder mehr. Lange Listen von Koordinaten sind für eine Deflate-Kompression fast der Idealfall: Jeder Eintrag teilt einen langen Anfangsabschnitt mit dem vorherigen, die Trennzeichen wiederholen sich endlos, und nur wenige Ziffern am Ende ändern sich wirklich.

Ein Dokument aus vielen kurzen, einzelnen Wegpunkten komprimiert schlechter, weil dort das wiederkehrende XML-Markup die Ersparnis bestimmt statt der Zahlen. Ein Dokument, das überwiegend aus Fließtext in Beschreibungsfeldern besteht, komprimiert wie gewöhnlicher Text. Wie viel es im Einzelfall bringt, zeigt erst die eigene Datei.

Das ist der Punkt, der vor dem Umwandeln verstanden werden sollte. Die Umwandlung packt nicht einfach das eigene KML in eine ZIP-Hülle. Sie liest das Dokument in ein einfaches Zwischenmodell ein — Punkte mit Position, optionaler Höhe und optionaler Zeit, gruppiert in benannte Linien und Marken — und schreibt daraus ein frisches KML, das anschließend komprimiert wird.

Wer das Archiv später öffnet und darin sein eigenes, unverändertes Dokument erwartet, findet es nicht. Stattdessen steckt darin ein knappes, minimales Dokument, das dieselbe Geometrie beschreibt, aber kürzer ist und dessen Elemente in einer anderen Reihenfolge stehen.

Style- und StyleMap-Definitionen samt der Verweise darauf fallen weg, also Linienfarben, -stärken und eigene Symbole. Beschreibungstexte samt eingebettetem HTML verschwinden ebenso wie ExtendedData und benutzerdefinierte Felder — genau dort, wo Angaben aus einer angebundenen Datenbank meist liegen. Ordnerstrukturen fallen weg, weil das Zwischenmodell nur eine flache Liste kennt. Voreingestellte Kamerablickwinkel und Netzwerklinks verschwinden vollständig.

Erhalten bleiben Geometrie und Beschriftung: Jeder Punkt wird zu einer Marke mit Position, jeder Linienzug behält seinen Namen, und der Dokumentname selbst wird übernommen. Für eine reine Weg- oder Standortübersicht ist das alles, was zählt. Für eine gestaltete Präsentationskarte ist es nur ein kleiner Teil, und dann führt der nächste Abschnitt weiter.

Trägt das KML Gestaltung oder Beschreibungen, die erhalten bleiben müssen, ist der verlässliche Weg ein selbst gepacktes Archiv. Das Dokument in `doc.kml` umbenennen, in ein ZIP-Archiv legen, sodass es an der Wurzel liegt statt in einem Unterordner, und die Endung von .zip in .kmz ändern — das schafft jedes gängige Betriebssystem ohne Zusatzsoftware, und das Ergebnis enthält das eigene Dokument unverändert.

Die Wurzelposition ist der Punkt, an dem es am häufigsten schiefgeht. Ein KMZ, dessen KML eine Ebene tiefer liegt, öffnet in manchen Programmen und scheitert in anderen still — die Karte bleibt leer, ohne Fehlermeldung. Wer das Archiv durch Rechtsklick auf einen Ordner erstellt hat, hat meist genau diesen Fehler gemacht.

Ein NetworkLink ist ein KML ohne eigene Daten: Es enthält nur eine Internetadresse und eine Anweisung zum Nachladen, alles Sichtbare wird erst beim Öffnen von einem Server geholt. Freigegebene Team-Karten und laufend aktualisierte Datensätze funktionieren häufig auf diese Weise, und die zugehörige Datei umfasst dann oft nur wenige Kilobyte.

Eine solche Datei liefert dieser Umwandlung keine Punkte und keine Linien, und das Ergebnis meldet, dass keine Wegpunkte gefunden wurden. Das ist keine Fehlfunktion, sondern eine ehrliche Aussage: Die eigentliche Karte stand nie in der Datei, es gibt lokal nichts zu komprimieren, und eine Offlinekopie entsteht so nicht — nur der Abruf der verlinkten Adresse liefert die tatsächlichen Daten.

Kompression ist nicht immer die richtige Antwort auf eine große Datei. Ein 40-Megabyte-Dokument, das in Google Earth langsam lädt, ist langsam wegen der Anzahl der gezeichneten Objekte — auf 7 Megabyte gezippt ändert sich am Rendering nichts, weil vor der Darstellung ohnehin wieder auf die vollen 40 Megabyte entpackt wird.

Liegt das eigentliche Problem beim Rendern, hilft nur eine strukturelle Änderung: das Dokument nach Region oder Ebene aufteilen, dicht gesetzte Linien ausdünnen, oder die Daten in ein für große Mengen gebautes Format überführen. Geht es tatsächlich nur darum, dass eine E-Mail den Anhang nicht annimmt oder ein Uploadformular eine Grenze setzt, ist diese Umwandlung genau richtig.

Wandelt man das Archiv später wieder zurück in KML, kommt das minimale Dokument heraus, nicht die ursprüngliche Datei. Die Vereinfachung geschieht beim Hinweg, und nichts danach kann einen Style-Block, einen Beschreibungstext oder ein eigenes Feld wiederherstellen, das bereits vor dem Packen verworfen wurde.

Deshalb lohnt es sich, das Original zu behalten, statt das Archiv als Ersatz zu betrachten. Der Speicherplatz ist kein echtes Gegenargument — das Ursprungsdokument ist trotz allem meist nur einige Hundert Kilobyte groß — und es ist die einzige Kopie, die noch die Gestaltung, die Ordnerstruktur und die Datenbankfelder trägt.

Das Dokument wird in diesem Browser-Tab gelesen, neu geschrieben und gepackt. Keine Anfrage trägt es irgendwohin, was sich im Netzwerktab der Entwicklerwerkzeuge während einer Umwandlung überprüfen lässt, und die Seite funktioniert auch mit ausgeschalteter Internetverbindung weiter.

Das ist bei dieser Umwandlung mehr wert als sonst, weil die naheliegende Alternative eine Datei-Kompressionswebsite wäre. Ein KML mit Standorten von Kunden, Grundstücken oder Anlagen ist geschäftsrelevante Information mit Ortsbezug, und der übliche Weg, sie kleiner zu machen, bedeutet, sie einem fremden Server anzuvertrauen, zu warten und wieder herunterzuladen. Die lokale Verarbeitung nimmt diesen Umweg heraus, statt ihn nur erträglicher zu machen.