¿Por qué dos mapas del mismo pedazo de bosque, hechos con las mismas imágenes de Sentinel-2 y casi el mismo código en R, pueden mostrar cosas completamente distintas? La respuesta casi nunca está en el satélite: está en el orden en que se toman las decisiones antes de llegar al mapa final. Mejorar un mapa de bosque con teledetección no es aplicar un filtro más lindo sobre el mismo archivo. Es revisar, en este orden, la proyección, la resolución de la imagen, el índice (como el NDVI) que se usa para traducir el verde en números y, recién al final, qué tan bien clasificado queda cada parche de vegetación. Saltarse alguno de esos pasos, o hacerlos en el orden que no es, suele terminar en perder la tarde completa revisando el mismo error otra vez.
Antes de tocar RStudio, probé comparando a ojo imágenes de distintos años directo en Google Earth, pasando el cursor entre una captura y otra. Servía para notar que algo se veía distinto, pero no había forma de medir cuánto había cambiado el bosque ni de guardar ese análisis para después, cada comparación vivía solo en la pantalla, ese rato, y se perdía apenas cerraba el programa. Ese límite tan simple fue lo que me hizo buscar algo que sí pudiera medir y guardar, que es básicamente todo lo que sigue en esta entrada.
Lo que hace que un mapa de bosque sea confiable y no solo bonito
Un mapa de bosque confiable parte de entender qué es, en el fondo, un raster, esa cuadrícula de valores que compone cada imagen satelital, algo que dejé armado con calma en otra entrada para no repetirlo acá. Lo que sí quiero dejar claro es que la confiabilidad de un mapa depende de tres cosas que casi nunca se mencionan juntas: qué tan fino es cada pixel frente al tamaño real del parche de bosque que te interesa, si las capas que vas a cruzar hablan el mismo idioma espacial, y si el índice o la clasificación que usas sabe distinguir lo que tú necesitas distinguir. Un mapa puede verse espectacular, con una paleta de colores preciosa, y aun así estar diciendo cosas que no son ciertas si falla cualquiera de esos tres puntos.
La proyección es lo primero que hay que revisar, no lo último
La proyección (CRS, por sus siglas en inglés) decide si dos capas van a calzar o no, y es, sin excepción, lo primero que reviso antes de cualquier otra cosa, ese tema tiene su propio apunte paso a paso con el detalle de cómo corregirlo, así que aquí solo cuento por qué importa tanto revisarlo primero. La vez que encontré sola un error de proyección, sin que nadie me lo señalara, el mensaje de la consola por fin dijo algo con sentido en lugar de ser una fila de texto rojo indescifrable: el problema nunca estuvo en los datos en sí, sino en cómo se estaban combinando las capas entre ellas.
Un lector de Temuco, Aldo Pinto, me escribió una vez contándome que le había pasado exactamente lo mismo con un predio que estaba monitoreando: todo cuadraba en el mapa de Chile completo, pero su polígono aparecía corrido varios kilómetros apenas se acercaba al detalle. Ese tipo de error no avisa con un mensaje claro la primera vez, y por eso conviene revisarlo antes de gastar tiempo en cualquier índice o clasificación. De nada sirve un NDVI perfecto sobre capas que no están alineadas.
Resolución espacial: el tamaño real de cada pixel
Landsat 8 entrega píxeles de 30 metros por lado, mientras que las bandas visibles e infrarrojo cercano de Sentinel-2 bajan a 10 metros, y esa diferencia es la que decide si un parche de bosque nativo angosto, pegado a un camino, se ve como una forma real o como un cuadrado borroso sin ninguna gracia. Para bosques grandes y continuos tal vez no importe tanto, pero para los retazos de selva valdiviana que quedan entre caminos y predios, esos 20 metros de diferencia separan un mapa útil de uno que solo sirve de adorno.
Bajar esas imágenes directo desde R, sin pasar por visores externos, tiene sus propias mañas que dejé completas en otra entrada, y lo mismo pasa con sacar las nubes antes de clasificar nada: es un paso aparte, tedioso, pero que si se salta arruina todo lo que viene después. Qué paquete de R conviene para cada tarea también tiene su propio repaso, yo cambié del paquete 'raster' al 'terra' hace tiempo, y lo que aprendí organizando mis scripts de R para no perder tiempo fue justamente ordenar ese tipo de decisiones para no repetir el mismo error dos veces.
El NDVI y el bosque: por qué el verde a veces miente
El NDVI ya tiene su propio tutorial calculado paso a paso con bandas de Sentinel-2, así que no voy a repetir la fórmula acá; lo que sí vale la pena decir es cuándo no basta con él. En un bosque muy denso como el que tenemos en el sur, el índice llega a su tope y dos parches con salud de vegetación distinta terminan mostrando casi el mismo valor de verde. El índice se satura y deja de avisar. La regla que uso para decidir si necesito algo más es simple: si en la zona de estudio el suelo se asoma bastante entre los árboles, reviso cómo calcular el índice de vigor de la vegetación SAVI usando RStudio, que corrige justamente ese ruido que mete el brillo del suelo; si el bosque es continuo y cerrado, el NDVI solo basta.
Si además quieres comparar NDVI con otros índices como NDWI o EVI, armé un glosario de índices espectrales aparte, solo para eso, así que tampoco entro en esa comparación acá.
Clasificar coberturas exige más que un algoritmo bonito
Clasificar coberturas vegetales paso a paso es, de nuevo, tema para otra entrada completa, pero el resumen corto es este: ningún algoritmo de clasificación sirve de mucho si antes no recortaste el raster al límite real del predio o la cuenca que te interesa, otro paso técnico que dejé explicado en detalle aparte. Una vez clasificado, hay que validar ese resultado con una matriz de confusión, no basta con que el mapa se vea razonable a simple vista, y ese también es su propio tema.
Marcia, mi compañera de oficina que estudia agronomía a distancia, una vez me preguntó por qué el modelo había marcado como bosque una franja que a simple vista era puro matorral, y antes de que yo terminara de explicarle la matriz de confusión ya había adivinado que el problema estaba en los puntos de entrenamiento, no en el algoritmo. Para tareas puntuales como sacar el valor de NDVI en un punto exacto, o el promedio por cada polígono de bosque, hay trucos específicos de extracción y de estadísticas zonales que también dejé anotados en otro lado; y cuando el archivo raster pesa tanto que el computador se cuelga a medio proceso, hay soluciones concretas para eso que no tienen nada que ver con comprar un computador nuevo.
Este mismo flujo también sirve para mapear especies, no solo bosque
Bastante, de hecho. Si en vez de cobertura vegetal lo que te interesa es dónde podría estar viviendo una especie puntual, el camino cambia de clasificación supervisada a modelado de distribución de especies con MaxEnt, que tiene su propio punto de partida para quien nunca lo ha tocado. Ahí el problema casi nunca es el modelo: es la calidad de los puntos de presencia que le das de entrada, algo que también tiene su historia aparte sobre cómo limpiar esos datos antes de modelar.
Si lo que buscas es crear mapas de idoneidad de hábitat en R para especies locales, ese cruce entre datos de presencia y capas ambientales es justo el siguiente paso después de tener bien resuelto todo lo anterior. Y si en vez de una foto fija quieres ver cómo cambia el bosque mes a mes en lugar de comparar solo dos años, ahí entran las series temporales completas de reflectancia, que es otro tema que merece su propio espacio.
El paso que casi nadie menciona: dejar el mapa listo para mostrar
Un mapa técnicamente correcto todavía necesita escala, norte, leyenda y una paleta que no confunda a quien lo lea. El diseño del mapa para un informe tiene sus propias reglas que dejé ordenadas en otra entrada, porque un polígono bien clasificado igual puede fracasar si nadie entiende qué está mirando. A veces también hay que remuestrear un raster para que calce con otra capa de distinta resolución, y ese ajuste de resolución espacial tiene su propio tutorial aparte.
Guardar el primer mapa que de verdad reflejaba el bosque, verde sobre fondo negro, con el polígono del predio calzando donde debía, fue un clic de trackpad bien simple, ahí en el escritorio de mi pieza en pleno centro de Valdivia, con la ventana empañada por el frío del patio interior y la taza de té ya fría junto al trackpad. No hace falta tener formación en programación para llegar hasta ahí; cómo fue aprender todo esto sin ese punto de partida es otra historia que cuento aparte, con calma.
Un flujo de trabajo, no una lista de trucos sueltos
Mejorar un mapa de bosque con teledetección no depende de encontrar el algoritmo perfecto: depende del orden. Proyección correcta primero, resolución acorde al tamaño real del parche, el índice adecuado para ese tipo de vegetación y, recién al final, una clasificación validada con números y no solo a ojo. Ese orden es lo único que de verdad sirve para el pedazo de bosque que vigilo por el sector de Barrio Alemania, y es, en el fondo, el mismo orden que le recomendaría a cualquiera que esté partiendo con imágenes de Sentinel-2 y R.
Revisa primero lo que no se ve a simple vista: la proyección y la resolución, antes de preocuparte por el índice o el color del mapa final. Ahí está, casi siempre, el error que después cuesta más deshacer.