KML in CSV umwandeln

Kommunale Open-Data-Portale veröffentlichen Standortlisten häufig als KML, weil das Format ursprünglich für Google Earth gedacht war und sich in vielen Verwaltungsabläufen als Exportformat gehalten hat — Ladesäulen für Elektrofahrzeuge, Feuerwehrstandorte, öffentliche Spielplätze, Sammelstellen. Wer diese Liste in einer Tabellenkalkulation weiterverarbeiten, mit anderen Datenbeständen abgleichen oder in ein Fachverfahren importieren will, sitzt vor einer Datei, die kein gängiges Tabellenprogramm direkt öffnet.

Diese Umwandlung liest genau diese Placemarks aus und schreibt sie als Zeilen mit Name, Breitengrad und Längengrad — die Form, die eine Verwaltung, ein Geoinformationssystem oder eine einfache Excel-Tabelle tatsächlich verarbeiten kann.

KML wurde zum Zeichnen auf einem Globus entworfen. Eine Datei voller Placemarks trägt weit mehr als nur Positionen — ein Symbol pro Marker, eine Beschreibungsblase mit eingebettetem HTML, eine Ordnerstruktur, die alles gruppiert. Ein sehr großer Teil der im Umlauf befindlichen KML-Dateien ist aber im Kern nichts anderes als eine Liste, die wie eine Karte aussieht: vierzig Standorte, eine Liste von Prüfstellen, die Orte, die jemand über ein Jahr in Google Earth markiert hat.

Für genau diese Datei ist eine CSV die ehrlichere Form. Jedes Placemark wird zu einer Zeile aus Name und Koordinaten, und das ist es, was ein Geokodierungsdienst, eine Routenoptimierung, ein CRM-Import oder eine einfache Gruppierung tatsächlich braucht. Alles, was aus der Datei eine Zeichnung gemacht hat, bleibt bewusst zurück.

KML schreibt eine Koordinate als „Längengrad, Breitengrad, Höhe" in einer einzigen, durch Leerzeichen getrennten Zeichenkette — die umgekehrte Reihenfolge fast jedes anderen Formats in dieser Familie, GPX eingeschlossen. Diese Vertauschung ist der häufigste Grund, warum eine KML-Umwandlung schiefgeht: Wird sie übersehen, landet Berlin bei 13,4 / 52,5 statt bei 52,5 / 13,4 — irgendwo im Nichts.

Diese Umwandlung tauscht die beiden Werte zurück, sodass die CSV-Spalten in der Reihenfolge „Breitengrad, Längengrad" stehen. Eine Sekunde reicht zur Kontrolle: Für Deutschland liegt der Breitengrad grob zwischen 47 und 55, der Längengrad zwischen 6 und 15 — steht die kleinere Zahl in der zweiten Spalte, hat etwas vorher schon einmal vertauscht.

Eine KML verschachtelt sich. Ein `<Document>` enthält `<Folder>`-Elemente, die weitere Ordner enthalten können, bis schließlich die `<Placemark>`-Elemente mit der eigentlichen Geometrie folgen. Diese Umwandlung geht den ganzen Baum durch statt nur die oberste Ebene zu prüfen — Exporte aus Verwaltungssoftware legen Standorte häufig drei Ebenen tief ab, und ein Parser, der nur oben nachsieht, meldet eine leere Datei, obwohl sie voll ist.

Was dabei nicht erhalten bleibt, ist die Ordnerstruktur selbst. Ein Standort in „Bezirk Ost / Phase 2 / bestätigt" kommt als Zeile heraus, die von einem Standort auf der obersten Ebene nicht zu unterscheiden ist, weil die CSV eine einzige Namensspalte hat, die dem Placemark gehört. Ist die Gruppierung die eigentliche Information, muss sie vor der Umwandlung in den Placemark-Namen selbst hineingeschrieben werden.

Ein Placemark mit einem `<Point>` wird zu einer Zeile vom Typ „waypoint". Ein Placemark mit einem `<LineString>` wird zu mehreren Zeilen vom Typ „track", eine je Stützpunkt, alle mit demselben Namen. Beide Fälle decken den überwiegenden Teil aller im Umlauf befindlichen KML-Dateien ab, und beide behalten ihre Namen.

Zwei Dinge ergeben dagegen gar nichts, und das sollte man vor dem Umwandeln wissen. Ein `<Polygon>` — eine schraffierte Fläche, eine Grundstücksgrenze, ein Versorgungsgebiet — trägt seine Umrisslinie in verschachtelten Grenzelementen, die diese Umwandlung nicht ausliest, sodass eine Fläche keine Zeile beisteuert. Eine KML, die ausschließlich aus solchen Flächen besteht, meldet zu Recht, dass keine verwertbaren Punkte gefunden wurden.

