Convertir KML en CSV

Le KML a été conçu pour dessiner sur un globe. Un fichier de repères porte bien plus que des positions — un style pour chaque icône, une bulle de description avec du HTML dedans, un arbre de dossiers qui les groupe, parfois un fond de carte en superposition. Mais un très grand nombre de fichiers KML en circulation servent de liste déguisée en carte : quarante implantations de succursale, un jeu de sites d’étude, les endroits que quelqu’un a étoilés dans Google Earth au fil d’une année.

Pour ce fichier-là, un CSV est le conteneur plus honnête. Chaque repère devient une ligne de nom et de coordonnées, ce que consomme réellement un géocodeur, un optimiseur de tournée, un import dans un CRM ou un `GROUP BY`. Tout ce qui en faisait un dessin est laissé de côté, et c’est une perte délibérée plutôt qu’une limite : une colonne pour une URL d’icône n’aiderait personne, et il n’y a pas de forme en colonnes qui survive à une bulle de description en HTML.

Le KML écrit une coordonnée sous la forme `longitude,latitude,altitude` dans une seule chaîne séparée par des espaces. Presque tous les autres formats de cette famille, GPX et TCX compris, nomment la latitude d’abord, et cette inversion est la manière la plus fréquente dont une conversion KML dérape : la paire est transposée plutôt que décalée, et Berlin en 13,4, 52,5 sort en 52,5, 13,4 et atterrit dans la mer d’Arabie.

La conversion les remet dans l’ordre, donc les colonnes du CSV sont `latitude` puis `longitude`. Cela mérite une vérification plutôt qu’une confiance, et il y a un contrôle d’une seconde : pour n’importe où en Europe occidentale, la latitude va d’environ 36 à 71 et la longitude d’environ −10 à 30, donc si la première colonne de coordonnées est petite et la seconde grande, quelque chose en amont les a re-inversées.

Un KML imbrique. Un `<Document>` contient des éléments `<Folder>`, qui contiennent d’autres dossiers et finissent par contenir les éléments `<Placemark>` qui portent la géométrie. Le lecteur parcourt cet arbre plutôt que de regarder un seul niveau, parce qu’un KML exporté depuis un outil de cartographie place couramment ses repères à trois niveaux de profondeur, et un analyseur qui ne vérifie que le haut du document annonce un fichier vide qui est en fait plein.

Ce que la promenade ne fait pas, c’est préserver la structure des dossiers. Une épingle dans `Sites / Phase 2 / Confirmé` sort comme une ligne indistinguable d’une au niveau racine, parce que le CSV n’a qu’une colonne `name` et qu’elle appartient au repère. Si le regroupement est l’information, il faut l’encoder dans les noms de repères avant la conversion, ou le retrouver à partir du KML après.

Un Placemark qui contient un `<Point>` devient une ligne de type `waypoint`. Un Placemark qui contient un `<LineString>` devient une série de lignes de type `track`, une par sommet, partageant toutes le nom du repère. Ces deux cas couvrent l’écrasante majorité du KML en circulation et passent tous deux avec leurs noms intacts.

Deux choses ne produisent rien du tout, et cela vaut la peine de le savoir avant de convertir. Un `<Polygon>` — une zone ombrée, le contour d’une propriété, une zone de service — garde son contour dans des éléments boundary imbriqués que cet analyseur ne descend pas, donc une zone ne contribue aucune ligne. Un `<MultiGeometry>` qui enveloppe plusieurs lignes dans un seul repère est sauté pour la même raison. Un KML fait entièrement de zones échoue sur le message qu’aucun track ou waypoint n’a été trouvé, ce qui est exact et n’est pas un problème de fichier.

Un LineString est une forme sans notion de quand. Si le KML vient d’un export GPS plutôt que d’un dessin, il peut porter à la place un `gx:Track`, l’extension Google qui stocke en parallèle des listes de timestamps `<when>` et de positions `<coord>`. Le lecteur le traite comme un cas à part plutôt que comme une ligne, et les timestamps atterrissent dans la colonne `time`.

Le signe que vous en avez un, c’est que la colonne `time` est remplie. Si toutes ses cellules sont vides, la source contenait des LineString, et aucun convertisseur ne peut récupérer des heures qu’un fichier n’a jamais stockées. C’est aussi la raison pour laquelle la troisième valeur de coordonnée à l’intérieur d’un gx:Track est séparée par un espace plutôt que par une virgule — le même document utilise deux séparateurs différents pour deux géométries différentes, ce qui est une vraie étrangeté du format plutôt qu’une erreur dans un fichier.

