Dos números, 4326 y 32718, son la diferencia entre ver tu bosque en el mapa o verlo flotando en medio del océano Pacífico. El primero es el código EPSG del sistema WGS 84, el que usa grados de latitud y longitud y que trae por defecto casi cualquier GPS de celular. El segundo es la zona UTM 18S, la que le corresponde al sur de Chile, con coordenadas en metros. Si mezclas datos que vienen en uno con datos que vienen en el otro sin avisarle a R cuál es cuál, la teledetección en R deja de ser un método de análisis y se convierte en una fuente de dolores de cabeza: las proyecciones cartográficas que no calzan son, con diferencia, el error más común y más silencioso de quien recién empieza.
Antes de seguir, vale la pena aclarar algo: hablar de proyecciones no tiene mucho sentido si todavía no sabes, técnicamente, qué es la imagen satelital que estás moviendo. Si ese es tu caso, conviene partir por leer archivos raster en RStudio para principiantes, porque ahí se explica qué es un raster antes de intentar transformarlo. Acá voy a asumir que ya tienes tus capas cargadas —un shapefile de puntos, un raster de Sentinel-2— y que el problema es que no se hablan entre sí.
¿Por qué el CRS manda sobre cualquier otro dato?
El sistema de referencia de coordenadas, o CRS, es la base de cualquier operación espacial, y es el único tema de este texto que me voy a permitir explicar a fondo. La regla es simple y no tiene excepciones: antes de cruzar, sumar o comparar dos objetos espaciales, ambos tienen que compartir el mismo CRS. Si mezclas un shapefile en WGS 84 con un raster en UTM sin decirle a R que traduzca uno al sistema del otro, el resultado casi nunca es un error rojo y evidente: muchas veces es un mapa vacío, o algo peor todavía, un mapa que parece correcto pero que mide mal cada distancia y cada área. Ahí está lo traicionero del asunto: no siempre suena una alarma, a veces solo obtienes un resultado equivocado con toda la confianza del mundo.
La primera vez que me topé con esto de verdad fue con un set de puntos de muestreo que marqué un sábado con el GPS del celular, caminando por el Parque Saval, en Isla Teja, más una imagen de Sentinel-2 descargada esa misma semana. Le pedí a R que graficara ambas capas juntas y lo que apareció fue un fondo blanco casi completo: mis puntos quedaron en una esquina del gráfico y la imagen en otra, separados por una distancia sin ningún sentido geográfico. Antes de eso ya había probado aprender QGIS siguiendo un tutorial, pero me perdí en los menús desde el primer clic, así que volví a R con más dudas que certezas.
Paquetes R-spatial: sf, terra y el idioma común que necesitan hablar
En R, el paquete sf maneja los objetos vectoriales —puntos, líneas, polígonos— mientras que terra se encarga de los raster, o sea, de las imágenes de satélite en sí. Cada uno guarda el CRS de forma distinta, pero ambos responden a los mismos códigos EPSG, así que una vez que entiendes la lógica de uno, el otro deja de ser un misterio. Dentro de este mundo R-spatial existen otros paquetes espaciales, cada uno pensado para un problema distinto, pero esa comparación completa da para otro texto aparte.
st_transform() o project(): cómo decidir cuál usar
La pregunta que hay que hacerse es simple: ¿qué objeto necesito mover, el vector o el raster? Si es un objeto vectorial —tus puntos de muestreo, un polígono de área de estudio— la función es st_transform(), del paquete sf: le pasas el objeto y el CRS de destino, y listo. Si en cambio necesitas mover la imagen satelital, la función correspondiente es project(), del paquete terra. Da lo mismo qué tan enredada se vea la sintaxis alrededor: la decisión de fondo es esa, vector o raster, y una vez que la tienes clara, el resto es buscar la sintaxis exacta en la documentación.
La regla que le baja la fiebre a tu computador: no reproyectes de más
Aquí hay un error técnico que cometí más de una vez sin darme cuenta: reproyectar un raster no es una operación gratuita. Cada vez que fuerzas a una imagen satelital a cambiar de sistema, R tiene que recalcular el valor de cada píxel —interpolarlo— y ese cálculo consume memoria y, en alguna medida, calidad. Mi regla desde entonces es trabajar con la capa más pesada en su sistema original y mover, en cambio, las capas livianas —los puntos, los polígonos— hacia ese mismo sistema. Solo reproyecto el resultado final si de verdad necesito exportarlo para otra cosa.
Con esa regla aplicada, el mismo cruce de capas que antes me devolvía un mapa vacío terminó mostrando algo que sí reconocía: el borde del bosque coincidiendo, sin desfases, con el trazado de una carretera que me sé de memoria de tanto pasar en auto. Ninguna alarma roja, ningún mensaje de error, solo el mapa haciendo lo que se supone que tiene que hacer.
Antes de cruzar cualquier capa, revisa esto
Con el tiempo armé una rutina corta que reviso antes de cualquier análisis: primero, confirmar el CRS de cada objeto por separado, con st_crs() para lo vectorial o crs() para lo raster, sin asumir nada por el nombre del archivo. Segundo, fijarme si los números son chicos —algo como -39, en grados— o gigantes —algo como 5580000, en metros—, porque esa diferencia de escala ya avisa si estás mezclando sistemas antes de que R tire el primer error. Tercero, mover siempre la capa liviana hacia el sistema de la pesada, nunca al revés. Y cuarto, anotar el código EPSG correcto en algún lado —arriba del script, en un cuaderno, donde sea— antes de seguir con cualquier otro paso del análisis.
Raimundo, un conocido de las salidas de senderismo, una vez me preguntó —con ese tono de escéptico amable que tiene— para qué servía tanto lío con números si al final el mapa se ve igual de verde. Le respondí que no es lo mismo: un CRS mal puesto no cambia cómo se ve la imagen, cambia si lo que estás midiendo es real. Sin las capas alineadas, cualquier cálculo de superficie, de distancia o de cambio en el tiempo queda construido sobre un supuesto falso, aunque el mapa en pantalla se vea perfectamente normal.
Quien llega hasta acá sin venir de geografía ni de programación puede quedarse tranquilo: este aprendizaje autodidacta se arma de a poco, sin curso formal de por medio, y ya conté ese proceso completo en mi experiencia aprendiendo teledetección con R sin ser programadora. Una vez que el CRS deja de ser un problema, se abren varias puertas: calcular el índice NDVI a partir de las bandas espectrales de Sentinel-2, recortar un raster con el shapefile de tu zona de estudio, o incluso avanzar hacia el modelado de distribución de especies con Maxent. Ninguna de esas cosas funciona si las capas de partida no están, primero, hablando el mismo idioma de coordenadas.
Quédate con una sola idea de todo esto: revisa el CRS antes de cualquier otra cosa, no después de que el mapa salga mal. Cuesta un segundo comprobarlo con código y ahorra tardes enteras tratando de entender por qué tu bosque terminó en medio del océano.