Convertir KMZ en KML

La première est manuelle. Renommez le fichier de .kmz en .zip, ouvrez-le, et retirez le document — vous tenez maintenant exactement ce que l’auteur a enregistré, avec tous les styles, les descriptions et les dossiers intacts, plus toutes les images qui ont voyagé avec. Rien n’est perdu parce que rien n’a été interprété. Cela prend une quinzaine de secondes et aucun logiciel.

La seconde est cette conversion, qui lit le document et en écrit un nouveau contenant la géométrie et les noms. C’est un fichier plus petit et plus simple que l’original, et parfois c’est précisément ce qu’il vous faut : un importeur qui rejette un KML complexe, un script qui attend une forme de document, un fichier que vous allez éditer à la main et préférez ne pas avoir à décortiquer. Savoir lequel des deux vous voulez est l’essentiel de la décision, et la voie manuelle est la bonne réponse plus souvent qu’une page de convertisseur ne l’admettrait normalement.

La sortie est un document KML 2.2 avec un élément <Document>, un nom si la source en avait un, et une liste plate de repères. Chaque point de l’archive devient un repère contenant un <Point> ; chaque ligne devient un repère contenant un <LineString> avec un drapeau <tessellate>1</tessellate> pour qu’elle suive le terrain plutôt que de le traverser. Les noms sont portés sur tous.

C’est tout le fichier. Il n’y a pas de bloc <Style>, pas de styleUrl, pas de <description>, pas de <ExtendedData> et pas d’imbrication de dossiers, ce qui le rend inhabituellement facile à lire et à éditer : un repère fait quatre ou cinq lignes, et trouver la coordonnée que vous voulez changer consiste à défiler jusqu’à un nom plutôt qu’à suivre une référence. Pour l’édition à la main, cette simplicité est la fonctionnalité.

Les archives produites par des organisations sont généralement stylées, parce qu’elles ont été faites pour être regardées. Attendez-vous à des définitions de <Style> et <StyleMap> fixant les couleurs de ligne et les icônes personnalisées, à des infobulles <description> contenant du HTML et parfois des tables entières, à <ExtendedData> portant les champs de base de données dont chaque entité vient, et à une arborescence de dossiers qui regroupe les entités par couche ou par phase. Rien de tout cela n’apparaît dans la sortie.

Deux choses de plus s’en vont et méritent d’être signalées à part. Un <GroundOverlay> — un plan scanné ou une image aérienne drapée sur le terrain — n’est pas lu du tout, donc une archive dont le vrai contenu est une image se convertit en un document presque vide. Et un <NetworkLink> contient une URL plutôt que des données, donc un KMZ construit autour d’un NetworkLink ne produit aucun repère et indique qu’aucun tracé ni aucun waypoint n’a été trouvé, ce qui est exact : la carte n’a jamais été dans le fichier.

À l’intérieur, le membre principal est conventionnellement doc.kml, à la racine de l’archive plutôt que dans un dossier. C’est ce qu’écrit Google Earth et ce que les lecteurs cherchent d’abord. Quand une archive vient d’un autre logiciel, le document peut être nommé d’après la couche à la place, donc le repli est le premier membre dont le nom se termine en .kml, et une archive sans aucun membre KML arrête la conversion avec un message qui le dit exactement.

Cela compte si vous allez réemballer quoi que ce soit à la main. Un KMZ dont le document est descendu d’un répertoire s’ouvre chez certains lecteurs et montre silencieusement une carte vide chez d’autres, et la cause habituelle est d’avoir zippé un dossier plutôt que le fichier qu’il contient. Si vous extrayez, éditez et recompressez, sélectionnez le document lui-même et vérifiez ensuite que l’archive le liste au niveau supérieur.

Si l’archive contient un gx:Track — la géométrie de Google pour les traces GPS, qui stocke des listes parallèles d’horodatages <when> et de positions <coord> — les positions sont lues et les heures sont lues avec elles. Mais l’écriture produit un <LineString>, qui stocke des coordonnées et rien d’autre, donc les horodatages n’ont nulle part où aller et sont abandonnés au passage.

La sortie est donc une forme là où l’entrée était un enregistrement, et le curseur de temps de Google Earth n’apparaîtra pas pour elle. Si les heures sont ce qui vous intéresse, c’est la mauvaise conversion et la bonne est KMZ en GPX, où chaque point de tracé a un élément <time> et l’enregistrement reste un enregistrement. C’est un cas rare — la plupart des KMZ en circulation ont été dessinés plutôt qu’enregistrés — mais c’est celui où la perte est silencieuse et totale.

