La lluvia golpeaba fuerte los vidrios de la ventana del living, con ese sonido constante y pesado del invierno acá en el sur, mientras una barra de progreso naranja avanzaba a paso de tortuga en la consola de RStudio. Llevaba más de una hora peleando con descargas manuales para mapear las laderas detrás de Niebla y lo único que tenía era un cuadrado gris plano en la pantalla.
Si alguna vez intentaste bajar un modelo digital de elevación navegando por portales llenos de menús confusos, seguro conoces esa sensación. Terminas con tres archivos zip gigantescos de cien megas en la carpeta de descargas, los descomprimes, cargas el archivo .tif en R y te das cuenta de que tu zona de estudio justo cae en la esquina de cuatro cuadrículas distintas. Y ninguna coincide bien con los límites que necesitabas.
Ese domingo en la tarde, aburrida de lidiar con clics manuales, decidí probar si R podía encargarse de todo el trámite directo desde el código, sin intermediarios ni descargas pesadas que después no sabía cómo unir.
La fricción de los portales y la alternativa directa en consola
Antes de meterme a escribir funciones para descargar elevación, mi rutina era bien rudimentaria (y bastante frustrante, para ser sincera). Entraba a visores internacionales, dibujaba un rectángulo tembloroso con el mouse, esperaba que un servidor al otro lado del mundo preparara los datos y descargaba archivos que mi pobre computador apenas lograba abrir. La mitad de las veces, el relieve que me interesaba quedaba cortado a la mitad.
El punto de quiebre fue entender que existen paquetes diseñados específicamente para consultar estos servidores en segundo plano. En lugar de buscar mosaicos globales a mano, tú le pasas un punto o un polígono delimitador a R y el paquete se encarga de conectar con las APIs correspondientes, descargar únicamente los fragmentos necesarios y devolverte un raster listo para manipular en memoria o guardar en disco.
Para quienes venimos aprendiendo de a poco los fines de semana, este cambio de enfoque ahorra horas de frustración. Si estás dando tus primeros pasos con datos espaciales, como cuando revisamos algunos consejos para aprender R para geografía si no sabes programar, ver que el código hace la búsqueda pesada por ti te devuelve un montón de energía mental para concentrarte en el paisaje real.
El choque entre geodata y elevatr: resoluciones y zooms
Mi primer intento formal fue con la función elevation_30s() del paquete geodata. Es súper amigable porque te pide el código de país (como "CHL" para Chile) y te descarga la altitud general basada en el clásico SRTM, cuya cobertura global se extiende formalmente entre los 60 grados de latitud norte y los 56 grados de latitud sur. El problema es que a escala de cuenca o ladera boscosa, esa resolución de 30 segundos de arco se siente como mirar una foto pixelada de los años noventa.
Ahí fue cuando llegué al paquete elevatr y su función estrella: get_elev_raster(). Este paquete accede a los mosaicos de relieve de AWS (Terrain Tiles), que manejan niveles de zoom del 1 al 14. Y aquí vino mi primera gran metida de pata de principiante.
Como quería ver hasta la última quebrada de los cerros de Niebla, se me ocurrió ponerle un nivel de zoom 14 a todo un polígono que abarcaba la Región de Los Ríos completa. En mi cabeza sonaba lógico: mayor nivel, mayor detalle. En la práctica, vi cómo RStudio se congeló por completo mientras la memoria RAM subía hasta el techo sin piedad. El ventilador del notebook sonaba como despegando y tuve que forzar el cierre del programa perdiendo lo que no había guardado.
library(sf)
library(elevatr)
library(terra)
# Definir el área de interés aproximada en Niebla / Corral
area_interes <- st_as_sf(
data.frame(
lon = c(-73.45, -73.35),
lat = c(-39.90, -39.80)
),
coords = c("lon", "lat"),
crs = "EPSG:4326"
)
# Descargar elevación con un zoom razonable (ej. zoom 10 u 11)
dem_bruto <- get_elev_raster(locations = area_interes, z = 10, clip = "bbox")
dem <- rast(dem_bruto)
Aprendí a porrazos que el zoom 14 está pensado para vecindarios pequeños o quebradas puntuales, no para paisajes comarcales enteros. Para la mayoría de los análisis de relieve mediano, un zoom entre 9 y 11 ofrece un balance impecable entre textura topográfica y velocidad de respuesta sin ahogar la máquina.
El mito de la ultra resolución y el ruido en los mosaicos
Después de unas tres semanas de ensayo y error, revisando salidas raster a distintas horas, me di cuenta de algo que casi ningún tutorial comenta de entrada. Solemos creer que mientras más milimétrico sea el modelo de elevación, mejor va a ser nuestro análisis del paisaje. Pero descargar DEMs de altísima resolución global suele ser una trampa: procesar datos locales más sobrios o directamente brutos es infinitamente más eficiente que pasarse tardes enteras filtrando los artefactos, líneas de unión y ruidos raros que traen los mosaicos interpolados de alta resolución.
Cuando fuerzas un zoom excesivo en capas globales sobre zonas boscosas o costas lluviosas como las nuestras, el modelo a veces confunde la copa irregular de los árboles adultos con la superficie real del suelo, o introduce pequeñas terrazas artificiales donde en realidad hay pendientes continuas. Un modelo con una grilla nominal estándar de 30 metros (1 segundo de arco) bien proyectado y limpio suele representar la hidrología y el relieve local de forma mucho más confiable que una cuadrícula pesada llena de micro-ruido geométrico.
Del raster descargado al mapa de sombras en pocas líneas
Una vez que el DEM aterriza en tu sesión, casi siempre llega en coordenadas geográficas estándar bajo el código EPSG:4326 (WGS84). Si intentas calcular pendientes o sombras directamente sobre grados de latitud y longitud, los cálculos trigonométricos se deforman porque un grado no mide lo mismo en el ecuador que en el sur de Chile.
Hoy en día en R la manipulación espacial moderna se apoya en el paquete terra, dejando atrás la librería antigua raster gracias a su motor en C++ que procesa todo con muchísima más ligereza. El flujo para recortar con tu polígono exacto y generar un sombreado del terreno se resuelve en un bloque compacto:
# 1. Proyectar a UTM local (Huso 18S para esta zona de Chile)
dem_utm <- project(dem, "EPSG:32718")
# 2. Calcular pendiente y orientación del terreno en radianes
pendiente <- terrain(dem_utm, v = "slope", unit = "radians")
orientacion <- terrain(dem_utm, v = "aspect", unit = "radians")
# 3. Generar el mapa de sombras (hillshade)
sombra <- shade(pendiente, orientacion, angle = 45, direction = 315)
# 4. Graficar el relieve sombreado
plot(sombra, col = gray.colors(100, start = 0, end = 1), legend = FALSE)
plot(dem_utm, col = terrain.colors(100, alpha = 0.45), add = TRUE)
Ese truco de montar la capa de elevación semitransparente sobre el sombreado gris cambia radicalmente la manera de mirar el mapa. De pronto los valles fluviales se hunden visualmente en la pantalla y las crestas de la cordillera de la costa adquieren volumen, como si pudieras tocarlas.
Si más adelante combinas estas capas de relieve con series de tiempo satelitales, viene muy bien tener los datos limpios de origen; hace poco recordaba lo que aprendí al quitar nubes de imágenes Landsat en RStudio, donde alinear la máscara con la pendiente adecuada me ahorró confusiones con sombras orográficas.
La satisfacción de mirar la cuenca desde el código
A mitad de invierno, mirando el resultado final en la pestaña de gráficos con una taza de té al lado mientras el viento movía los árboles del patio, sentí ese pequeño alivio que llega cuando las piezas encajan. No necesité abrir programas de escritorio pesados ni lidiar con carpetas llenas de archivos temporales con nombres incomprensibles.
Tener todo el proceso escrito en un script de apenas veinte líneas significa que mañana puedo cambiar las coordenadas a otra cuenca del río Calle-Calle o del lago Ranco, apretar un botón y obtener la topografía en un par de segundos. Aprender esto de a poco, tropezando con zooms descalabrados y proyecciones invertidas, me demostró que no hace falta ser experta en geodesia para empezar a entender el relieve que habitamos.