A veces el mapa de lluvia que armaste en R le regala agua a un cerro que en la vida ha visto una gota de más. Llevo un tiempo dándole vueltas a la interpolación espacial con datos climáticos, ese truco de tomar lo que miden un puñado de estaciones y estirarlo hasta cubrir todos los rincones donde nadie puso jamás un pluviómetro, y hay una idea que casi todo el que recién llega a esto de R y el SIG se cree sin cuestionar: que el mapa que sale al final ya entiende el terreno por el que pasa. No es así, y esa diferencia cambia por completo cómo hay que mirar el resultado antes de confiar en él.
Antes de tocarle una sola línea a RStudio intenté ir por el camino difícil: me puse a buscar artículos científicos sobre teledetección para entender de dónde salía todo esto, y el vocabulario técnico me dejó atascada en la primera página, con más preguntas que cuando empecé. Terminé aprendiendo al revés de como se supone que hay que hacerlo, abriendo la consola y viendo qué pasaba cada vez que escribía una función nueva, que es más o menos como aprendo casi todo lo que sé de este tema los fines de semana.
El mito que nadie te avisa cuando empiezas con SIG
La trampa es esta: consigues tus coordenadas, las metes al programa, corres la función de turno y sale un mapa lleno de colores tan convincente que uno asume que ahí está la realidad. Con el tiempo entendí que ni siquiera hace falta saber leer un raster de memoria para caer en esto (ese es tema aparte, para otro día), porque la sensación de que "ya está resuelto" llega apenas ves algo pintado sobre tu región. Ahí entra Raimundo, un conocido del grupo de senderismo, que cuando le mostré uno de mis primeros mapas de lluvia me preguntó, con esa cara suya de duda de siempre, si eso realmente servía para algo si ni él ni yo sabíamos qué pasaba en el medio.
Meses atrás, calculando un NDVI para otro ejercicio, vi aparecer un parche rojo justo donde yo sabía que estaba el claro de un sendero por el que había caminado en verano, y esa coincidencia entre lo que decía la pantalla y lo que habían pisado mis propias zapatillas se me quedó grabada. Ese dato lo midió el satélite, píxel por píxel, sobre el terreno real. Un mapa de lluvia interpolado no funciona igual: no mide nada nuevo, solo adivina matemáticamente lo que hay entre dos estaciones, y esa es la raíz del mito. Confundir una cosa con la otra es la forma más común de creerle a un mapa interpolado más de lo que se merece.
Ordenar los puntos antes de pintar nada
Dicho el mito, vamos a los pasos de verdad. Tus columnas de latitud y longitud, apenas las subes a R, son solo números para el programa, no lugares en el espacio, así que el primer paso real es convertir ese data frame en un objeto espacial con el paquete sf (si nunca has abierto un raster en RStudio antes de esto, te va a costar un poco más, pero se puede igual). Hay que decirle al objeto que esos números están en el código EPSG para WGS 84, el estándar que usa cualquier GPS, porque si te saltas ese paso los puntos terminan flotando en medio del océano en vez de caer sobre tu región.
Después toca un cambio que a mí me costó entender: para calcular distancias reales hay que dejar los grados de lado y pasar a una proyección local en metros, que para esta zona del sur de Chile es la UTM 18S (el código 32718, si lo quieres anotar). Trabajar en grados para medir distancia es como calcular cuánto café queda mirando el color en vez de pesar la taza: da una idea, pero no sirve para el cálculo fino que necesita la interpolación.
Se necesita un lienzo vacío para estirar los datos climáticos
Con los puntos ya ubicados, hace falta un espacio en blanco sobre el cual proyectar la estimación: en los Sistemas de Información Geográfica le dicen grilla, o raster vacío, y básicamente es una superficie de píxeles que cubre toda tu área de interés. Usé una resolución parecida a la de los datos de WorldClim, unos 30 segundos de arco, que es más o menos un kilómetro por píxel, porque quería algo detallado sin que mi laptop se colgara a mitad del proceso (si el tuyo sí se cuelga con rasters pesados, ese es otro problema con solución aparte). Para armar esa grilla vas a necesitar paquetes como terra o gstat, que junto con sf son la base de casi todo lo espacial que se hace en R, aunque elegir entre las distintas opciones que hay merece su propia conversación.
¿Por qué la Distancia Inversa Ponderada no ve la cordillera?
La función que hace la magia se llama idw, y aunque suena a nombre de robot la lógica detrás es simple: si un punto está cerca de una estación, lo más probable es que su clima se parezca al de esa estación, y mientras más lejos, menos pesa ese dato en el cálculo. Isidora, una chica con más base de matemáticas que yo con la que quedé en contacto por unos comentarios en YouTube, fue quien me explicó que ese "peso" no es más que una potencia que decide qué tan rápido cae la influencia de la distancia, casi siempre fijada en 2. Subirla mucho deja círculos raros alrededor de cada estación, y bajarla demasiado aplana el mapa entero hasta que pierde sentido.
El problema, el de verdad, es que esa cuenta no sabe nada del terreno. Pensé en esto la última vez que llevé mis propios datos al Jardín Botánico de la Universidad Austral de Chile: entre la parte alta, cerca de los árboles más grandes, y la zona baja pegada al río, hay una diferencia real de humedad y temperatura que cualquiera que camine por ahí puede sentir, pero mi interpolación pintaba una transición suave y pareja entre un punto y otro, como si el desnivel no existiera. Es lo mismo que terminé de entender cuando escribí sobre cómo crear un mapa de pendientes en RStudio con datos de elevación: la interpolación matemática es ciega, no sabe que hay una cordillera atajando nubes entre dos estaciones, y asume que el terreno es plano como una mesa.
La regla que uso antes de confiar en cualquier mapa interpolado
Entonces, volviendo a la pregunta de Raimundo: sí sirve, pero no como una foto de la realidad, sino como una primera estimación que hay que revisar con ojo desconfiado. La regla que me quedó después de tropezarme varias veces es simple: si el mapa dice que no llueve en la cima de un cerro donde tú sabes que siempre hay nieve, algo anda mal, y en vez de creerle al color hay que preguntarse qué variable le falta a ese modelo, casi siempre elevación o alguna barrera geográfica que el algoritmo nunca vio.
Con eso en mente, hay un par de cosas que ya no se me olvidan cada vez que abro un proyecto nuevo de interpolación. Fijar primero el CRS inicial en EPSG 4326 y recién después pasar a la proyección local, nunca al revés. Elegir una resolución de grilla que tenga sentido con la distancia real entre tus estaciones, porque no sacas nada con píxeles de un metro si las estaciones más cercanas están a 50 kilómetros. Mirar el resultado con desconfianza antes de darlo por bueno, comparándolo con algo que conozcas del terreno. Y no tenerle miedo al paquete terra, que aunque es más nuevo que el clásico raster, hace que todo el proceso corra bastante más rápido.
Ese parche de colores que finalmente logré ver sobre el mapa de mi región, después de tanto pelear con comas mal puestas y objetos que no calzaban entre sí, se parece un poco a lo que buscaba cuando empecé con esto de por qué estudiar teledetección satelital con R para ver cambios ambientales: dejar de suponer y empezar a mirar los datos de otra forma. Ese raster después se puede recortar con un shapefile, cruzarlo con puntos nuevos para sacar valores exactos en un lugar puntual, o dejarlo bonito y ordenado para un informe, pero eso ya es otro proceso completo que no alcanzo a cubrir aquí. Por ahora, con la lluvia golpeando el techo de zinc otra vez, me basta con saber que el bosque que interpolo ya no es una caja negra ni una verdad absoluta, sino un dibujo que hay que seguir cuestionando cada vez que se abre en la pantalla.