Hay una idea sencilla detrás de este experimento: guardar una imagen periódica del cielo de Elche y observar cómo cambia mientras pasan los aviones. La imagen no sería una fotografía tomada desde una cámara en tierra, sino una vista satelital de la zona —con nubes, temperatura, aerosoles o anomalías— descargada automáticamente y archivada junto con la posición de los vuelos.
El repositorio [NASA Worldview](https://github.com/nasa-gibs/worldview) es un punto de partida excelente para entender cómo hacerlo. La aplicación permite explorar más de mil capas de imágenes globales y usa [NASA GIBS (Global Imagery Browse Services)](https://nasa-gibs.github.io/gibs-api-docs/) como fuente principal. Worldview aporta la interfaz; GIBS aporta los servicios de mapas y las imágenes.
Qué contiene realmente el repositorio
Worldview es una aplicación web en JavaScript/Node.js basada en OpenLayers. El README describe una interfaz para navegar imágenes satelitales de resolución completa, con capas globales, línea temporal, anotaciones, eventos naturales, descargas y vistas polares. Algunas capas se actualizan diariamente y están disponibles aproximadamente tres horas después de la observación; las capas geoestacionarias pueden ofrecer imágenes en intervalos de diez minutos durante los últimos 90 días.
El repositorio sirve para varias cosas:
- **Entender la aplicación oficial:** instalación con `npm ci`, compilación con `npm run build` y arranque local con `npm start`.
- **Descubrir capas y metadatos:** la configuración se genera a partir de los documentos `GetCapabilities` de GIBS.
- **Crear una instalación personalizada:** basta copiar `config/default` a `config/active` y modificar la configuración activa.
- **Construir URLs reproducibles:** Worldview documenta parámetros para proyección, extensión geográfica y capas activas.
- **Estudiar integraciones:** el proyecto incluye descargas, snapshots, búsquedas, eventos naturales y ejemplos de despliegue con Docker.
No es, sin embargo, un repositorio que contenga un histórico de imágenes listo para consultar. Las imágenes se sirven desde GIBS mediante estándares geoespaciales como **WMS** y **WMTS**. Para una automatización, podemos usar la interfaz de Worldview como referencia y llamar directamente a GIBS.
Qué imagen tiene sentido pedir para Elche
El primer paso es definir una caja geográfica pequeña alrededor de Elche. Un encuadre razonable para la prueba sería aproximadamente:
min_lon=-0.85
min_lat=38.15
max_lon=-0.55
max_lat=38.38La caja incluye Elche, parte del litoral y el entorno del aeropuerto de Alicante-Elche. En una segunda iteración se puede ajustar para cubrir solo el corredor de aproximación o una zona más amplia de la provincia.
Para una primera imagen visual elegiría una capa de reflectancia en color verdadero, por ejemplo `MODIS_Terra_CorrectedReflectance_TrueColor` o su equivalente más reciente disponible en el `GetCapabilities`. Conviene comprobar la disponibilidad de cada capa antes de fijarla en producción: la resolución, la frecuencia y la latencia dependen del sensor.
Una petición WMS de imagen estática puede tener esta forma:
https://gibs.earthdata.nasa.gov/wms/epsg4326/best/wms.cgi?
SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&
LAYERS=MODIS_Terra_CorrectedReflectance_TrueColor&
STYLES=default&FORMAT=image/jpeg&TRANSPARENT=false&
CRS=EPSG:4326&BBOX=38.15,-0.85,38.38,-0.55&
WIDTH=1600&HEIGHT=1200&TIME=2026-08-24En WMS 1.3.0 el orden del `BBOX` depende del sistema de coordenadas. Para evitar sorpresas, recomiendo validar la orientación con una petición pequeña y conservar una prueba visual en el workflow. La documentación de GIBS ofrece ejemplos de `GetMap`, formatos PNG/JPEG/TIFF y composición de varias capas en una misma imagen.
Una precisión importante: “casi en tiempo real” no significa “cielo en directo”
La disponibilidad de la imagen no es uniforme. Una capa diaria puede llegar con horas de retraso y, además, tener zonas cubiertas por nubes. Las capas geoestacionarias son más frecuentes, pero su resolución y cobertura son distintas. Por eso guardaría siempre estos campos junto al archivo:
- hora de captura solicitada y hora de descarga;
- fecha/hora real disponible en la capa;
- sensor, producto e identificador de capa;
- bounding box, proyección, tamaño y formato;
- URL completa de la petición;
- respuesta HTTP y tamaño del archivo.
Así podremos distinguir una ausencia de nubes de una ausencia de datos, y una imagen nueva de una repetición servida por caché.
Cómo lo implementaría en n8n
La primera versión puede ser un workflow pequeño, ejecutado cada diez o quince minutos:
1. **Schedule Trigger.** Dispara el flujo con la frecuencia elegida. Para una capa diaria no tiene sentido consultar cada diez minutos; para una capa geoestacionaria sí puede ser razonable. 2. **Date & Time.** Genera la fecha UTC que se enviará en `TIME`. Para productos diarios, normalmente se usa `YYYY-MM-DD`; para productos subdiarios, se conserva el instante ISO. 3. **Set o Code.** Define las coordenadas de Elche, el identificador de capa, el tamaño de salida y un nombre de archivo como `elche_2026-08-24T12-10-00Z.jpg`. 4. **HTTP Request.** Solicita el endpoint WMS como archivo. En n8n hay que activar la descarga de respuesta binaria y asignarla a una propiedad, por ejemplo `data`. 5. **IF / manejo de errores.** Comprueba el código HTTP, que el contenido tenga un tipo `image/*` y que el tamaño no sea anormalmente pequeño. Si falla, se registra el error y se reintenta con backoff. 6. **Almacenamiento.** Guarda el binario en S3, Google Drive, MinIO o disco local. Para el proyecto elegiría almacenamiento por fecha: `worldview/elche/2026/08/24/…`. 7. **Registro de metadatos.** Inserta en SQLite, PostgreSQL o una tabla de n8n la URL, la capa, la fecha, el nombre del objeto y el estado de la petición. 8. **Cruce con aviones.** En una rama paralela se consulta el origen de vuelos que ya use el proyecto. Se guardan los aviones visibles en una ventana temporal alrededor de la imagen y se relacionan por intervalo, zona o proximidad. 9. **Notificación o publicación.** Opcionalmente, n8n envía un enlace a Telegram/Discord/email o actualiza una página del proyecto con la última imagen.
La URL se puede construir en un nodo **Code** para que todos los parámetros queden explícitos:
const p = {
layer: 'MODIS_Terra_CorrectedReflectance_TrueColor',
time: $json.time,
bbox: '38.15,-0.85,38.38,-0.55',
width: 1600,
height: 1200,
};
const qs = new URLSearchParams({
SERVICE: 'WMS',
VERSION: '1.3.0',
REQUEST: 'GetMap',
LAYERS: p.layer,
STYLES: 'default',
FORMAT: 'image/jpeg',
TRANSPARENT: 'false',
CRS: 'EPSG:4326',
BBOX: p.bbox,
WIDTH: String(p.width),
HEIGHT: String(p.height),
TIME: p.time,
});
return [{
json: {
...p,
imageUrl: `https://gibs.earthdata.nasa.gov/wms/epsg4326/best/wms.cgi?${qs}`,
},
}];En el nodo HTTP Request se usaría `{{$json.imageUrl}}`, respuesta **File** y propiedad binaria `data`. El nodo de almacenamiento debe conservar el binario sin convertirlo a base64 si el destino admite subida directa.
Cómo unirlo al proyecto de aviones
La unidad de análisis no sería la imagen aislada, sino un registro temporal compuesto:
imagen_id | image_time | layer | object_url | bbox | flights_count | flight_idsPara cada captura, el workflow puede consultar los vuelos de los cinco o diez minutos anteriores y posteriores. Después podemos mostrar una galería de imágenes, un mapa con la trayectoria de cada vuelo o una vista que permita seleccionar una captura y ver qué aviones estaban cerca en ese momento.
También hay una oportunidad analítica interesante: usar capas distintas para preguntas distintas. La imagen en color verdadero sirve para contexto visual; una capa de nubes o aerosoles puede ayudar a explicar por qué un vuelo no se ve; las anomalías térmicas o los eventos naturales pueden convertirse en señales adicionales. No conviene interpretar una huella en una imagen satelital como identificación de un avión: la resolución, el ángulo de observación y la nubosidad no garantizan ese nivel de detalle.
Qué tomaría del repositorio y qué no
Tomaría del repositorio la configuración de capas, la construcción de URLs, los parámetros de Worldview, la lógica temporal y la forma de enlazar servicios GIBS. Si en el futuro queremos una interfaz cartográfica propia, podríamos reutilizar OpenLayers o desplegar una instalación personalizada de Worldview.
No ejecutaría Worldview dentro de n8n. n8n debe orquestar tareas y almacenar resultados; Worldview es una aplicación web interactiva. Separar ambas responsabilidades hace el sistema más simple y evita mantener un navegador automatizado solo para descargar una imagen.
Plan de implementación por fases
**Fase 1 — prueba manual:** elegir una capa, validar el `GetCapabilities`, descargar una imagen de Elche y comprobar proyección, orientación y calidad.
**Fase 2 — workflow mínimo:** programar n8n, guardar imagen y metadatos, y registrar errores y tiempos de respuesta.
**Fase 3 — proyecto de aviones:** añadir la consulta de vuelos, claves temporales y una vista conjunta.
**Fase 4 — robustez:** deduplicación por URL y fecha, reintentos, alertas, almacenamiento con política de retención y validación de cambios en las capas.
La recomendación es empezar por una imagen diaria y no prometer una cadencia que el producto satelital no pueda ofrecer. Cuando el flujo sea estable, podemos cambiar a una capa geoestacionaria de mayor frecuencia y comparar el resultado.
Conclusión
NASA Worldview aporta una forma muy completa de explorar el catálogo; NASA GIBS aporta la interfaz de datos que necesitamos para automatizar. Con un único `GetMap`, un workflow de n8n y un registro de metadatos podemos crear un archivo visual del cielo de Elche y enlazar cada captura con el tráfico aéreo de la zona.
El valor del proyecto estará en la serie temporal y en el cruce entre fuentes, no en una imagen puntual. Por eso merece la pena diseñar desde el principio el nombre de los archivos, la zona horaria, la latencia, el producto satelital y la relación con los vuelos.
**Enlaces:** [Repositorio NASA Worldview](https://github.com/nasa-gibs/worldview) · [Configuración de Worldview](https://github.com/nasa-gibs/worldview/blob/main/doc/config/configuration.md) · [Parámetros de URL](https://github.com/nasa-gibs/worldview/blob/main/doc/url_parameters.md) · [Documentación de la API GIBS](https://nasa-gibs.github.io/gibs-api-docs/) · [Ejemplos WMS en Python](https://nasa-gibs.github.io/gibs-api-docs/python-usage/)