Por qué deberías dejar de servir GeoTIFF clásicos y empezar a usar COG

Un error que se comete con cierta frecuencia en webmapping es utilizar los archivos raster (tif) de trabajo para crear el mapa web. El GeoTIFF es un formato de éxito que ha sido (y es) ampliamente utilizado por sus muchas virtudes. Para muchos propósitos sigue siendo un formato eficaz pero hay contextos donde es mejor sustituirlo por COG por varias razones que trataremos de exponer en este artículo. Aquí vamos a establecer una comparativa GeoTIFF vs COG orientada a webmapping, por lo que crearemos un archivo COG a partir de un TIFF y los insertaremos en un mapa web para ver su comportamiento.

Idea clave: COG no es un formato nuevo, es una forma correcta de construir un GeoTIFF.

Por qué deberías dejar de servir GeoTIFF clásicos y empezar a usar COG

Crear un archivo COG a partir de un GeoTIFF utilizando script de Python

Una forma sencilla de convertir GeoTIFF a COG es utilizando GDAL que lo podemos utilizar mediante Python y para más comodidad se pueden escribir los script en un cuaderno de Google Colab. Aquí vamos a utilizarlo partiendo de un archivo TIF que tenemos alojado en Google Drive por lo que todo es más simple y no requiere de instalaciones. Tan solo debemos instalar GDAL en Google Colab lo cual hacemos en la primera celda de nuestro cuaderno.

!apt-get update -qq
!apt-get install -y gdal-bin python3-gdal

Comprobamos la instalación:

!gdalinfo --version

Esto nos devolverá un mensaje con la versión de GDAL instalada.

Comenzamos a realizar el trabajo definiendo las rutas a los archivos, que como hemos dicho estás alojados en Google Drive y creando un archivo temporal

from pathlib import Path
import subprocess

input_tif = Path("/content/Tu_ruta/Datos/TCI.tif")
output_cog = Path("/content/Tu_ruta/Datos/TCI_COG.tif")

temp_tif = output_cog.with_suffix(".temp.tif")

with_suffix nos está creando un archivo temporal que al terminar el proceso eliminaremos, pero de esta forma nos aseguramos trabajar sin corromper el archivo final si algo falla.

La conversión a COG se suele hacer en tres fases o «subprocesos» para garantizar su conformidad:

Primer subproceso: Preparar el GeoTIFF

subprocess.run([
    "gdal_translate", str(input_tif), str(temp_tif),
    "-of", "GTiff",
    "-co", "TILED=YES",
    "-co", "COMPRESS=DEFLATE",
    "-co", "PREDICTOR=2",
    "-co", "BIGTIFF=YES"
], check=True)

TILED=YES. Divide el archivo en bloques (tiles).
COMPRESS=DEFLATE. Compresión sin pérdida.
PREDICTOR=2. Mejora la compresión para imágenes continuas.
BIGTIFF=YES. Permite archivos > 4GB.

Segundo subproceso: crear las pirámides

subprocess.run([
    "gdaladdo",
    "-r", "average",
    temp_tif,
    "2", "4", "8", "16", "32", "64"
])

Tercer subproceso: Convertir en COG

subprocess.run([
    "gdal_translate", str(temp_tif), str(output_cog),
    "-of", "COG",
    "-co", "COMPRESS=DEFLATE",
    "-co", "PREDICTOR=2"
], check=True)

Este subproceso reorganiza todo el archivo: sitúa las cabeceras al principio, ordena los bloques e integra overviews correctamente.

El resultado de estos subprocesos es que tendremos nuestro archivo COG. Nos quedaría eliminar el archivo temporal que habíamos definido al principio.

temp_tif.unlink()
print("✅ COG creado correctamente")

Como puedes observar, además de eliminar el archivo temporal hemos añadido un texto para dar feedback al usuario.

Resumiendo, los pasos que hemos llevado a cabo son:

Crear GeoTIFF optimizado.
Generar overviews.
Convertir a COG.
Borrar temporal → temp_tif.unlink()
Avisar éxito.

