Tengo la consola de RStudio abierta y ahí está, otra vez, ese mensaje en rojo que ya me sé casi de memoria: se quedó sin memoria RAM para seguir. Al lado del teclado hay un té que se enfrió hace rato, porque me quedé mirando la pantalla esperando que el error se arreglara solo (no pasó, nunca pasa). Llevo un par de años metida en esto de la teledetección los fines de semana, y todavía, cuando un raster pesa lo que tiene que pesar, mi laptop de oficina se pone a temblar como si le hubiera pedido correr algo para lo que no entrenó.
Frente a este tipo de error hay como dos caminos, y los probé los dos antes de entender cuál me servía de verdad. El primero es el que casi todo el mundo prueba apenas parte: pensar que el problema es la máquina. El segundo es más aburrido de entrada pero es el que en realidad funciona: cambiar la forma en que le pides a R que lea el archivo. Dejo la comparación acá, con los dos lados puestos uno al lado del otro, porque a mí nadie me la explicó así de simple y me habría ahorrado hartas tardes de mal genio.
Dos formas de pelear con un raster que no cabe en la memoria
La primera vez que me topé con esto, mi reacción fue la típica de alguien sin formación en programación: buscar en foros que decían, básicamente, cómprate más RAM y se soluciona. Antes de llegar a algo más útil vi hartas horas de videos de YouTube sobre SIG, pero la mayoría mostraba pantallas de un programa distinto al que yo tenía instalado en mi computador, así que terminaba copiando pasos que no calzaban con nada de lo que veía en mi propia pantalla, más perdida que al principio. Ese es el primer camino: agrandar los recursos y esperar que alcance.
El segundo camino no te lo explica nadie de entrada porque no es tan intuitivo: en vez de pedirle al computador que se trague el archivo completo, le enseñas a R a comerlo en pedazos. No se trata de tener una máquina más potente, sino de ordenarle el trabajo de otra manera. Ahí entra el paquete terra, que reemplazó al paquete raster que usé mis primeros meses sin saber que ya iba quedando atrás para archivos pesados (cómo se lee un raster desde cero es tema para otro texto mío, así que no me desvío por ahí).
¿Comprar más RAM o cambiar cómo RStudio procesa el archivo?
Puesta la balanza, el camino de más RAM tiene una ventaja real: es simple de entender, y si el archivo no es tan grande o solo lo vas a abrir una vez, a veces de verdad resuelve el problema sin que tengas que aprender nada nuevo. El problema aparece cuando trabajas seguido con imágenes satelitales completas, de las que se usan en teledetección: ahí ni la memoria más generosa alcanza, porque con el paquete antiguo R seguía intentando cargar todo de una sola vez, sin importar cuánta RAM tuviera disponible.
El segundo camino pide más paciencia al principio porque hay que entender un concepto nuevo. Pero una vez que lo internalizas, deja de importarte si el archivo pesa poco o pesa una barbaridad, porque el método funciona igual para los dos casos, y eso es justo lo que el primer camino nunca te va a dar.
El paquete terra ataca el problema desde otro lado
Cuando por fin cambié al paquete terra sentí que me habían cambiado los lentes. La diferencia de fondo es que un objeto SpatRaster no carga los datos apenas lo abres: guarda algo parecido a un mapa de dónde está la información en el disco duro, y solo va a buscar los pedazos que necesita cuando se los pides, no antes. Funciones como writeRaster() aprovechan eso: cortan el trabajo en bloques, procesan uno, lo guardan, lo sueltan de la memoria y siguen con el próximo, en vez de tener todo abierto al mismo tiempo.
Antes, trabajando con el paquete viejo, mi primera solución torpe fue tratar de cambiar la resolución de un raster en R con remuestreo espacial solo para que el archivo pesara menos y mi laptop no se cerrara sola. Funcionaba a medias, pero perdía detalle que después terminaba necesitando. Con terra dejé de tener que hacer ese sacrificio: podía trabajar con el archivo original sin recortarlo de entrada.
Elegir entre un camino y el otro
Con el tiempo aprendí a mirar el tamaño del archivo y el tipo de trabajo antes de decidir qué camino tomar. Si es una imagen chica que solo vas a abrir una vez para mirarla, no vale la pena complicarse: ábrela como siempre y sigue tu día. Pero si es un archivo pesado, de esos que vienen de Sentinel-2 y que vas a procesar más de una vez (recortarlo, compararlo, calcular algo encima), ahí el segundo camino gana siempre, porque agrandar la RAM en esos casos es como comprar una olla más grande para una sopa que de todas formas no te va a caber en la cocina.
Uso esto, por ejemplo, cada vez que quiero procesar varias imágenes satelitales en R usando bucles sencillos: si intento cargarlas todas juntas antes de empezar el bucle, vuelvo al mismo error de siempre. Si dejo que cada vuelta del bucle cargue, procese y suelte su propio archivo, el computador ni se entera.
Otra cosa que aprendí a puro tropezón es que R deja archivos temporales botados en una carpeta oculta, y si el disco duro se llena, chocas con un error parecido aunque la RAM esté libre, así que limpiarlos de vez en cuando con tmpFiles(remove = TRUE) es parte del mismo camino. Y si solo necesito una banda para lo que estoy haciendo, dejé de cargar de entrada las doce completas de Sentinel: cargar solo lo que vas a usar también es, a su manera, procesar por partes.
Con cuál me quedo, según lo que tengo enfrente
La prueba de que el segundo camino valía la pena la tuve el día que corrí un índice de vegetación (NDVI, le dicen, aunque cómo se calcula lo dejo para otro texto) sobre una zona que conozco bien, el Jardín Botánico de la Universidad Austral: apareció un parche rojo justo donde recordaba el claro que se abre en el sendero en verano, y por primera vez sentí que el mapa no me estaba mintiendo. Antes de eso, con el paquete viejo, ni siquiera había logrado que el proceso terminara sin colgarse a medio camino.
Le conté esto a una amiga que hace cerámica en un taller del centro, pensando que le iba a sonar interesante, y me miró como si le hablara de otro planeta (con toda razón, la verdad, porque contado así suena bastante raro). Pero para mí fue la confirmación de que no necesitaba una máquina mejor, necesitaba entender el problema antes de intentar resolverlo a la fuerza.
El mismo truco de ir por bloques fue el que después me sirvió para calcular áreas más grandes, como cuando escribí sobre cómo logré calcular la superficie de coberturas vegetales en R sin errores, donde el archivo era todavía más pesado y sin este cambio de enfoque ni lo habría intentado. Si tuviera que resumir la comparación en una frase para alguien que recién empieza: no gastes tu sábado tratando de exprimirle más memoria a tu computador si el problema real es que le estás pidiendo que trague el archivo entero de una sentada. Mira primero cuántas veces vas a usar ese archivo y qué tan grande es, y decide desde ahí cuál de los dos caminos te conviene.
Y si te sirve de algo saber que alguien que hace un par de años no tenía idea de qué era un archivo raster ahora puede procesar los pesados sin que el ventilador de la laptop suene a avión despegando: se puede, y no hace falta comprar nada nuevo para lograrlo, solo cambiar el orden en que le pides las cosas a R, que es, al final, toda la gestión de memoria que hace falta entender.