Convertir KML en KMZ

Le KMZ a été conçu pour résoudre un problème d’empaquetage. Un KML qui utilise des images d’épingle personnalisées, une incrustation photo ou un scan géoréférencé fait référence à ces fichiers par chemin relatif, et à l’instant où le document est envoyé par courriel seul, les références cassent et la carte arrive vide. Regrouper le document et ses assets dans une seule archive règle cela, et c’est la raison pour laquelle le format existe.

La seconde raison est plus simple : un KML est du texte verbeux et le texte se comprime. Si votre document n’a pas d’assets externes — un jeu d’épingles, un itinéraire dessiné, un export depuis une base de données — alors l’empaquetage n’est pas ce que vous achetez, la taille, si. C’est le cas que cette conversion dessert, et elle le dessert bien, mais cela vaut la peine de nommer laquelle des deux vous cherchez avant de convertir.

Mesuré sur un KML contenant une seule polyligne de 7 200 sommets avec altitude à chaque point, le document faisait environ 258 ko et l’archive environ 47 ko — un facteur cinq et demi. Les listes de coordonnées sont proches du cas idéal pour un deflate : chaque entrée partage un préfixe avec la précédente, les séparateurs se répètent indéfiniment, et les chiffres qui varient se trouvent dans les positions basses.

Un document fait de nombreuses courtes épingles se comprime moins bien, parce que le ratio est dominé par le balisage répété des éléments plutôt que par les nombres, et un document qui est surtout de la prose en description se comprime comme de la prose. Aucune de ces distinctions ne change la décision beaucoup, mais la garantie est plus étroite qu’elle n’en a l’air. L’auteur garde la forme non compressée quand le deflate n’aide pas, donc la charge utile ne grandit jamais — c’est la structure ZIP autour qui le fait. Un en-tête local, une entrée de répertoire central et l’enregistrement final coûtent 112 octets pour un fichier nommé doc.kml, et le KML à l’intérieur est réécrit plutôt que copié octet pour octet, donc un très petit document peut sortir un peu plus gros qu’il n’est entré. Au-dessus de quelques kilooctets c’est du bruit.

C’est la partie à comprendre avant de convertir. La conversion ne prend pas votre KML et le zippe. Elle analyse le document dans la même forme interne par laquelle passent tous les formats GPS de ce site — des points avec une position, une altitude optionnelle, un temps optionnel, groupés en lignes et épingles nommées — et écrit un KML neuf à partir de cette forme, qu’elle compresse ensuite.

La conséquence est que le KML à l’intérieur de l’archive n’est pas octet-identique au vôtre, et dans la plupart des cas n’est même pas proche. Il sera plus court, ses éléments seront dans un ordre différent, et tout ce que la forme interne n’a pas de place pour accueillir sera absent. Si vous dézippez le résultat en vous attendant à y trouver votre propre fichier, vous n’y trouverez pas votre fichier : vous y trouverez un document propre et minimal qui décrit la même géométrie.

Précisément : les définitions `<Style>` et `<StyleMap>` et les références `styleUrl` qui pointent vers elles, donc les couleurs de ligne, les épaisseurs et les icônes personnalisées sont parties. Les ballons `<description>`, y compris tout HTML qu’ils contiennent. `<ExtendedData>` et les champs personnalisés typés par schéma, là où vit en général tout ce qui vient d’une base de données. Le groupement par `<Folder>`, puisque la forme interne a une seule liste plate. `<LookAt>` et `<Camera>`, donc la vue que l’auteur avait choisie n’est pas restaurée. `<NetworkLink>`, `<GroundOverlay>` et `<ScreenOverlay>` entièrement.

Ce qui survit est la géométrie et les étiquettes : chaque Point devient un Placemark avec un Point, chaque LineString et gx:Track devient un Placemark avec une LineString, et chacun garde le `<name>` qu’il avait. Le nom du document est porté. Pour un fichier dont le contenu est où sont les choses et comment elles s’appellent, c’est tout. Pour une carte de présentation stylée, c’est une petite fraction, et la section qui suit est la meilleure voie.

Si le KML porte un stylisme ou des descriptions dont vous avez besoin, l’empaquetage fidèle est celui que vous faites à la main. Renommez votre document en `doc.kml`, ajoutez-le à une archive ZIP pour qu’il se trouve à la racine plutôt qu’à l’intérieur d’un dossier, et renommez l’archive de `.zip` en `.kmz`. Chaque système d’exploitation peut faire les deux étapes sans logiciel supplémentaire, et le résultat est un KMZ dont le document est votre document, inchangé.

