El KMZ no abre: leé el aviso, después arreglá el archivo

Respuesta corta: un KMZ es un archivo KML dentro de un zip, así que el paquete solo puede ser una de cuatro cosas, el visor dice cuál, y tres de las cuatro se arreglan con un comando. El caso que agarra a más gente es el paquete renombrado — el archivo está bien, y el nombre no.

Probado el 2 de octubre de 2026 en el visor de KMZ, en los tres idiomas de la interfaz, con todos los archivos de prueba armados a partir de los comandos del final de este post. Toda cadena citada abajo es la de la propia herramienta. Cada caso de acá muestra o un aviso rojo y ninguna capa, o una capa con la línea de conteos y ningún aviso — nunca las dos cosas, así que la pantalla ya te dice en qué mitad de este post estás.

Un KMZ es un zip, así que leé primero el listado

unzip -l site.kmz es el primer movimiento, y la guía de KML y KMZ dice lo mismo, en la sección "Abrir y visualizar un KMZ en línea sin Google Earth". Este post es qué hacer con cada una de sus cuatro respuestas: una entrada KML bajo un nombre .kmz, una entrada KML bajo cualquier otro nombre, ninguna entrada KML, o un listado que falla porque la cosa no es un paquete.

El control de todo lo que viene abajo es un paquete armado a mano: un doc.kml con un punto, una línea y un polígono, zipeado con zip -X site.kmz doc.kml. Abre sin ningún aviso, el panel de capas muestra 1 polígono · 1 línea · 1 punto, y la capa viene rotulada con el nombre de documento del propio KML, no con el nombre del archivo. Esa es la cara de un éxito — una línea de conteos, nada en rojo.

El .zip renombrado: decide el nombre, no los bytes

Copiá ese mismo paquete a un segundo nombre con cp site.kmz site.zip y tenés dos archivos byte a byte idénticos. El .kmz abre. El .zip es rechazado, y el aviso dice Este ZIP contiene un archivo KML. Cámbiale el nombre a .kmz, o extrae el .kml, y cárgalo de nuevo.

Es todo eso: el cargador decide qué es un archivo por la extensión antes de que algo lea un byte, y .zip quiere decir shapefile zipeado. Entonces tu paquete se va al parser de shapefile, que lo rechaza — no hay ningún .shp ahí dentro. Pero lo que leés no es la queja de ese parser: habiendo sido rechazado, el visor reabre el paquete, ve que sí contiene un KML, y reformula el rechazo como el arreglo que necesitás. El archivo sigue rechazado; la frase es sobre tu archivo, y no sobre shapefiles.

Es el nombre el que hace todo ese trabajo, y eso queda más claro visto del otro lado. El cargador tiene una segunda puerta de entrada — traer un archivo a partir de un enlace — y no pasa ningún nombre de archivo adelante: inventa uno, remote.kmz cuando el enlace termina en .kmz o cuando la respuesta se declara un zip, y después llama al mismo despacho. Los mismos bytes serían aceptados bajo el nombre inventado y rechazados bajo el tuyo, así que la rama del .zip es inalcanzable por ese camino. Un despacho, dos puertas de entrada, un nombre que nadie eligió. Esa inconsistencia es nuestra y está en nuestra lista, en vez de arreglada; y tampoco es una salida, porque el visor no tiene campo donde pegar un enlace. Corregir el nombre es el arreglo.

Un zip sin ningún KML dentro

Armá uno con zip -X nokml.kmz readme.txt y soltalo en el visor. El aviso dice No se encontró ningún archivo KML dentro del ZIP.

Este se llama .kmz, así que el camino del KMZ sí corrió: el paquete abrió, el visor recorrió las entradas, y no había nada para interpretar. El aviso anterior puede ser más específico porque allá sí encontró algo.

Un KML anidado abre, y eso sorprende a la gente

Poné el KML en cualquier lugar que no sea la raíz — mkdir layers && cp doc.kml layers/site.kml && zip -X nested.kmz layers/site.kml — y el paquete no tiene ningún doc.kml ni ninguna entrada a nivel de la raíz. Abre. Ningún aviso, la misma línea de conteos 1 polígono · 1 línea · 1 punto, el mismo nombre de documento en la capa.