Der dritte Wert einer KML-Koordinate ist die Höhe in Metern, und diese Umwandlung schreibt ihn in die Spalte „elevation", sofern er vorhanden ist. Was sie nicht auswertet, ist `<altitudeMode>` — das Nachbarelement, das festlegt, ob die Höhe an den Boden gebunden, relativ dazu oder absolut gemeint ist.

Das ist entscheidend, weil Google Earths Voreinstellung „clampToGround" die Höhe komplett ignoriert und oft schlicht als 0 gespeichert wird. Eine KML, die freihändig über bewegtem Gelände gezeichnet wurde, liefert deshalb häufig eine Höhenspalte voller Nullen, die „auf der Oberfläche" bedeuten und nicht „auf Meereshöhe". Eine Spalte voller Nullen ist ein Hinweis darauf, dass die Angabe fehlt, keine echte Messung.

KML kennt ein `<address>`-Element, und Verwaltungssoftware füllt es mitunter, wenn ein Standort per Adresssuche angelegt wurde. Diese Umwandlung liest es nicht aus, sodass die Ausgabe Name und Koordinaten enthält, aber nichts, das einer Postanschrift ähnelt, selbst wenn die Quelldatei eine gepflegt hatte.

Für die meisten Weiterverwendungen ist das kein Nachteil, weil ein Koordinatenpaar ein stärkerer Schlüssel ist als eine Adresszeile und jeder Routing-, Kartierungs- oder Geokodierungsdienst damit direkt arbeitet. Wird tatsächlich eine Adresse gebraucht, muss sie nachträglich über eine Rückwärtsgeokodierung ermittelt werden — und ein Stichprobenblick lohnt sich, weil ein mitten auf einem Parkplatz gesetzter Punkt auf das nächstgelegene Gebäude aufgelöst wird, das nicht zwingend das gemeinte ist.

Ein LineString ist eine Form ohne Zeitbezug. Stammt die KML aus einer GPS-Aufzeichnung statt aus einer Zeichnung, enthält sie stattdessen häufig einen `gx:Track` — Googles eigene Erweiterung, die parallele Listen aus `<when>`-Zeitstempeln und `<coord>`-Positionen speichert. Diese Umwandlung behandelt das als eigenen Fall, und die Zeitstempel landen in der Spalte „time".

Ob eine Datei einen solchen Track enthält, verrät sich an genau dieser Spalte: Ist sie durchgängig leer, lag ein einfaches LineString vor, und kein Konverter kann Zeiten liefern, die eine Datei nie gespeichert hat. Das ist auch der Grund, warum der dritte Wert innerhalb eines gx:Track mit einem Leerzeichen statt einem Komma getrennt wird — dieselbe Datei nutzt zwei verschiedene Trennzeichen für zwei verschiedene Geometrien.

Placemark-Namen sind das Feld, das eine einfache CSV am ehesten beschädigt, weil sie freier Text sind. „Halle 3, Nebeneingang" enthält bereits das Trennzeichen, eine als Name verwendete Adresse gleich mehrfach. Jeder Wert, der ein Komma, ein Anführungszeichen oder einen Zeilenumbruch enthält, wird deshalb in Anführungszeichen gesetzt, innere Anführungszeichen werden verdoppelt — genau das, was RFC 4180 verlangt und jede Tabellenkalkulation korrekt zurückliest.

Koordinaten brauchen nie eine solche Behandlung, deshalb bleibt die Datei auch in einem reinen Texteditor lesbar. Beim Prüfen der Ausgabe lohnt sich ein Blick genau auf die in Anführungszeichen gesetzten Zeilen: Ein unausgeglichenes Anführungszeichen im Namen deutet darauf hin, dass schon die ursprüngliche KML-Datei fehlerhaft war, und die Umwandlung gibt diesen Fehler unverändert weiter.

Die Umwandlung läuft vollständig in diesem Browser-Tab — die KML wird gelesen, durchlaufen und neu geschrieben, ohne dass eine Anfrage sie irgendwohin trägt. Es gibt kein Konto, keine Warteschlange und keine Aufbewahrungsfrist zu lesen, weil auf einem Server nichts liegt, das eine solche Frist bräuchte.

Der Grund, warum das bei dieser Umwandlung besonders zählt: Eine KML voller Standorte ist häufig eine Kundenliste, eine Lieferadresse, ein Bestand an Einsatzorten oder Standorte, die niemand veröffentlichen möchte. Als CSV wird sie zugleich portabler und leichter lesbar — und verdient deshalb dieselbe Sorgfalt im Umgang wie die Tabelle, die daraus entsteht.