En una entrada anterior vimos cómo la SST se calculaba en base a un algoritmo Split-Window pero con variantes según los datos disponibles (dos o tres bandas, una o dos vistas por píxel); y cómo la variable "sst_algorithm_type" del fichero netCDF *L2P_GHRSST*.nc reportaba qué variante en particular se había utilizado. Pero ya dijimos también que es importante consultar otras variables de ese fichero antes de utilizar el producto de SST. Hay que tener en cuenta, por ejemplo, que la temperatura se calcula y reporta para muchos píxeles, incluso para aquellos que corresponden a nubes o donde la información auxiliar es menos fiable. Solamente no se calcula para datos sobre tierra o para nubes densas y frías donde el algoritmo da un valor anómalo.
Así que, cuando se quiera utilizar la imagen de temperatura para determinar la SST, es necesario consultar al menos dos variables. En primer lugar, la variable "l2p_flags", donde se asocia a cada píxel una etiqueta numérica correspondientes a las siguientes informaciones: [microwave, land, ice, lake, river, tidal, cosmetic_fill, day, sun_glint, cloud, pointing, exception, overflow, stratospheric, dual_nadir_diff_sst_type]. Si el píxel recibe alguna de las etiquetas peligrosas, como cloud o ice, no debería utilizarse. Estas etiquetas funcionan dando valor 0 ó 1 a un determinado bit dentro de un dato de 16 bits, de manera que hay que consultarlas bit a bit (sin considerar el valor numérico global asignado al píxel). Por supuesto SNAP lo hace perfectamente y facilita el dato en la pestaña de Pixel Info, pero hay que tener precauciones si se usa otra herramienta para visualizar este producto.
En segundo lugar, el fichero incluye una variable "quality_level", en la que se asocia a cada píxel una calidad entre las siguientes opciones:
Las calidades 2 a 5 se deciden a partir de umbrales en la incertidumbre teórica de cada píxel. Esa incertidumbre teórica se calcula combinando el ruido instrumental, las limitaciones del propio modelo split-window, la incertidumbre en el conocimiento del vapor de agua en la atmósfera (clave para corregir la interferencia atmosférica) y un factor relacionado con la proximidad del píxel a tierra y a nubes. Su valor se reporta en otra de las variables del fichero, la llamada "sst_theoretical_uncertainty".
EUMETSAT recomienda utilizar solo píxeles con calidad = 5 en las imágenes nocturnas, donde la detección de nubes es menos fiable que en las diurnas, ya que no está disponible la valiosa información del espectro visible, y píxeles con calidad 4 o 5 en las imágenes diurnas.
En las siguientes figuras hemos visualizado la información de calidad para la imagen diurna que discutimos en una entrada anterior (imagen adquirida el pasado 8 de abril al oeste de la península Ibérica). En la primera figura, se representa el número total de píxeles para las calidades 1 a 5; la calidad 0 se corresponde a píxeles de tierra y no merece la pena ser contabilizada. Aparte del elevado número de píxeles de nube (calidad 1), lo cual no tiene mayor relevancia, vemos que hay bastantes píxeles de calidad 2 y algunos de 3, lo que repercutiría en el análisis de la imagen tras excluir las zonas de nubes.
En la segunda figura se muestra el rango de temperaturas para cada calidad. Tanto en las zonas de tierra (calidad 0) como en nubes (calidad 1) el rango es muy amplio, pero en esos píxeles ni siquiera es válido el algoritmo de SST por lo que no hay que extrañarse. En las calidades 2 a 5 tenemos solo píxeles de mar o de masas de agua interiores (grandes ríos, lagos y embalses) y allí el rango se encoge. El menor rango es por supuesto para calidad 5, donde solo hay píxeles de océano.
Los (pocos) píxeles con calidad 4 y temperatura cercana a 40º C sí son sospechosos y, al consultar su posición en la imagen, se comprueba que corresponden a un borde de nube sobre el mar. Claramente la nube ha afectado al algoritmo split-window (ese valor de SST es imposible) y no se les debería haber asignado calidad 4. Esto es un pequeño fallo en la cadena de proceso, que podría afectar a eventuales estudios estadísticos de SST basados en esta imagen. Pero, por supuesto, estamos hablando de menos de una decena de píxeles en toda una imagen, donde (en este caso) hay 176452 píxeles con QL≥4: no está nada mal. Por tanto, ¡felicitaciones al equipo de proceso del dato SST del SLSTR!