Les éléments Document et Folder sont parcourus récursivement, donc un repère imbriqué à trois niveaux de profondeur est trouvé — ce qui est nécessaire, parce que les exports depuis des logiciels de cartographie enterrent routinièrement leurs entités. Ce que la marche ne fait pas, c’est préserver où elles étaient. Tout sort dans une liste plate.

Pour un KMZ organisé par couche, c’est une vraie perte de structure : « Phase 1 / Confirmé / Site 14 » et « Phase 3 / Proposé / Site 14 » deviennent deux repères appelés « Site 14 » assis l’un à côté de l’autre. Si le regroupement est une information dont vous avez besoin, il faut le replier dans les noms de repères avant la conversion, ou extraire l’archive à la main pour que les dossiers survivent. Une liste plate est plus facile à traiter par script et plus difficile à lire, ce qui est l’échange dans les deux sens.

Un KMZ est plus petit que le KML qu’il contient, donc en décompresser un coûte toujours des octets. Mesuré ici, un document d’environ 258 Ko a été compressé à environ 47 Ko dans l’archive, un facteur de cinq et demi — le texte de coordonnées est proche du meilleur cas pour un deflate, puisque chaque entrée partage un préfixe avec la précédente.

Le redéployer est la plus grande part de ce que cette conversion fait, et il vaut mieux s’attendre au changement de taille que d’en être surpris. La limite pratique est le plafond de 100 Mo appliqué à l’archive telle qu’elle arrive, mais le chiffre que vous rencontrez d’abord sur une grosse publication est la mémoire de votre onglet de navigateur, qui doit tenir le document analysé plutôt que le compressé.

Le document normalisé se prête à l’édition à la main. Les coordonnées sont écrites comme des triplets longitude,latitude,altitude, un par ligne dans l’élément <coordinates>, avec la longitude en premier — l’inverse du GPX et de la plupart des autres choses, et le seul détail qu’on a le plus de chances de rater en tapant un remplacement à la main. Six décimales, c’est ce que l’écriture produit, environ 11 centimètres, et il n’y a aucun avantage à en ajouter plus.

Remettre du style est un petit travail si vous en voulez : un bloc <Style> avec une couleur et une épaisseur de <LineStyle> près du haut du document, et un styleUrl sur chaque repère qui doit l’utiliser. Google Earth le fait aussi de manière interactive — ouvrez le KML, changez l’apparence dans la boîte de dialogue des propriétés, et enregistrez le lieu, ce qui écrit le style dans le fichier à votre place.

Les logiciels qui prétendent lire du KML varient énormément dans la quantité qu’ils en implémentent réellement, et les refus se regroupent autour d’une courte liste : un <Schema> avec des champs <ExtendedData> typés, une géométrie dans l’espace de noms gx: que le lecteur ne reconnaît pas, un <NetworkLink> qu’il ne suivra pas, un <StyleMap> pointant vers une icône qui n’est pas dans l’archive. N’importe lequel d’entre eux peut produire un message d’erreur qui n’en nomme aucun.

La sortie normalisée ne contient rien de tout cela — un seul espace de noms, deux types de géométrie, des noms et des coordonnées, et aucune référence à quoi que ce soit d’extérieur au fichier. C’est la substance de ce que cette conversion offre par rapport à la décompression à la main de l’archive, et c’est la raison de l’essayer quand un import a échoué pour des raisons que personne ne peut pointer. Si le document réécrit se charge alors, le problème était dans les parties qui ont été abandonnées, ce qui est un diagnostic en soi et prend une minute à atteindre.

L’archive est décompressée, analysée et réécrite dans cet onglet de navigateur. Rien n’est transmis, ce que l’onglet réseau montre pendant qu’une conversion tourne, et la page continue de fonctionner sans connexion une fois chargée.

C’est la réponse pratique à un embarras fréquent. Un KMZ d’un client, d’un sous-traitant ou d’un organisme public arrive souvent avec des conditions sur l’endroit où il peut être stocké, et la façon la plus rapide d’en regarder l’intérieur est généralement un outil web qui les enfreindrait sans que personne s’en aperçoive. Le faire dans le navigateur signifie qu’il n’y a aucun tiers dans la chaîne et aucun accord de traitement à aller chercher avant de pouvoir lire votre propre pièce jointe.