La position à la racine est le détail que les gens ratent. Un KMZ dont le KML se trouve un répertoire plus bas s’ouvre dans certains lecteurs et échoue silencieusement dans d’autres, et l’échec ressemble à une carte vide plutôt qu’à une erreur. Si vous avez construit l’archive en cliquant-droit sur un dossier, c’est ce qui s’est passé — sélectionnez le fichier lui-même, pas le dossier autour.

Un `<NetworkLink>` est un KML qui ne contient aucune donnée : il porte une URL et des instructions pour la rafraîchir, et tout ce que vous voyez en l’ouvrant a été récupéré depuis un serveur après le chargement du fichier. Les couches de trafic en direct, les jeux de données par abonnement et les cartes partagées d’équipe sont tous construits ainsi, et le fichier sur disque ne fait souvent que quelques kilooctets.

Passé à cette conversion, un tel fichier ne donne ni épingle ni ligne, et le résultat est le message indiquant qu’aucune trace ni waypoint n’a été trouvé. C’est le résultat correct plutôt qu’un échec d’analyse, et cela vous dit quelque chose d’utile : la carte que vous regardiez n’a jamais été dans le fichier, donc il n’y a rien à compresser localement et aucune copie hors ligne à faire. Télécharger la ressource liée est la seule manière d’obtenir les données elles-mêmes.

Google Earth, en enregistrant un KMZ, parcourt le document à la recherche de chaque asset référencé et copie chacun d’eux dans l’archive, en réécrivant les chemins au passage. Cette étape de collecte est le fond de ce que fait un outil d autoría KMZ, et cette conversion ne s’y essaie pas.

La sortie contient un document et aucun asset, donc un KML qui référence des fichiers d’icônes locaux produit une archive plus petite que prévu et incomplète comme paquet. Comme le stylisme qui les référençait a de toute façon été supprimé pendant la réécriture, les deux limitations s’annulent en un résultat cohérent plutôt qu’un fichier à moitié cassé : ce que vous obtenez est de la géométrie simple, dessinée avec l’apparence par défaut du lecteur, et rien qui pendouille.

La compression n’est pas la seule manière de rendre un gros KML gérable, et c’est parfois la mauvaise. Un document de 40 Mo qui est lent dans Google Earth est lent à cause du nombre d’entités qu’il dessine, et le zipper à 7 Mo change le temps de transfert et rien du rendu — il se décompresse dans les mêmes 40 Mo avant que quoi que ce soit n’apparaisse.

Si le problème est la performance plutôt que le transfert, les correctifs sont structurels : découper le fichier par région ou par couche pour que chacun se charge seul, éclaircir les lignes denses qui portent un sommet tous les mètres, ou faire passer les données dans un format conçu pour le volume. Si le problème est vraiment qu’un courriel ne transportera pas la pièce jointe ou qu’un formulaire d’envoi a un plafond, l’archive est exactement la bonne réponse et cette conversion est le moyen le plus rapide de l’obtenir.

Reconvertir l’archive en KML ensuite rend le document minimal, et non le fichier dont vous étiez parti. La réécriture s’est faite à l’aller, et rien en aval ne peut restaurer un bloc de style, un ballon de description ou un champ personnalisé qui a été écarté avant que le zip ne soit écrit. Les deux conversions se composent en une étape destructrice plutôt que de s’annuler.

C’est la raison pratique de garder l’original plutôt que de traiter l’archive comme son remplacement. Le stockage n’est pas la contrainte — le document source est le plus gros des deux d’un facteur cinq et se compte encore en centaines de kilooctets — et c’est la seule copie qui porte le stylisme, la structure de dossiers et les champs de base de données. Traitez le KMZ comme vous traiteriez un PDF exporté depuis un document : la chose que vous remettez, pas la chose que vous maintenez.

Le document est analysé, réécrit et zippé dans cet onglet de navigateur. Aucune requête ne le porte ailleurs, ce qui peut être confirmé dans le panneau réseau pendant une conversion, et la page continue de fonctionner avec la connexion coupée.

Cela vaut plus que d’habitude pour cette paire en particulier, parce que l’alternative évidente est un site web de compression de fichiers. Un KML de sites, clients, actifs ou propriétés est une donnée métier avec des emplacements attachés, et la route habituelle pour le rendre plus petit implique de le remettre au serveur d’un inconnu, d’attendre, et de le recharger. Faire le zip localement supprime ce détour plutôt que de vous demander d’être à l’aise avec.