Este sitio web utiliza cookies propias y de terceros para mantener la sesión y obtener datos estadísticos de navegación de los usuarios. Para más información vea la Política de cookies.
Este sitio web utiliza cookies propias y de terceros para mantener la sesión, ofrecerle una mejor experiencia de usuario y obtener datos estadísticos de navegación de los usuarios. Para más información sobre cómo configurar las cookies, vea nuestra Política de cookies.
Al pulsar el botón "Aceptar selección" se están aceptando las cookies seleccionadas, además de las cookies técnicas que permiten un correcto funcionamiento del sitio web. Al pulsar el botón "Rechazar todas" se están rechazando todas las cookies, excepto las cookies técnicas que permiten un correcto funcionamiento del sitio web.
Como vimos en una entrada anterior, los mosaicos Sentinel-2 con SNAP requieren remuestrear todas las bandas a la misma resolución espacial, o bien usar opción Multi-size Mosaic. Pero esta parece tener un bug pendiente.
Para comprobarlo, hemos seguido paso por paso las indicaciones del tutorial en video publicado por la ESA (https://www.youtube.com/watch?v=GeAZrk4sEKQ), con dos productos Sentinel-2 L1c normales y corrientes. Siguiendo el tutorial, hemos decidido salvar el mosaico resultante como beam-dimap, que es el formato que se ofrece por defecto, y hemos elegido como sistema de referencia (CRS) UTM WGS84, que no solo es el caso que se utiliza en el tutorial sino que es lo habitual para un usuario en nuestras latitudes. Usamos la opción "resolution from native product" y hemos seleccionado en la última pestaña las bandas Sentinel-2 B2, B3 y B4, todas con tamaño de píxel 10 m.
La ejecución de este mosaico y escritura del producto beam-dimap resultante tarda unos 10 minutos en un equipo Linux de baja gama (8 GB de ram, procesador 3.6 GHz). A la vez que se escribe en disco el fichero mosaico, queda abierto en SNAP. Al activar "open image window" para visualizar el resultado tarda otros 10 minutos (esto es ya es mala cosa) "creating RGB image" tras los cuales la imagen en la ventana indica que el resultado es incorrecto. No en características geométricas (extensión, tamaño de píxel) sino radiométricas. La figura adjunta muestra el histograma de una de las bandas mosaicadas, en el que rápidamente se reconoce una distribución anómala.
Sin embargo, si el CRS de salida es coordenadas geográficas, el resultado es correcto, como se ve en el nuevo histograma y en la imagen que mostramos de la zona de unión (hecha con la opción "overlay"), donde las diferencias radiométricas son simplemente fruto de la diferente fecha de imagen (septiembre frente a abril). Aunque eso sí, el mosaico tarda en esta ocasión unos 50 minutos. Y SNAP tarda casi 10 minutos en crear una imagen RGB para visualizarlo. Esto de la lentitud de visualización es un viejo problema de SNAP, que probablemente no tenga solo que ver con la cuestión del Multi-size mosaic.
Dando una vuelta por el foro de STEP encontramos una entrada que se refiere a esta problema. Se trata de esta ( https://forum.step.esa.int/t/s2-mosaic-fails/20846 ), en la que una usuaria ha investigado el asunto con cuidado y señala un par de problemas potenciales. El equipo de SNAP ha anotado el problema, que aparece como pendiente en la parte pública de la web de seguimiento de incidencias (accesible aquí). Eso sí, lo han anotado como "Mosaic operator create empty data when using same projection of s2 input products (UTM)", aunque ya hemos visto que en nuestro caso no ha salido "empty" sino con valores imposibles.
Esperemos que la investigación de la incidencia sea ambiciosa y aclare el problema de manera completa y global. Aunque las limitaciones de los mosaicos con SNAP vayan más allá de este bug particular.