Tengo el cursor clavado en un histograma que no tiene ninguna curva, solo una rayita flaca pegada al borde izquierdo, y la taza de té ya fría me queda ahí al lado mientras la consola de RStudio me tira otra línea en rojo. Llevo un rato haciéndole clic al mismo botón como si eso fuera a cambiar algo, tratando de entender por qué la imagen satelital del bosque al que le quiero seguir la pista año a año se convirtió, de un momento a otro, en una mancha blanca sin ninguna gracia. Así empiezan casi todos mis sábados con la teledetección: un raster que se ve perfecto en la carpeta y que, apenas lo abro en RStudio, me obliga a sentarme a limpiarlo píxel por píxel si quiero que el mapa diga algo de verdad.
Antes de seguir, una aclaración rápida: algunos de los enlaces que vas a cruzar en esta bitácora son de afiliado, lo que significa que si compras algo a través de ellos me llega una comisión, sin que a ti te cueste un peso extra. Solo recomiendo lo que de verdad he usado este invierno para aprender, o aquello con lo que me he dado de cabezazos semana tras semana hasta entenderlo. Si alguna vez un enlace no es de afiliado te lo aviso aparte.
El problema de los píxeles fuera de rango en un raster
Mucho antes de llegar a R, probé meterme por el lado de Google Earth Engine, porque en varios foros lo mencionaban como el camino más directo para trabajar con Landsat 8 sin bajar nada a la computadora. Me cerró la puerta casi de inmediato: la interfaz corre sobre JavaScript y yo no tenía ni la base más mínima de programación, así que cada línea se veía como un idioma que no era el mío. Terminé volviendo a RStudio, que ya conocía apenas de cargar un archivo raster y mirarlo sin entender mucho más, y ahí fue donde me quedé dándole vueltas.
El problema en concreto era este: cuando calculas el NDVI, ese índice de vegetación que te dice qué tan sano se ve el bosque, el valor debería moverse dentro de un rango razonable. Y ahí estaba yo, con un píxel suelto marcando un número que no tenía ningún sentido físico, y R tratando de estirar la escala de colores para que ese número cupiera igual, dejando todo lo demás —lo que sí importaba— apachurrado en una esquina. El mapa entero se volvía blanco por culpa de un solo dato que probablemente era una nube mal leída o un error del sensor, no vegetación de verdad.
Fue por esos días que mi vecino Boris, que trabaja en infraestructura de servidores y le gusta todo lo que huela a software libre, me vio con el mapa abierto en el pasillo del edificio y me preguntó, sin ninguna maldad, por qué mi bosque se veía como una hoja en blanco. Tuve que explicarle en voz alta, con palabras bien simples, qué es un valor atípico en un raster, y ahí me di cuenta de que yo misma todavía no tenía la respuesta clara: sabía que había un número que sobraba, pero no sabía cómo sacarlo sin arruinar el resto de los datos.
Aprendiendo a poner límites con el paquete terra
Encontré la respuesta en las clases del curso de Teledetección Satelital con R y R-Studio, que ha sido mi mapa de ruta este invierno para no aprenderlo todo a puro tropezón. Ahí entendí que la solución no es borrar el dato raro sino ponerle un límite: en R hoy se trabaja mucho con el paquete terra, que entre los paquetes espaciales es de los más livianos y rápidos, y tiene una función que se llama clamp. La lógica es más simple de lo que suena, aunque a mí me costó verla: si yo sé que mi índice no puede pasarse de cierto rango, le pido a R que todo lo que quede afuera se transforme en el valor límite o derechamente en un vacío (NA), como ponerle baranda a una escalera para que nadie se caiga por el lado que no corresponde.
Para la semana 8 de estar metida en esto ya me animaba a mirar el histograma antes que el mapa, que es justo el cambio de hábito que me faltaba. Un rato antes, sola frente a la pantalla, me había topado con un error de proyección que en otro momento me habría dejado paralizada, y esa vez el mensaje tenía sentido: lo leí, entendí qué pedía y lo corregí sin preguntarle a nadie. Fueron esas cosas chicas las que me hicieron confiar en que también podía tratar los valores atípicos con el mismo cuidado, sin pánico.
Si andas empezando y te sientes perdida entre tanto código, no eres la única: yo tampoco soy geógrafa ni programadora, solo alguien que quiere ver sus propios bosques desde arriba. Por eso me gustó tanto ese curso, porque acompaña desde el momento en que no sabes qué es una proyección hasta el día en que te sale un mapa decente. Hay otro un poco más específico, el de Modelado de Nicho Ecológico con Maxent en R, que tengo guardado para más adelante, cuando termine de ordenar bien la limpieza de mis propios datos; se lo comenté hace poco a Denise, con quien hablo seguido en un grupo de R, porque ella viene del diseño gráfico y maneja ggplot2 mejor que nadie que conozca, pero se traba justo en el paso de pasar un raster a data frame, que es casi lo mismo que a mí me tenía dando vueltas.
Cuando un valor extremo no es realmente un error
Aquí es donde mi método de limpiar todo a lo bruto casi me juega en contra. Leyendo sobre estudios en zonas polares y en desiertos me encontré con una trampa: hay lugares donde esos valores que parecen disparatados son en realidad el dato más importante de todo el análisis, no un error del sensor. Si alguien está mirando la temperatura del suelo en un desierto, un número que se ve exagerado puede ser justo el registro de un evento de calor que ocurre una vez cada varios años, y filtrarlo a ciegas sería borrar lo único que valía la pena mirar.
En Valdivia, con tanta humedad y tanto verde, es más fácil sospechar que un número fuera de rango es un error de nube o de sensor, pero igual aprendí a preguntarme antes de aplicar cualquier filtro: ¿este valor es físicamente posible en este lugar? Si la respuesta es no, recién ahí se va. Y de pasada, para quien también se pierde con esto: la proyección de coordenadas es otro tema aparte que a mí me costó lo suyo entender, ahí entra la Zona UTM 18S que nos corresponde en el sur de Chile, pero esa es una pelea para otra bitácora.
Mi forma de trabajar ahora, sin que la laptop colapse
Con tal de no repetir el susto de ese primer invierno, ahora sigo un orden bien marcado cada vez que abro RStudio un sábado en la mañana. Reviso primero la extensión y la resolución espacial del archivo, para no cargar algo más pesado de lo que mi memoria puede aguantar; si te ha pasado que R se cierra solo a mitad de proceso, por ahí tengo contada mi peor racha de caídas en cómo evitar errores de memoria al procesar rasters grandes en RStudio.
Después de cargar la imagen lo primero que grafico es el histograma, nunca el mapa, porque ahí es donde saltan los valores que no cuadran. Si veo la escala corrida, aplico el filtro; y si el problema no es un error del sensor sino una nube que se coló, uso otro truco que ya conté en lo que aprendí al quitar nubes de imágenes Landsat en RStudio, que básicamente arma una máscara para taparla.
Si todavía te sientes estancada con tus propios mapas, tranquila: a mí me tomó meses pasar de la desesperación total a poder limpiar un raster en minutos, y sigo volviendo a mis apuntes del curso de Teledetección Satelital con R y R-Studio cada vez que se me olvida una coma. Si quieres seguir tirando del hilo, más adelante toca ver cómo calcular el índice de vegetación MSAVI, que es otro mundo cuando el suelo está casi pelado. Por ahora me quedo con la lección que más me sirvió de todo este proceso: antes de borrar cualquier número raro, hay que preguntarle al paisaje si ese número tiene sentido ahí, porque un filtro aplicado sin pensar puede limpiar justo el dato que valía la pena guardar.