La troisième valeur d’une coordonnée KML est l’altitude en mètres, et la conversion l’écrit dans la colonne `elevation` quand elle est présente. Ce qu’elle ne fait pas, c’est consulter `<altitudeMode>`, l’élément voisin qui dit comment l’altitude doit être interprétée — plaquée au sol, relative au sol, ou absolue.

Cela compte parce que la valeur par défaut de Google Earth est `clampToGround`, sous laquelle la valeur d’altitude est purement ignorée et très souvent écrite `0`. Donc un KML dessiné à la main sur un terrain vallonné tend à produire une colonne elevation pleine de zéros qui veulent dire « à la surface », pas « au niveau de la mer ». Traitez une colonne de zéros comme absente plutôt que comme une donnée, et tirez l’altitude d’un GPX ou d’un TCX si c’est ce nombre que vous êtes venu chercher.

La sortie met toutes les lignes `waypoint` avant toutes les lignes `track`, quel que soit l’ordre dans lequel elles apparaissaient dans le document. C’est une commodité pour le cas courant : un KML d’épingles se convertit en un fichier dont les lignes sont toutes des waypoints, et un KML mixte d’épingles plus un itinéraire dessiné vous donne les épingles en haut, où on peut les sélectionner sans défiler.

Le coût, c’est que l’ordre du document n’est pas préservé entre les deux types. Si la séquence d’objets dans le KML avait du sens — l’ordre dans lequel une campagne a visité ses sites, par exemple — cet ordre doit venir des noms de repères ou de la colonne `time`, et pas des numéros de ligne. À l’intérieur de chaque type, l’ordre d’origine est conservé tel quel.

Les noms de repères sont le champ qui a le plus de chances de casser un CSV naïf, parce que c’est du texte libre écrit par une personne. « Entrepôt 3, accès arrière » contient le délimiteur, et une adresse employée comme nom en contient plusieurs. L’écriture cite toute valeur contenant une virgule, un guillemet ou un saut de ligne, et double les guillemets intérieurs, ce que demande la RFC 4180 et ce que toute feuille de calcul et toute bibliothèque CSV relit correctement.

Les coordonnées n’ont jamais besoin d’être citées, donc le fichier reste lisible dans un éditeur de texte. Si vous vérifiez la sortie à l’œil, les noms cités sont les lignes qui valent un coup d’œil : un nom contenant un guillemet non équilibré dans le KML d’origine est le seul cas où le fichier d’origine était déjà mal formé et où la conversion le transporte fidèlement.

Le KML définit un élément `<address>` sur un Placemark, et Google Earth le remplit quand une épingle a été créée en cherchant un lieu plutôt qu’en cliquant sur le globe. Il n’est pas lu ici, donc la sortie porte un nom et des coordonnées et rien qui ressemble à une adresse postale, même quand le document source en avait une.

Pour la plupart des destinations, ce n’est pas une perte, parce qu’une latitude et une longitude est une clé plus forte qu’une ligne d’adresse et que chaque service de routage, de cartographie et de géocodage en accepte une directement. Là où une adresse est vraiment demandée — une tournée de courrier, un bordereau de livraison — il faut la tirer d’une étape de géocodage inverse à partir des coordonnées, et une poignée de résultats méritent d’être vérifiés à l’œil : une épingle posée au milieu d’un parking résout sur le bâtiment le plus proche, qui n’est souvent pas celui qu’elle marquait.

La conversion tourne entièrement dans cet onglet de navigateur — le KML est lu, parcouru et réécrit localement, et aucune requête ne le transporte. Il n’y a pas de compte, pas de file d’attente et pas de politique de conservation à lire, parce qu’il n’y a rien sur un serveur à conserver.

La raison de s’en soucier, c’est ce qu’est en général une liste de repères. Un KML d’épingles est souvent une liste de clients, un jeu d’adresses de livraison, des sites de patients ou de clients, ou les emplacements d’actifs que quelqu’un préférerait ne pas voir publiés. Le convertir en CSV le rend plus portable et plus lisible en même temps, et la sortie mérite donc la même protection que la feuille de calcul dont elle va faire partie.