Características de COG: overviews (pirámides)

Una vez que hemos construido nuestro archivo COG podemos seguir utilizando Python para ver sus características.

!gdalinfo /content//drive/MyDrive/machine-learning/Datos/TCI_COG.tif

Al ejecutar esta sentencia obtenemos una respuesta que nos proporciona información sobre el archivo:

Driver: GTiff/GeoTIFF
Files: /content//drive/MyDrive/machine-learning/Datos/TCI_COG.tif
Size is 5490, 5490
Coordinate System is:
PROJCRS["WGS 84 / UTM zone 30N",
    BASEGEOGCRS["WGS 84",
        DATUM["World Geodetic System 1984",
            ELLIPSOID["WGS 84",6378137,298.257223563,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4326]],
    CONVERSION["UTM zone 30N",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",-3,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",0.9996,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["Navigation and medium accuracy spatial referencing."],
        AREA["Between 6°W and 0°W, northern hemisphere between equator and 84°N, onshore and offshore. Algeria. Burkina Faso. Côte' Ivoire (Ivory Coast). Faroe Islands - offshore. France. Ghana. Gibraltar. Ireland - offshore Irish Sea. Mali. Mauritania. Morocco. Spain. United Kingdom (UK)."],
        BBOX[0,-6,84,0]],
    ID["EPSG",32630]]
Data axis to CRS axis mapping: 1,2
Origin = (254880.000000000000000,4000020.000000000000000)
Pixel Size = (10.000000000000000,-10.000000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=DEFLATE
  INTERLEAVE=PIXEL
  LAYOUT=COG
  PREDICTOR=2
Corner Coordinates:
Upper Left  (  254880.000, 4000020.000) (  5d43'23.90"W, 36d 6'50.15"N)
Lower Left  (  254880.000, 3945120.000) (  5d42'23.15"W, 35d37'10.20"N)
Upper Right (  309780.000, 4000020.000) (  5d 6'49.64"W, 36d 7'34.47"N)
Lower Right (  309780.000, 3945120.000) (  5d 6' 2.46"W, 35d37'53.73"N)
Center      (  282330.000, 3972570.000) (  5d24'39.79"W, 35d52'23.54"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
  NoData Value=0
  Overviews: 2745x2745, 1373x1373, 687x687, 344x344, 172x172, 86x86
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
  NoData Value=0
  Overviews: 2745x2745, 1373x1373, 687x687, 344x344, 172x172, 86x86
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
  NoData Value=0
  Overviews: 2745x2745, 1373x1373, 687x687, 344x344, 172x172, 86x86

Como se puede observar nos proporciona información sobre los sistemas de coordenadas utilizados, las bandas que contiene la imagen, los límites… y algunas otras cosas interesantes que merecen comentarse.

La línea LAYOUT=COG, nos confirma que se trata de un COG real, es decir que la conversión está bien hecha.

Block=512×512 nos indica que la imagen está dividida internamente en bloques de 512×512 píxeles, lo que permite que el servidor lea solo los bloques necesarios.

Overviews

Y llegamos a un aspecto clave de COG, por el que habíamos pasado de puntillas ,que son las pirámides u overviews.

Overviews: 2745×2745, 1373×1373, 687×687, 344×344, 172×172, 86×86

Estas resoluciones están relacionas con los valores que definimos al crear el COG. Si recuerdas establecimos estos valores: «2», «4», «8», «16», «32», «64», por lo tanto nuestro COG contiene la imagen original completa + 6 niveles de detalle.

Nivel	Resolución
1/2	2745×2745
1/4	1373×1373
1/8	687×687
1/16	344×344
1/32	172×172
1/64	86×86

De aquí podemos extraer la idea principal de COG. Se trata de archivos raster optimizados y por lo tanto más eficientes que contienen la imagen original y otras «copias» a diferentes resoluciones. Es un concepto diferente a los tiles o teselas en que la imagen se divide en partes. En las overviews se mantienen copias completas de la imagen, pero con menos píxeles. Por ejemplo si una imagen original contiene 10.000 × 10.000 píxeles un Overview 1/2 contiene 5.000 × 5.000 píxeles. La extensión geográfica es exactamente la misma solo cambia la resolución espacial. Como consecuencia cada píxel representa un área 4 veces mayor.

GeoTIFF vs COG

Todo esto que estamos viendo tiene el objetivo de explicar por qué el rendimiento de COG es mejor que el de GeoTIFF y por lo tanto es el formato que debemos utilizar en los proyectos de webmapping. Entonces vamos a probar la misma imagen de las dos formas para ver cómo se comporta en cada caso.

Lo primero que podemos observar es que el archivo COG es más grande que el archivo TIFF original, esto puede parecer una contradicción pues estamos diciendo que COG ofrece mejor rendimiento. La explicación es que COG, contiene copias a diferentes niveles niveles de la imagen, por lo tanto es más pesado. Lo que sucede es que cuando desde una aplicación web el cliente solicita la imagen TIFF original, esta se sirve al completo, mientras que COG solo nos proporciona la imagen al nivel solicitado y por lo tanto con mejor rendimiento.

Para comprobarlo hemos subido ambas imágenes a GeoServer y luego hemos construido un mapa con Leaflet que contiene dos vistas, una a la imagen TIF original y otra con COG.

Si realizas la prueba comprobarás que el renderizado de la imagen COG optimizado es más rápido que la imagen TIF original. Sin embargo aquí se produce una paradoja. La primera vez que realices esta prueba observarás lo que hemos indicado. Pero (si al mismo nivel de zoom) repites la operación puede darse la circunstancia de que suceda lo contrario, que el TIF original se cargue más rápido que COG. Esto tiene una explicación que se basa en cómo funciona webmapping a nivel interno. Cuando «recargamos» la imagen, GeoServer utiliza el cacheado de la imagen, posibilidad que no tenía en la primera petición.

El cacheado hace que la ventaja competitiva inicial que tenía COG ya no se cumpla y por tanto los rendimientos se igualan. Esto se da en una prueba local como esta, pero en unas condiciones reales, es decir, en un servidor público con múltiples peticiones concurrentes las ventajas de COG son notorias.

Siguiendo la comparación podemos reparar en otra contradicción. La imagen COG es menos nítida, tiene «menos calidad» que la imagen TIF original. En la vista que hemos incluido en este artículo puede no apreciarse correctamente esta diferencia pero si replicas la prueba lo puedes comprobar. Esto tiene relación con lo que estamos explicando en relación a los niveles de resolución u overviews. La imagen tif se carga al completo y con su resolución inicial. En COG hemos visto que la resolución se establece en niveles agrupándose pixels.

Esto no quiere decir que COG sea de peor calidad. Lo que hace, para explicarlo de otra forma, es adaptar la resolución al nivel de zoom o dicho de otro modo a lo que el cliente necesita en cada momento. Pero si nos vamos acercando la resolución aumenta hasta llegar al original, púes COG también lo conserva.

Tratamos de resumirlo en esta tabla:

Conclusiones

Aunque las generalizaciones no son buenas, podemos decir que si vas a publicar imágenes raster en una página web debes utilizar COG. Con esto no queremos decir que TIF no sea un formato válido. Ha sido y seguirá siendo utilizando en SIG de forma masiva. Para muchos flujos de trabajo offline el GeoTIFF clásico sigue siendo perfectamente adecuado e incluso preferible en algunos casos. El TIF clásico nos permite trabajar con la imagen completa lo que es necesario cuando tenemos que hacer labores de procesamiento o cálculo matemático, como filtros o clasificación. En ese caso COG no aporta ventajas.

Jose Luis García Grandes

Tutor del curso online de Análisis GeoEspacial con Python y de los cursos online de webmapping. Echa un vistazo a todos nuestros cursos de SIG online.