Hay una pregunta que me ronda desde hace tiempo: ¿hasta qué punto puede un analista GIS, sin presupuesto de misión espacial ni acceso a LiDAR propio, generar un Modelo Digital del Terreno con una precisión que supere a los DEM globales de libre acceso? La respuesta corta: sí se puede, pero el camino no es trivial. Este post documenta ese camino completo, con todos sus tropiezos incluidos, porque creo que el valor real de un tutorial está tanto en lo que sale bien como en lo que se rompe por el camino.
El punto de partida, dos escenas Sentinel-1 IW SLC, mismo relative orbit (81), mismo pass (descendente), separadas por apenas 6 días, la ventana mínima que ofrece el ciclo de repetición de la constelación. Coherencia modelada: 0.90. Baseline perpendicular: ~112 metros. Sobre el papel, un par interferométrico casi de manual.
Sobre el terreno, sin embargo, el proceso de validar que dos imágenes SAR realmente sirven para InSAR ya es un ejercicio en sí mismo: comparar horas de adquisición al segundo, verificar REL_ORBIT en los metadatos abstraídos de SNAP, confirmar que la diferencia de órbitas absolutas es múltiplo exacto del ciclo de repetición de 175 órbitas. Nada de esto aparece en el nombre del archivo a simple vista, hay que abrir SNAP y mirar con lupa antes de procesar nada.
El flujo dentro de SNAP: más largo de lo que parece en los diagramas de bloques
Cualquier esquema de InSAR que se vea en un paper cabe en media docena de cajas con flechas. La realidad en SNAP son bastantes más pasos, cada uno con sus propias decisiones:
TOPSAR Split — porque una escena IW completa cubre tres subswaths y decenas de bursts, y solo interesa uno. Aquí ya hay una primera lección de campo: si tu zona de interés cae justo en el límite entre dos subswaths (como me pasó a mí, entre IW2 e IW3), la opción sensata no es forzar un mosaico entre ambos — es reencuadrar el área de trabajo para que quepa entera en uno solo. Menos elegante sobre el mapa, mucho más simple en el pipeline.
Apply Orbit File (x2) — refinamiento de la geometría orbital con vectores de estado precisos, repetido para cada escena por separado.
Back-Geocoding — el corregistro entre maestro y esclavo, y el primer punto donde el software te devuelve números duros: baseline perpendicular, baseline temporal, coherencia modelada, altura de ambigüedad. Es el momento de la verdad — si estos valores no acompañan, más vale parar aquí que seguir invirtiendo horas de cómputo en un par condenado.
Interferogram Formation — con la fase topográfica sin restar, porque el objetivo es extraerla, no eliminarla.
TOPSAR Deburst — fusión de bursts en una imagen continua.
Multilooking — el paso que en la teoría se menciona de pasada y en la práctica resulta decisivo. Volveré sobre esto.
Goldstein Phase Filtering — reducción de ruido de fase antes de intentar desenrollarla, con máscara de coherencia aplicada.
SNAPHU Export → SNAPHU (externo) → SNAPHU Import — el bloque que rompe la comodidad de trabajar dentro de una sola aplicación.
Phase to Elevation — conversión de fase continua a altura real, apoyada en un DEM de referencia (Copernicus 30m) solo para anclar el offset absoluto.
Range-Doppler Terrain Correction — geocodificación final a UTM.
Doce operadores. Ninguno opcional si el objetivo es un DTM completo y no solo un interferograma bonito para una diapositiva.
El punto de fricción real: SNAPHU no vive dentro de SNAP
Aquí es donde el tutorial deja de ser “clic, clic, Run” y empieza a parecerse a administración de sistemas. SNAPHU — el algoritmo de network-flow que resuelve la ambigüedad de los 2π de la fase envuelta — es un proyecto externo de Stanford, en C, que SNAP invoca pero no empaqueta. En Windows puro, no hay binario oficial.
La solución pasó por:
- Instalar WSL2 desde PowerShell en modo administrador
- Configurar una distribución Ubuntu completa, con su propio usuario y su propio
sudo - Instalar
build-essentialpara tener compilador C disponible - Descargar el código fuente de SNAPHU v2.0.5 y compilarlo con
make - Resolver un error de compilación nada trivial: código escrito para estándares C de hace más de una década, chocando contra las validaciones estrictas de GCC 15 — solucionado forzando
-std=gnu17en el Makefile - Ajustar la memoria asignada a WSL2 vía
.wslconfig, porque el límite por defecto (50% de la RAM del sistema) resultó insuficiente para procesar la imagen a resolución completa
Y ahí llega la lección más importante de todo el proceso, la que de verdad merece un titular propio.
Por qué el Multilooking no es opcional (y casi me cuesta el proyecto)
Mi primer intento de correr SNAPHU sobre la fase filtrada, a resolución SLC nativa — 26.960 píxeles de ancho, sin ningún tipo de reducción — terminó con un escueto Killed en la terminal tras varios minutos de cómputo. El OOM killer de Linux matando el proceso por consumo de memoria, incluso con 20 GB asignados a WSL2 sobre un equipo con 32 GB totales.
La solución no fue más RAM. Fue reconocer que había saltado un paso del flujo estándar: el Multilooking antes del filtrado Goldstein. Con 4 range looks y 1 azimuth look, el ancho de la imagen se redujo de 26.960 a 6.740 píxeles — una cuarta parte. El mismo comando de SNAPHU que antes moría a los pocos minutos, esta vez completó el desenrollado completo en 17 minutos y 56 segundos, sobre una red de más de 82 millones de nodos, sin un solo error.
La moraleja para cualquiera que replique este flujo: el Multilooking no es un capricho de eficiencia computacional. Es lo que separa un proceso viable de un Killed silencioso, y de paso mejora la relación señal/ruido antes de las etapas más sensibles del pipeline.
El resultado: menos resolución nominal, más precisión real. Con el pixel spacing final en torno a 14.7 metros — deliberadamente más grueso que los 30 metros de GLO-30 o SRTM en términos de “tamaño de píxel de fábrica” solo en apariencia, porque la comparación relevante no es el tamaño del píxel sino la fuente del dato — el resultado geocodificado en UTM 30N muestra una definición de la red de drenaje y de las formas del terreno notablemente más fina que la de los DEM globales de referencia.
Esto no es casualidad. GLO-30 y SRTM son productos de propósito general, construidos para cobertura mundial homogénea, con todas las concesiones que eso implica. Un DTM InSAR calculado ad hoc, con baseline perpendicular optimizada (~112 m, en el rango ideal de sensibilidad a la altura sin decorrelación geométrica), baseline temporal mínima (6 días) y coherencia por encima de 0.90, está afinado específicamente para esa zona y esa fecha — y eso se traduce directamente en una capacidad muy superior para captar el detalle real del relieve, incluso con un pixel spacing nominal similar o algo mayor.
Cerrando el círculo en Global Mapper
El GeoTIFF final, con valores de elevación en metros sobre WGS84/UTM 30N, se importó sin fricciones en Global Mapper v26.2 para la visualización final y el shading hipsométrico — el mismo entorno donde vengo trabajando el terreno de Sierra de Gredos a partir de PNOA-LiDAR. Tener ambos DTM, el oficial y el generado por InSAR casero, sobre la misma plataforma de visualización, es el mejor banco de pruebas posible para valorar hasta qué punto un flujo construido enteramente con herramientas gratuitas — SNAP, WSL, SNAPHU compilado a mano — puede acercarse a productos de referencia con LiDAR aéreo detrás.
En números
- 2 sistemas operativos coordinados en el mismo flujo de trabajo (Windows + Ubuntu vía WSL2)
- 1 compilación desde código fuente de una herramienta de 2009 sobre un compilador de 2025
- 12 operadores de SNAP encadenados, sin contar los reintentos
- ~82.5 millones de nodos en la red de optimización de flujo del desenrollado de fase
- 1 error de memoria que obligó a repensar el pipeline a mitad de camino
- ~14.7 m de pixel spacing final, con un nivel de detalle topográfico que compite de tú a tú con DEM globales de 30 m
Probablemente el procedimiento más complejo que he seguido desde hace quince años… nunca, nunca he seguido un procedimiento tan enrevesado y cambiante en todos mis años en geospacial. ¡Estoy muy contento!. Espero que se vea el potencial de uso de esta fuente, a la que le falta postproceso, añadir GCP y análisis en profundidad de QC pero teniendo en cuenta cuál fue mi puesto los últimos años, no será problema…
Saludos y como siempre, si te gusta, ¡manda un mensajito que hace mucha ilusión!
Alberto Concejal
Geospatial Analyst
Geovisualization.net
Sources:
https://step.esa.int/main/download/snap-download/
https://search.asf.alaska.edu/
https://www.facebook.com/watch/?v=1092425842277002
https://dares.tech/es/como-leer-los-datos-insar-para-controlar-el-desplazamiento-del-suelo/
Geovisualization.net 