Trescientos. Ese es el número de puntos por pulgada que separa un mapa que se ve impecable en la pantalla de RStudio de uno que sale borroso apenas alguien lo manda a imprimir para un informe técnico. Llevo un buen rato metida en esto de la teledetección satelital con R (el lado espacial de R, más que nada, con sus rasters y sus capas) tratando de que mis mapas de cartografía técnica no solo muestren datos, sino que los comuniquen bien. Ahí la visualización de datos deja de ser un capricho estético: es la diferencia entre un mapa que alguien entiende de un vistazo y uno que termina archivado sin que nadie lo mire dos veces.
Antes de llegar a este punto vi horas de videos de YouTube sobre SIG, buscando cómo armar mapas que no se vieran de aficionado, pero la mayoría enseñaba con un software distinto al que tenía instalado en mi computador, así que terminaba más perdida que al principio, copiando botones que ni siquiera existían en mi pantalla. Ahí entendí que necesitaba algo pensado para RStudio y no un tutorial genérico armado para otro programa. No soy programadora ni geógrafa: aprendí esto sola, revisando qué funcionaba y descartando lo que no.
Dos maneras distintas de plotear el mismo raster
Con el tiempo até cabos: hacer un mapa que sirva para un informe técnico no es solo cuestión de código bonito, hay dos caminos posibles en R y cada uno tiene su momento. Todo parte, claro, con tener la imagen ya lista: haber bajado antes las escenas de Sentinel-2 a RStudio, haberles sacado las nubes de encima porque una escena nublada arruina cualquier mapa bonito, y haber recortado el raster con el shapefile del área que me interesa. Ese trabajo previo es justo lo que dejé documentado cuando escribí sobre cómo hacer un análisis multiespectral en R usando imágenes de satélite, así que aquí parto directamente desde el raster ya limpio.
El primer camino es armar todo con ggplot2 y el paquete tidyterra, que permite tratar un raster como si fuera una capa más de un gráfico de ggplot2. El segundo es quedarse con el sistema de graficado nativo de terra, más simple, menos bonito por defecto, pero bastante más liviano. Para los vectores, límites, ríos, caminos, uso el paquete sf, y en el camino fui probando distintos paquetes espaciales de R hasta quedarme con la combinación que uso hoy, aunque elegir entre todos esos merece su propio texto aparte. Eso sí, antes de llegar siquiera a esta parte tuve que entender qué es un raster y cómo se abre en RStudio, que es otra historia completa.
Cuándo conviene quedarse en ggplot2 y tidyterra
Ggplot2 gana cuando el raster no es descomunal y lo que quiero es control fino sobre cada capa: el color de fondo, la transparencia de los polígonos, dónde exactamente cae cada etiqueta. Sirve perfecto, por ejemplo, cuando lo que estoy mostrando es un índice como el NDVI, calculado a partir de un par de bandas espectrales, o cualquier otro de la familia de índices de diferencia normalizada que tienen su propia fórmula (hay más de uno, no solo el NDVI, y algún día voy a ordenar ese glosario para mi propio beneficio). Combinado con ggspatial, ggplot2 además calcula solo la flecha del norte y la barra de escala, que es justo lo que necesita un mapa técnico para que alguien de afuera lo entienda sin preguntar nada.
Cuando el archivo pesa demasiado, gana el motor nativo de terra
El problema aparece con los rasters pesados: escenas completas de Sentinel-2 sin recortar, mosaicos de varias fechas, capas de una serie temporal larga. Ahí ggplot2 se pone lento, no porque esté mal hecho, sino porque su arquitectura de capas no fue pensada para mover esa cantidad de píxeles de una sola vez. La razón de fondo tiene que ver con cómo cada paquete maneja la memoria frente a un raster grande, tema que ya me hizo perder tardes enteras esperando que algo terminara de renderizarse y que dejo para otro texto completo. En esos casos uso el 'plot' nativo de terra: más feo, pero no se cuelga a mitad de camino.
Los mapas que más me piden con este tipo de raster pesado son justamente esos: coberturas de suelo que salen de una clasificación supervisada (bosque nativo, plantación, pradera, agua) y que después hay que validar con una matriz de confusión antes de mostrárselas a nadie, aunque ese proceso también da para su propio capítulo. También están las series completas donde se ve el cambio del bosque año tras año, algo parecido a lo que conté en cómo analizar la fenología de la vegetación en R con series temporales, y hasta algún modelo de distribución de especies con Maxent, terreno que recién estoy pisando. En otros mapas lo que necesito es sacar el valor del raster justo en un punto específico, y ese truco tiene su propia lógica aparte.
Tengo grabada una tarde de sábado en que por fin la proyección quedó bien puesta: el contorno del bosque en la pantalla calzó exacto con la curva que tengo memorizada del camino en auto hacia el Parque Saval, en Isla Teja, esa que reconozco sin mirar ningún letrero. Fue la primera vez que un mapa mío se pareció de verdad al lugar que veía por la ventana del auto, y no a una versión torcida de él.
Lo que necesita un mapa de cartografía técnica antes de exportarse
Ahí es donde entra la parte que sí es enteramente mía en este tema: cómo queda un mapa listo para un informe, más allá de si lo hice en ggplot2 o en terra. Primero, definir el sistema de referencia de coordenadas antes de graficar nada, nunca después. Segundo, si el raster no es excesivamente grande, usar tidyterra para que se integre bien con el resto del gráfico. Tercero, sumar los elementos cartográficos con el paquete ggspatial, que calcula solo la flecha del norte y la barra de escala en vez de tener que dibujarlas a mano. Y cuarto, exportar con ggsave indicando siempre la resolución: sin eso, el trescientos del que hablaba al principio no aparece por arte de magia.
También importa la paleta de colores: para un informe técnico conviene una que sea legible para personas daltónicas, porque nunca se sabe quién va a revisar el documento al otro lado. Y la leyenda tiene que explicarse sola. Si alguien necesita preguntar qué significa cada tono, sobran capas o faltan etiquetas, no al revés.
Qué camino conviene según el informe que tengas entre manos
Entonces, resumiendo el dilema: si el raster es manejable y lo que importa es el control fino sobre cada capa (colores, transparencias, dónde cae cada etiqueta), me quedo con ggplot2 y tidyterra. Si el archivo es gigante, son varias escenas juntas o una serie temporal completa, cambio al 'plot' nativo de terra y sacrifico algo de estética a cambio de que el mapa realmente se renderice. Pero da lo mismo el camino que tome: el paso final siempre es el mismo, exportar con la resolución correcta, la paleta correcta y los elementos cartográficos completos, porque un mapa que no se puede leer en papel no le sirve a nadie, por bonito que se vea en la pantalla.
Todavía tengo guardada la primera versión de un mapa que hice, apenas un contorno verde sobre un fondo negro, y me acuerdo clarito del clic seco del trackpad cuando por fin le di guardar esa vez. De ese archivo torcido a uno que se puede imprimir sin vergüenza hay hartos rasters pesados de por medio, hartas tardes de lluvia contra el techo, y ese trescientos que ya no se me olvida nunca más.