KMZ in KML umwandeln

Der erste ist von Hand: Die Endung von .kmz auf .zip ändern, öffnen und das Dokument herausnehmen — damit liegt genau das vor, was ursprünglich gespeichert wurde, mit jedem Stil, jeder Beschreibung und jeder Ordnerstruktur, dazu alle mitgelieferten Bilder. Nichts geht verloren, weil nichts interpretiert wird. Das dauert eine Viertelminute und braucht keine Software.

Der zweite ist diese Umwandlung, die das Dokument liest und ein neues schreibt, das nur noch die Geometrie und die Namen enthält. Das Ergebnis ist kleiner und einfacher als das Original, und genau das ist manchmal gewollt: ein Importwerkzeug, das an komplexem KML scheitert, ein Skript, das eine bestimmte Dokumentform erwartet, eine Datei, die per Hand bearbeitet werden soll und in der niemand durch verschachtelte Stile suchen möchte. Zu wissen, welche der beiden Varianten gebraucht wird, ist der größte Teil der Entscheidung.

Das Ergebnis ist ein KML-2.2-Dokument mit einem Document-Element, dem Namen aus der Quelle, falls vorhanden, und einer flachen Liste von Placemarks. Jeder Punkt aus dem Archiv wird zu einem Placemark mit Point, jede Linie zu einem Placemark mit LineString samt tessellate-Angabe, damit sie dem Geländeverlauf folgt statt hindurchzuschneiden. Namen bleiben bei allen erhalten.

Das ist der gesamte Inhalt. Kein Style-Block, kein styleUrl, keine description, kein ExtendedData, keine verschachtelten Ordner — was das Dokument ungewöhnlich einfach zu lesen und zu bearbeiten macht: Ein Placemark umfasst vier oder fünf Zeilen, und eine gesuchte Koordinate findet sich über den Namen statt über eine Verweiskette.

Archive von Behörden, Vermessungsämtern oder Kommunen sind meist gestaltet, weil sie zum Betrachten gedacht sind. Zu erwarten sind Style- und StyleMap-Definitionen für Linienfarben und eigene Symbole, description-Blöcke mit HTML und mitunter ganzen Tabellen, ExtendedData mit den ursprünglichen Datenbankfeldern, und eine Ordnerstruktur, die Objekte nach Themenschicht oder Bauabschnitt gruppiert. Nichts davon erscheint im Ergebnis.

Zwei weitere Dinge fallen gesondert auf. Ein GroundOverlay — ein eingescannter Plan oder ein Luftbild über dem Gelände — wird gar nicht erst gelesen, ein Archiv, dessen eigentlicher Inhalt ein Bild ist, wandelt sich also in ein nahezu leeres Dokument. Und ein NetworkLink trägt nur eine Adresse statt Daten, ein darauf aufgebautes KMZ liefert deshalb keine Placemarks und meldet, dass keine Route oder Wegpunkte gefunden wurden — was zutrifft, denn die eigentliche Karte war nie in der Datei.

Üblicherweise heißt das Hauptdokument doc.kml und liegt direkt an der Wurzel des Archivs, nicht in einem Unterordner — so schreibt es Google Earth, und so suchen die meisten Lesewerkzeuge zuerst. Kommt das Archiv aus anderer Software, trägt das Dokument oft den Namen der Ebene, deshalb greift als Rückfall die erste Datei mit der Endung .kml; ein Archiv ganz ohne KML-Datei bricht die Umwandlung mit einer entsprechenden Meldung ab.

Das ist wichtig, wer selbst etwas repackt. Liegt das Dokument eine Ebene tiefer, öffnet es sich in manchen Lesern trotzdem, in anderen zeigt sich stillschweigend eine leere Karte — meist, weil ein ganzer Ordner statt der Datei darin gezippt wurde. Wer entpackt, bearbeitet und neu zippt, wählt das Dokument selbst aus und prüft danach, dass es an oberster Stelle im Archiv steht.

Enthält das Archiv einen gx:Track — Googles Geometrie für aufgezeichnete GPS-Spuren, mit parallelen Listen aus when-Zeitstempeln und coord-Positionen —, werden die Positionen gelesen, die Zeiten ebenfalls. Geschrieben wird aber ein LineString, der nur Koordinaten kennt und sonst nichts, die Zeitstempel haben also keinen Platz mehr und fallen weg.

Das Ergebnis ist damit eine reine Form, wo die Quelle eine Aufzeichnung war, und Google Earths Zeitschieberegler erscheint dafür nicht mehr. Zählen die Zeiten — etwa bei einer aufgezeichneten Wanderung oder einer GPS-Spur des Deutschen Alpenvereins —, ist KMZ zu GPX die richtige Wahl, weil dort jeder Trackpunkt sein eigenes time-Element behält.