La regla que aplica el visor es la primera entrada cuyo nombre termina en .kml, en cualquier lugar del paquete, abajo de la raíz o no, pasada a minúsculas antes de ese test, así que DOC.KML también abre. Un doc.kml en la raíz del paquete es una convención — la de Google Earth, y una buena costumbre para un archivo que le pasás a otra persona — no algo que este visor exija. Si tu KMZ fue rechazado, la profundidad a la que está el KML no es el motivo.

No es un zip, o no es una extensión que el visor conozca

head -c 512 /dev/urandom > broken.kmz crea un archivo con nombre de KMZ y ningún paquete dentro. El aviso dice Error al procesar el archivo. Verifica que sea un KML o KMZ válido. Una descarga truncada cae acá, y también cae una página de error que el servidor devolvió con el nombre que pediste: file broken.kmz responde data en vez de nombrar un paquete zip, y unzip -l sobre él falla de entrada.

Copiá esos mismos bytes a broken.dat, o a un nombre sin ninguna extensión, y la respuesta cambia a Tipo de archivo no compatible. Usa KML o KMZ. Nada leyó los bytes esta vez: la extensión se chequea dos veces, una para elegir el parser y otra adentro del camino del KML, y una que ninguno de los dos chequeos reconoce es rechazada antes de cualquier intento de interpretación.

Cómo arreglarlo, de tres maneras

• Renombralo de vuelta: mv site.zip site.kmz, y después soltalo de nuevo en el visor. Para un paquete renombrado ese es el arreglo entero.
• Rearmá el paquete: zip -X site.kmz doc.kml, desde el directorio que contiene el KML. Usá esto cuando el zip vino de algún lugar que no controlás.
• Saltate el contenedor: unzip -o site.kmz '*.kml' y cargá el .kml extraído en su lugar. El visor acepta un KML puro, y unzip ignora el nombre del paquete, así que esto funciona también en el archivo renombrado.

Ninguno de esos convierte nada, porque ninguna de estas fallas es sobre el contenido. Para las que sí lo son — atributos perdidos en la lectura, estilos perdidos en la conversión — la sección "Errores, decodificados" de la guía tiene las transcripciones.

Archivos de prueba que podés usar

Nada está hospedado; cada archivo de prueba es uno o dos comandos. Armá primero el KML, como un doc.kml en UTF-8: <?xml version="1.0" encoding="UTF-8"?>, después <kml xmlns="http://www.opengis.net/kml/2.2"><Document><name>KMZ test</name>, después los tres placemarks, después </Document></kml>. Las coordenadas son grados decimales a propósito.

• <Placemark><name>P1</name><Point><coordinates>-46.633,-23.550,0</coordinates></Point></Placemark>
• <Placemark><name>L1</name><LineString><coordinates>-46.64,-23.55,0 -46.63,-23.54,0</coordinates></LineString></Placemark>
• <Placemark><name>A1</name><Polygon><outerBoundaryIs><LinearRing><coordinates>-46.65,-23.56,0 -46.64,-23.56,0 -46.64,-23.55,0 -46.65,-23.56,0</coordinates></LinearRing></outerBoundaryIs></Polygon></Placemark>

Después los seis paquetes, en orden: el control, zip -X site.kmz doc.kml · los mismos bytes bajo un segundo nombre, cp site.kmz site.zip · un paquete sin ningún KML dentro, printf 'no KML here\n' > readme.txt && zip -X nokml.kmz readme.txt · un KML abajo de la raíz, mkdir layers && cp doc.kml layers/site.kml && zip -X nested.kmz layers/site.kml · algo que no es un paquete, head -c 512 /dev/urandom > broken.kmz · y ese mismo no-paquete bajo una extensión desconocida, cp broken.kmz broken.dat. Fijate en uno antes que nada: unzip -l nested.kmz lista una única entrada, layers/site.kml.

Para equipos

"El KMZ no abre" suele ser un problema de traspaso, y no un problema de archivo: el paquete fue renombrado para pasar un filtro de correo, o rearmado por una herramienta que movió el KML de lugar, y quien tiene que abrirlo no es quien lo hizo. Geodocs mantiene los datos de campo en un único mapa compartido, en vez de un KMZ por celular, así que no hay paquete para renombrar ni nada para zipear de nuevo.