Document- und Folder-Elemente werden rekursiv durchsucht, deshalb wird auch ein drei Ebenen tief verschachteltes Placemark gefunden — nötig, weil Exporte aus GIS-Software ihre Objekte häufig genau so vergraben. Was dabei nicht erhalten bleibt, ist der Ort im Baum. Alles landet in einer einzigen flachen Liste.

Für ein nach Themenschicht gegliedertes KMZ ist das ein echter Strukturverlust: Bauabschnitt 1 / bestätigt / Standort 14 und Bauabschnitt 3 / geplant / Standort 14 werden zu zwei nebeneinanderstehenden Placemarks namens Standort 14. Zählt diese Gruppierung, muss sie vorher in die Namen eingearbeitet werden, oder das Archiv wird von Hand entpackt, wo die Ordnerstruktur erhalten bleibt.

Ein KMZ ist kleiner als das enthaltene KML, jedes Auspacken kostet also Bytes. Gemessen wurde hier ein rund 258 KB großes Dokument, das im Archiv auf etwa 47 KB komprimiert war — ein Faktor von fünfeinhalb, weil Koordinatentext für eine Deflate-Kompression nahezu ideal ist, da jeder Eintrag mit dem vorherigen einen gemeinsamen Anfang teilt.

Diesen Größensprung zu erwarten ist sinnvoller, als sich davon überraschen zu lassen. Die praktische Grenze ist die 100-MB-Obergrenze für das ankommende Archiv, doch bei einer großen Veröffentlichung stößt eher der Arbeitsspeicher des Browser-Tabs an seine Grenze, weil er das geparste Dokument und nicht die komprimierte Fassung im Speicher hält.

Das bereinigte Dokument lässt sich unkompliziert von Hand bearbeiten. Koordinaten stehen als Dreiergruppe Länge, Breite, Höhe im coordinates-Element, mit der Länge zuerst — anders als bei GPX, und die Reihenfolge, die beim Tippen am ehesten vertauscht wird. Sechs Nachkommastellen liefert der Konverter, das entspricht rund elf Zentimetern Genauigkeit, mehr bringt keinen Vorteil.

Stil lässt sich mit wenig Aufwand nachrüsten: ein Style-Block mit LineStyle-Farbe und -Breite oben im Dokument, dazu ein styleUrl bei jedem Placemark, das ihn verwenden soll. Google Earth kann das auch interaktiv erledigen — Datei öffnen, Erscheinungsbild in den Eigenschaften anpassen, speichern, fertig ist der eingetragene Stil.

Wie viel von KML eine Software tatsächlich versteht, schwankt erheblich, und Ablehnungen häufen sich an ähnlichen Stellen: ein Schema mit typisierten ExtendedData-Feldern, eine gx-Geometrie, die der Leser nicht kennt, ein NetworkLink, dem nicht gefolgt wird, ein StyleMap-Verweis auf ein im Archiv fehlendes Symbol. Jede dieser Stellen kann zu einer Fehlermeldung führen, die keine davon beim Namen nennt.

Das umgeschriebene Dokument enthält nichts davon — ein Namensraum, zwei Geometrietypen, Namen und Koordinaten, kein Verweis auf irgendetwas außerhalb der Datei. Das ist der eigentliche Vorteil gegenüber dem manuellen Entpacken, und es lohnt sich, das zu versuchen, wenn ein Import aus unklaren Gründen scheitert. Lädt das bereinigte Dokument danach, lag das Problem in den entfernten Teilen — eine Diagnose in sich, die eine Minute kostet.

Das Archiv wird ausgepackt, gelesen und neu geschrieben, alles im Browser-Tab. Es wird nichts übertragen, was sich im Netzwerk-Reiter der Entwicklerwerkzeuge während einer Umwandlung nachprüfen lässt, und die Seite funktioniert danach auch ohne Internetverbindung weiter.

Das ist die praktische Antwort auf eine häufige Unannehmlichkeit. Ein KMZ von einer Gemeinde, einem Planungsbüro oder einem Auftraggeber kommt oft mit Auflagen dazu, wo es gespeichert werden darf, und der schnellste Weg hineinzuschauen wäre sonst ein Webdienst, der diese Auflage unbemerkt verletzen würde. Läuft alles im Browser, entfällt sowohl der Dritte in der Kette als auch die Frage nach einer Verarbeitungsvereinbarung, bevor die eigene Datei überhaupt geöffnet ist.