Geografía financiera de Castilla y León · análisis espacial de POIs Open Data 2026

El análisis de la distribución espacial de servicios financieros en centros urbanos —bancos, cajeros, aseguradoras, gestorías y corredurías de seguros— ofrece una lectura directa de la vitalidad económica y la accesibilidad financiera de un territorio. Mapear estos puntos con assetIQ sobre datos Overture Maps permite identificar en minutos dónde se concentra la actividad financiera, qué zonas quedan en la periferia del servicio y cómo se estructuran los ejes comerciales de cada ciudad. El mismo análisis es replicable para cualquier otra capa temática —alojamiento, salud, restauración, deporte— convirtiendo cada capital de provincia en un dashboard geoespacial comparable y reproducible.

Más allá de la visualización individual por categoría, assetIQ calcula para cada edificio del área de interés un índice POIQ (POI Quality Index), un valor normalizado entre 0 y 1 derivado de la densidad de kernel de cada grupo temático en su entorno inmediato. Esto permite construir una matriz de correlación entre todas las categorías —Finanzas, Comercio, Alimentación, Salud, Alojamiento, etc.— midiendo mediante Pearson o Spearman en qué medida la concentración de un tipo de actividad coexiste o se excluye con otra. Una correlación alta entre Finanzas y Comercio en el mismo edificio o entorno indica sinergia espacial —los dos usos se retroalimentan y comparten eje urbano—; una correlación baja o negativa entre Alojamiento y Servicios Industriales señalaría segregación funcional. Esta capa analítica transforma la visualización de puntos en una herramienta de inteligencia urbana cuantificada, útil para inversores, entidades financieras en expansión, planificadores urbanos o consultores de localización que necesitan comparar ciudades de forma reproducible y objetiva.

Vamos a recorrer esta preciosa región a la que tengo tanto cariño y donde me licencié en su facultad de Geografía (en los Leones!) en Valladolid. Una por una y en orden alfabético para que nadie se queje 🙂

Ávila — El dinero dentro de las murallas

Imagen 1 – POIs Overture Maps sobre Ávila

Con 73 POIs financieros sobre un total de 2.058 (3,54%) en un radio de 3 km, Ávila muestra una concentración financiera muy marcada en el centro histórico, coherente con su estructura urbana compacta. El heatmap revela dos núcleos calientes claramente diferenciados: uno en torno al eje de la Plaza de Santa Teresa / Puerta del Alcázar, donde se agrupan las sucursales bancarias tradicionales, y un segundo foco algo más desplazado hacia el norte que probablemente corresponde a la zona de expansión comercial moderna. La categoría dominante es banks y financial_service, con presencia notable de atm y insurance_agency. El median center cae dentro del recinto amurallado, lo que confirma que el grueso de la oferta financiera sigue anclado al tejido histórico-comercial, sin haber migrado aún hacia las nuevas áreas residenciales del extrarradio. Para una ciudad de este tamaño, 73 registros financieros es una densidad razonable pero con escasa redundancia —cualquier cierre de sucursal tiene impacto real en la accesibilidad del servicio.Con 73 POIs financieros sobre un total de 2.058 (3,54%) en un radio de 3 km, Ávila muestra una concentración financiera muy marcada en el centro histórico, coherente con su estructura urbana compacta. El heatmap revela dos núcleos calientes claramente diferenciados: uno en torno al eje de la Plaza de Santa Teresa / Puerta del Alcázar, donde se agrupan las sucursales bancarias tradicionales, y un segundo foco algo más desplazado hacia el norte que probablemente corresponde a la zona de expansión comercial moderna. La categoría dominante es banks y financial_service, con presencia notable de atm y insurance_agency. El median center cae dentro del recinto amurallado, lo que confirma que el grueso de la oferta financiera sigue anclado al tejido histórico-comercial, sin haber migrado aún hacia las nuevas áreas residenciales del extrarradio. Para una ciudad de este tamaño, 73 registros financieros es una densidad razonable pero con escasa redundancia —cualquier cierre de sucursal tiene impacto real en la accesibilidad del servicio.

Burgos — Dos ciudades, dos bancas

Imagen 2 – POIs Overture Maps sobre Burgos

Con 145 POIs financieros sobre 4.202 totales (3,45%) en un radio de 3 km, Burgos duplica en volumen absoluto a Ávila manteniendo una proporción relativa casi idéntica, lo que sugiere que el peso del sector financiero en el tejido urbano de las capitales castellanas tiende a estabilizarse en torno al 3,5% independientemente del tamaño. El heatmap es especialmente revelador: muestra dos núcleos claramente separados en lugar de uno, con un foco principal muy intenso en el centro histórico —eje Paseo del Espolón / Calle Vitoria, el corredor comercial y bancario por excelencia de la ciudad— y un segundo núcleo de menor intensidad hacia el sur, en la zona de

Gamonal, el barrio obrero y comercial más poblado de Burgos. Esta dualidad refleja la estructura socioeconómica real de la ciudad: banca tradicional y de gestión patrimonial concentrada en el centro, banca minorista y cajeros orientados al consumo cotidiano en Gamonal. El median center se desplaza hacia el oeste respecto al centro geométrico del buffer, ajustándose al eje financiero real. La presencia de business_banking_service y tax_services entre las categorías más frecuentes apunta a una demanda corporativa relevante, coherente con el perfil industrial y logístico de Burgos como nodo de la A-1.

León — La red financiera que siguió a la población

Imagen 3 – POIs Overture Maps sobre León

Con 151 POIs financieros sobre 5.121 totales (2,94%) en un radio de 3 km, León presenta la proporción relativa más baja de las tres primeras ciudades analizadas, lo que resulta llamativo dado que es la capital más poblada del grupo. Este descenso porcentual puede indicar una mayor diversificación del tejido urbano —más peso de servicios, hostelería y comercio— que diluye el peso relativo del sector financiero, o bien una menor densidad de sucursales físicas fruto de la digitalización bancaria más acelerada en ciudades medianas con población envejecida. El heatmap muestra un patrón más fragmentado y difuso que el de Burgos: hay un núcleo caliente principal en torno al eje Ordoño II / Calle Ancha, el corredor financiero y comercial histórico de León, pero con varios satélites de intensidad media dispersos hacia el norte y el noreste, en los barrios de expansión residencial. Esta dispersión sugiere que la banca minorista ha seguido a la población hacia los nuevos desarrollos urbanos más activamente que en otras capitales. El median center se posiciona con precisión sobre el centro comercial consolidado, aunque la nube de puntos secundarios le resta nitidez al análisis de concentración. La presencia de bank_credit_union entre las categorías destacadas es notable — inusual en ciudades de este tamaño en España y podría apuntar a entidades de crédito cooperativo con implantación regional fuerte en Castilla y León.

Palencia — Más bancos de los que el tamaño explica

Imagen 4 – POIs Overture Maps sobre Palencia

Con 105 POIs financieros sobre 2.620 totales (4,00%) en un radio de 3 km, Palencia registra la proporción relativa más alta de las capitales analizadas hasta ahora, superando el umbral del 4% — dato significativo para una ciudad de apenas 75.000 habitantes. Esto sugiere que el sector financiero está sobredimensionado respecto al tamaño urbano, posiblemente como herencia de una época de mayor actividad económica industrial y agraria en la que Palencia actuaba como plaza bancaria de referencia para toda su provincia. El heatmap es el más concentrado y compacto del grupo: un núcleo central de altísima densidad en torno a la Calle Mayor y el eje Calle Menéndez Pelayo, con dos lóbulos secundarios bien definidos al norte y al sur que siguen perfectamente el trazado del ensanche urbano histórico. Esta morfología de “trébol” es característica de ciudades con estructura urbana lineal a lo largo de un eje principal. El median center coincide prácticamente con el centro geométrico del núcleo financiero, lo que indica una distribución excepcionalmente equilibrada sin outliers que lo desplacen. Destaca la presencia de atm como categoría muy frecuente — inusualmente alta para el tamaño de la ciudad — lo que podría reflejar una red de cajeros sobredimensionada respecto a la demanda actual, un indicador típico de territorios en proceso de contracción demográfica donde las entidades mantienen infraestructura física heredada.

Salamanca — El Toro manda: concentración sin fisuras

Imagen 5 – POIs Overture Maps sobre Salamanca

Con 178 POIs financieros sobre 5.846 totales (3,04%) en un radio de 3 km, Salamanca es la ciudad con mayor volumen absoluto de servicios financieros del grupo hasta ahora, aunque su proporción relativa se mantiene en la media del conjunto. Lo verdaderamente distintivo aquí es la morfología del heatmap: un núcleo único de densidad extraordinariamente alta, compacto, casi circular, centrado sobre el eje Gran Vía / Calle Toro — el corredor financiero y comercial más potente de Castilla y León fuera de Valladolid. La ausencia de lóbulos secundarios relevantes indica que la actividad financiera en Salamanca no se ha descentralizado: todo permanece anclado en el centro histórico consolidado, posiblemente reforzado por la demanda de una población universitaria numerosa que genera una necesidad constante de servicios bancarios minoristas, cambio de divisa e insurance_agency vinculados a alquiler residencial. El median center se desplaza claramente al norte respecto al marcador de posición, confirmando que el peso financiero real está en la mitad norte del buffer — la ciudad histórica — y no en los desarrollos del sur del Tormes. La categoría money_transfer_services tiene aquí una presencia destacada, coherente con una ciudad universitaria con alta proporción de estudiantes internacionales que necesitan remesas y transferencias internacionales con frecuencia.

Segovia — La topografía parte el mapa financiero en dos

Imagen 6 – POIs Overture Maps sobre Segovia

Con 94 POIs financieros sobre 2.258 totales (4,16%) en un radio de 3 km, Segovia comparte con Palencia el honor de superar el umbral del 4% de concentración financiera relativa, siendo junto a ella la ciudad con mayor densidad proporcional del grupo. Para una ciudad de apenas 50.000 habitantes esto es llamativo y merece interpretación: Segovia actúa históricamente como capital administrativa y judicial de una provincia amplia y dispersa, lo que genera una demanda de servicios financieros formales —notarías, gestorías, banca de empresa agraria— que va más allá de lo que su población residente justificaría por sí sola. El heatmap muestra un patrón bilobulado muy nítido: un núcleo principal de alta intensidad sobre el eje de la Calle Real y la Plaza Mayor —el corredor financiero histórico intramuros— y un segundo foco claramente separado hacia el sur, en el ensanche moderno de San José / La Fuentecilla, donde la banca minorista ha seguido el crecimiento residencial de las últimas décadas. La separación física entre ambos núcleos es más pronunciada que en cualquier otra ciudad del grupo, reflejo de la topografía segoviana que impone una ruptura urbana real entre la ciudad histórica sobre el cerro y la ciudad moderna en el llano. El median center cae precisamente en el valle entre ambos núcleos, un punto que geográficamente no corresponde a ninguna concentración real — lo que ilustra perfectamente la limitación del centroide en distribuciones bimodales y refuerza el valor del heatmap como herramienta complementaria.

Soria — Todo en el Collado, nada más allá

Imagen 7 – POIs Overture Maps sobre Soria

Con 52 POIs financieros sobre 1.585 totales (3,28%) en un radio de 3 km, Soria es la ciudad con menor volumen absoluto del grupo, reflejo directo de ser la capital de provincia menos poblada de España con apenas 38.000 habitantes. Sin embargo, su proporción relativa del 3,28% se mantiene dentro de la banda central del conjunto, lo que indica que el tejido financiero, aunque pequeño, está presente de forma proporcionalmente coherente. El heatmap es el más monocéntrico y concentrado de todas las capitales analizadas: un único núcleo de densidad muy alta, casi perfectamente circular, centrado sobre el Collado —la calle peatonal principal de Soria— sin ningún lóbulo secundario de relevancia. Esta morfología de punto único es la expresión geoespacial de una ciudad que no ha experimentado descentralización urbana real: todo el comercio, la administración y los servicios financieros permanecen en el casco histórico compacto, sin expansión hacia barrios periféricos con entidad propia. El median center coincide prácticamente con el centroide visual del núcleo, algo que solo ocurre en distribuciones perfectamente unimodales como esta. Llama la atención que con tan solo 52 registros, Soria cuente con una representación completa de subcategorías —banks, atm, insurance_agency, tax_services, business_banking_service— lo que indica que todas las tipologías de servicio financiero están presentes aunque con un único representante por tipo, una situación de mínima redundancia y máxima vulnerabilidad ante cierres o reubicaciones.

Valladolid — La capital que no necesita un solo centro

Imagen 8 – POIs Overture Maps sobre Valladolid

Con 274 POIs financieros sobre 7.420 totales (3,79%) en un radio de 3 km, Valladolid es con claridad la capital financiera de Castilla y León en términos absolutos, con casi el doble de registros que Salamanca y casi cinco veces más que Soria. Su proporción relativa del 3,79% es además la segunda más alta en volumen significativo del grupo, lo que indica que el sector financiero no solo crece con la ciudad sino que lo hace a un ritmo ligeramente superior al resto de actividades. El heatmap es cualitativamente diferente al de todas las demás capitales: en lugar de uno o dos núcleos discretos, Valladolid muestra una mancha de alta densidad continua y extensa que cubre prácticamente todo el centro urbano consolidado, desde el eje Paseo de Zorrilla al sur hasta la Plaza de España al norte, con una intensidad sostenida que no decae bruscamente en los bordes sino que se difumina gradualmente. Esto refleja una ciudad que ha desarrollado un tejido financiero maduro y policéntrico, sin dependencia de un único eje bancario. Destaca especialmente la presencia de business_banking_service y business_brokers como categorías relevantes — un indicador claro de que Valladolid concentra banca corporativa y servicios de intermediación empresarial propios de una capital regional con sede de instituciones autonómicas, universidad técnica consolidada e industria de automoción. El median center se sitúa sobre el corazón del centro histórico comercial, pero dada la extensión de la mancha caliente, su poder discriminatorio es aquí menor que en ciudades más compactas — el verdadero valor analítico en Valladolid está en la extensión del heatmap, no en su pico.

assetIQ_Valladolid_pois Descarga

assetIQ_Valladolid_poiq_correlaciones Descarga

assetIQ_Valladolid_poiq_edificios Descarga

Zamora — Centro histórico sólido, periferia por construir

Imagen 9 – POIs Overture Maps sobre Zamora

Con 74 POIs financieros sobre 2.520 totales (2,93%) en un radio de 3 km, Zamora presenta la proporción relativa más baja de todo el grupo junto a León, lo que resulta especialmente significativo considerando que es una ciudad de tamaño similar a Ávila o Soria pero con una densidad financiera notablemente inferior. Este dato apunta a una economía local con menor actividad empresarial formal y mayor dependencia del sector primario y la administración pública, sectores que generan menos demanda de servicios financieros especializados. El heatmap muestra un patrón claramente asimétrico: un núcleo principal intenso y compacto sobre el centro histórico en torno a la Calle Santa Clara y la Plaza Mayor, y un lóbulo secundario hacia el sur en el barrio de Pinilla — el desarrollo residencial más activo de Zamora en las últimas décadas — de intensidad considerablemente menor. La separación entre ambos núcleos es limpia, sin gradiente continuo entre ellos, lo que sugiere que la banca en Pinilla responde exclusivamente a la demanda residencial local sin haber desarrollado aún una masa crítica de servicios corporativos o especializados. El median center se posiciona sobre el centro histórico pero ligeramente desplazado hacia el sur, traccionado por el peso de Pinilla. Destaca que con solo 74 registros, Zamora muestra todas las subcategorías financieras presentes en ciudades más grandes, incluyendo business_brokers y business_banking_service — lo que podría indicar cierta sobreestimación en la clasificación de Overture para esta ciudad, o bien la presencia de servicios orientados al sector agroindustrial zamorano que justifican esta tipología.

Conclusión

Este estudio sobre la distribución de POIs financieros en las nueve capitales de provincia de Castilla y León ha sido posible gracias a una combinación de herramientas enteramente abiertas y reproducibles.

Imagen 10 – asseIQ por edificio representado para mostrar zonas “calientes” en relación a FINANZAS en Valladolid

Imagen 11 – Representación gráfica exagerada x1000 del atributo “FINANZAS” por edificio en Valladolid para simplificar la comprensión

El stack técnico (R, Shiny, DuckDB y Overture Maps) permite ejecutar el análisis completo en menos de un minuto por ciudad, consultando directamente los archivos GeoParquet almacenados en S3 sin necesidad de descargar ni almacenar datos localmente. El release utilizado data de apenas unos días (20260722) lo que garantiza que los datos reflejan el estado más reciente del dataset, una ventaja competitiva real respecto a fuentes estáticas que se actualizan anualmente o de forma irregular.

Imagen 12 – POIs Overture Maps sobre Valladolid (detalle en el centro de la ciudad)

Cada POI incorpora en su tabla de atributos un campo sources_json que documenta su procedencia exacta: meta, microsoft, tomtom, osm o combinaciones de varias fuentes. Esta trazabilidad es fundamental para evaluar la fiabilidad de cada registro y para entender sesgos potenciales, por ejemplo, la cobertura de Meta tiende a ser más completa en establecimientos de hostelería y comercio, mientras que OSM aporta mayor precisión en equipamientos públicos y elementos urbanos estructurales.

Imagen 13 – Matriz de correlaciones por categorías en Valladolid

Más allá de la visualización, la verdadera aportación analítica reside en el POIQ y en la matriz de correlaciones entre categorías. Que Deporte y Educación presenten correlaciones altas no es una casualidad (los equipamientos deportivos y los centros educativos comparten lógica de implantación: se sitúan en barrios residenciales consolidados con suelo disponible, alejados del centro comercial). Que Restauración y Alojamiento correlacionen fuertemente tampoco sorprende (ambos responden a la misma demanda turística y de negocios, co-localizándose en los mismos ejes urbanos). A todo ello se añade el campo confidence que Overture asigna a cada POI — un valor entre 0 y 1 que estima la probabilidad de que ese establecimiento exista realmente en esa ubicación — y que permite ponderar o filtrar los registros antes del análisis, descartando aquellos por debajo de un umbral de fiabilidad y garantizando que el POIQ se construye sobre datos contrastados y no sobre ruido. Estas correlaciones no son observaciones subjetivas: son medidas estadísticas reproducibles que permiten comparar ciudades, detectar anomalías y fundamentar decisiones de inversión o planificación con base científica.

Frente a los rankings cualitativos o los informes de percepción, la cuantificación espacial apoyada en open data ofrece algo diferente: equilibrio territorial medible, comparable y auditable. Todas las ciudades analizadas con el mismo método, el mismo radio, la misma fecha, la misma escala y los mismos criterios. Eso es lo que convierte un mapa bonito en una herramienta de política pública o de estrategia empresarial.

Análisis realizado con assetIQ · R · DuckDB · Overture Maps release 20260722.0 · Geovisualization.net

Alberto Concejal
Analista GIS
https://geovisualization.net/

fuentes:
Overture Maps Foundation — Places dataset, release 2026-05-20 · overturemaps.org DuckDB + httpfs extension — Serverless querying of remote Parquet files · duckdb.org R Project & Shiny — Statistical computing and interactive web applications · r-project.org · shiny.posit.co OpenStreetMap contributors — Base cartography via Stadia Maps / OpenMapTiles · openstreetmap.org Esri World Imagery — Satellite basemap · esri.com assetIQ · Geovisualization.net — Spatial POI intelligence tool · geovisualization.net

El kernel que sigue al fuego: reconstruyendo el pulso de un fuego con datos satelitales

He pasado los últimos días construyendo Fire Kernel Tracker, una app en R Shiny que representa el ciclo de vida completo de un incendio forestal: desde el primer foco hasta la extinción, usando un kernel de densidad espacio-temporal ponderado por FRP (Fire Radiative Power) sobre detecciones satelitales VIIRS/MODIS de NASA FIRMS.

Image 1 – Exportando a GIF los puntos FRP

La idea de partida era sencilla: en vez de mostrar puntos de calor sueltos como hace casi cualquier visor de incendios, quería ver cómo se mueve y se concentra la intensidad térmica día a día. Cada jornada del incendio genera una superficie de densidad ponderada por la energía radiativa real de cada detección, no solo por su posición. El centroide ponderado de cada día se conecta en una trayectoria, y una curva de FRP total muestra el patrón clásico de nacimiento, crecimiento, pico y apagado.

Usé como caso de estudio el incendio de Paüls, en el Parque Natural dels Ports (Tarragona), que ardió del 7 al 16 de julio de este año y quemó más de 3.300 hectáreas, avanzando hacia el sureste empujado por viento de mistral hasta cruzar el Ebro a la altura de Tivenys.

Trabajar con datos reales de satélite en vez de datos sintéticos me dejó una lección que vale más que la propia app: la detección activa de incendios vía satélite es muchísimo más escasa de lo que uno imagina. Un solo satélite VIIRS puede pasar por una zona muy pocas veces al día, y entre nubes, humo y el propio algoritmo de detección, un incendio de miles de hectáreas puede dejar solo un puñado de píxeles de detección algunos días. Combinar varios satélites (Suomi-NPP, NOAA-20, NOAA-21) ayuda, pero la dispersión real de los datos de campo es una diferencia enorme frente a cualquier simulación pedagógica, y es exactamente el tipo de matiz que solo se aprende peleándose con la API en vivo.

Técnicamente, la app usa un KDE ponderado (paquete ks) convertido a bandas de densidad rellenas sobre un raster de terra, con exportación a GIF animado y a KML para verlo directamente en Google Earth. Todo en R Shiny, con estética oscura y sin dependencias de mapas de pago.

Image 4 – Exportando el KMZ para compartir en Google Earth

Image 5 – Apertura de la secuencia en Google Earth, día tras día…

Sigo ampliando el repertorio de herramientas geoespaciales aplicadas a gestión de emergencias y análisis de riesgo. Si trabajas en este espacio o simplemente te interesa el tema, encantado de charlar.

Alberto Concejal
Analista de Geodatos

Fuentes:
NASA FIRMS: https://firms.modaps.eosdis.nasa.gov/
https://view.eumetsat.int/productviewer?v=default
EFFIS (Copernicus): https://forest-fire.emergency.copernicus.eu/
Incendio de Paüls, cobertura en directo: https://www.eldiario.es/catalunya/incendio-baix-ebre-tarragona-quema-1-500-hectareas-generalitat-pide-activacion-ume_1_12446515.html
Incendio de Paüls, avance hacia el sureste: https://www.elnacional.cat/es/sociedad/incendio-forestal-pauls-baix-ebre-viento-mistral-empuja-llamas-complica-trabajo_1447748_102.html
Paquete ks (CRAN): https://cran.r-project.org/package=ks
Paquete terra (CRAN): https://cran.r-project.org/package=terra

Super-resolution 1m vs ‘Google Maps de Incendios Forestales’ en Guadalajara, España 20260723

Ya sé que es una obviedad pero la precisión importa… Un caso de estudio de por qué la resolución espacial importa en comunicación de crisis, no solo en análisis técnico. Después de un tiempo con problemas con un código para generar Super-resolution en Google COLAB, lo he conseguido arreglar (gracias a Claude y a mis conocimientos de fuentes geoespaciales, todo sea dicho, que pareciera que todo olo hace la IA, ¡No!). Varios días de trabajo ahorrado.

Imagen 1 – Asedio de las llamas en Las Navas de Jadraque en Guadalajara 20260722.

Parece que ya estamos llegando al final de este incendio pero se ha “comido” casi 32,000 ha! y me llamó la atención cómo lo tienen que haber pasado los habitantes de este pequeño pueblo de la zona llamado Las Navas de Jadraque que según Google Maps, se quemó enteramente… el fuego de la Sierra Norte de Guadalajara es exactamente ese tipo de incendio “mega” (más de 30.000 ha, nivel 2, decenas de pueblos evacuados) donde la cobertura mediática y las capas de datos rápidos tienden a generalizar y “tragarse” núcleos de población que en realidad sobrevivieron, sobre todo cuando hay defensa activa in situ. De hecho el alcalde de Las Navas de Jadraque, Eliseo Marigil, relató que ha estado subiendo y bajando al pueblo desde el viernes, y que dos ganaderos con cerca de 200 cabezas de vacuno y otros cuatro vecinos se quedaron con su permiso — precisamente porque las llamas se reavivaron varias veces tras el paso del grueso del incendio y hacía falta alguien in situ para avisar. Un frente que “pasa” pero no arrasa el núcleo urbano, algo que un perímetro generalizado tipo Google/FIRMS puede pintar como “absorbido” sin serlo.

Imagen 2 – Google Maps y su capa de incendios en curso.

Google Maps / capas de incendio activo suelen basarse en detecciones térmicas MODIS/VIIRS (375m–1km) o en perímetros oficiales generalizados (buffers, KML simplificados), no en clasificación de superficie real. A esa resolución, un pueblo pequeño como Las Navas de Jadraque (área municipal ~8 km², núcleo urbano mucho más pequeño) puede quedar completamente “engullido” por un solo píxel de detección térmica cercana, aunque el pueblo en sí nunca ardiera.

Imagen 2b – Google Maps y su capa de incendios en curso

Antes de ayer 20260721 estaba rodeando el pueblo pero ya no había movimiento en la zona según vemos en el Copernicus browser visualizando el SWIR.

Imagen 3 – Combinación 12-8A-4 de Sentinel 2

Visualizando el NIR y haciendo un poco de zoom lo vemos todavía con más claridad pero

Imagen 4 – Combinación 8-4-3 en el NIR de Sentinel 2. 20260721

Imagen 4b – Detalle del NIR de Sentinel 2 sobre Las Navas de Jadraque. 20260721

Con este pipeline de Google Colab (es curioso, Google Maps “la caga” y Google Colab le rectica, jeje) se puede mostrar el perímetro real de la cicatriz de quemado vs. el núcleo urbano intacto, algo que a 375m-1km de resolución es literalmente invisible. Esto es justo lo que confirma la fuente sobre el terreno: tras el paso del grueso del incendio las llamas se reavivaron en varias ocasiones y fueron controladas gracias a que había alguien allí para avisar, es decir, hubo defensa activa del núcleo, consistente el hallazgo de que el pueblo no fue absorbido. ¡Bien!

Imagen 5 – Detalle de lo cerca que estuvieron las llamas de engullir el pueblo

https://gamayos.github.io/gamma-earth-api/s2dr3-demo-20250305.html?ds=ES-T30TVL-d19a106ce-20260721#15.48/41.10267/-3.023907

¿Te interesa usar este script de Python? Prueba tú mismo en Google COLAB (https://colab.research.google.com/). Nada más que tienes que actualizar los datos de nombre de proyecto, ubicación y fecha de la imagen Sentinel 2 elegida, en mi caso 2026-07-21:

Celda1 (montar drive)

			
from google.colab import drive
import os
from datetime import datetime
drive.mount('/content/drive')
output_path = '/content/drive/MyDrive/Sentinel2_nombreproyecto'
!mkdir -p {output_path}
!rm -rf /content/output
!ln -s {output_path} /content/output

		

Celda2 (instalación, obviar el mensaje de error: “pip’s dependency…”)

			
!pip -q install https://storage.googleapis.com/0x7ff601307fa5/s2dr3-20250905.1-cp312-cp312-linux_x86_64.whl

Celda3 (instalación2, obviar el mensaje de error: “pip’s dependency…”)

!pip -q install --upgrade --force-reinstall scipy numba

Celda4 (comprobación)

			
import s2dr3.inferutils
print("Import OK")

Celda5 (actualizar ubicación y fecha)

			
lonlat = (-3.0253240108598822, 41.10178516492805) # (lon, lat) - Las Navas de Jadraque, Guadalajara
date_actuelle = '2026-07-21'

Celda6 (lanzado)

			
print(f"Lancement de la super-résolution pour Las Navas de Jadraque (Date cible : {date_actuelle})...")
s2dr3.inferutils.test(lonlat, date_actuelle)
print(f"Traitement terminé. Les fichiers sont dans : {output_path}")

Este caso demuestra que las capas de “incendios activos” que ofrecen plataformas como Google Maps —basadas en detecciones térmicas de baja resolución (300m-1km) o en perímetros oficiales generalizados— tienden a sobreestimar el área realmente afectada, pudiendo dar por “absorbidos” núcleos urbanos que en realidad resistieron gracias a la defensa activa sobre el terreno, como ocurrió en Las Navas de Jadraque. Frente a esto, propongo un enfoque complementario: el uso de superresolución aplicada a imágenes Sentinel-2 (10m) para reconstruir la cicatriz de quemado a escala de 1m, permitiendo distinguir con precisión qué estructuras y núcleos de población quedaron realmente dentro del perímetro de quemado y cuáles se salvaron. Este tipo de análisis no pretende sustituir a los sistemas de alerta temprana —que priorizan velocidad sobre precisión geométrica— sino complementarlos en la fase de evaluación post-incendio, aportando una capa de verdad-terreno de bajo coste y alta resolución que resulta especialmente valiosa para la gestión de emergencias, la comunicación a la población afectada y la planificación de la recuperación.

Espero que te haya interesado. Si es así, esta vez no lo dejes. Dame un toque que quiero llegar a los 2000 seguidores pronto. ¿Para qué? Para encontrar un trabajo útil e interesante lo antes posible 🙂 ¡Saludos cordiales!.

Alberto Concejal
Analista Geospacial

Fuentes
https://colab.research.google.com/
https://browser.dataspace.copernicus.eu/
https://www.google.com/maps/@41.0858821,-3.0765216,12.94z/data=!5m1!1e8?entry=ttu&g_ep=EgoyMDI2MDcyMC4wIKXMDSoASAFQAw%3D%3D
https://www.sigterritoires.fr/index.php/es/uso-de-s2dr3-en-google-colab-para-el-estudio-de-los-corales-en-mauricio/
https://geovisualization.net/2026/03/18/super-resolution-1-m-a-cadalso-de-los-vidrios-madrid-avec-sentinel-2-10m-magique/
https://www.bseed.eu/
https://forest-fire.emergency.copernicus.eu/

De NDVI a CO2e: un pipeline MRV de estimación de emisiones FLAG con GEE

Imagina una empresa que se llama ACME. ACME es dueña de 5 parcelas de tierra en Almendralejo, Extremadura, España, donde se cultiva cereal (trigo, cebada, ese tipo de cosas). Entre las 5 parcelas, ACME tiene un total de 1.52 km² de tierra — para que te hagas una idea, eso es más o menos el tamaño de 300 campos de fútbol (a razón de aproximadamente media hectárea por cada campo).

ACME quiere saber algo importante: ¿sus tierras están absorbiendo CO2 (dióxido de carbono, el gas que calienta el planeta) o están soltando más del que absorben?

Esto no es solo curiosidad. Cada vez más empresas en el mundo están obligadas — o quieren voluntariamente — a medir y reducir su huella de carbono (la cantidad de CO2 que generan sus actividades). Y para las empresas que trabajan con tierra, cultivos o ganado, existe un estándar específico llamado FLAG (Forest, Land and Agriculture, que en español sería “Bosques, Tierra y Agricultura”). FLAG es parte de un marco más grande llamado SBTi (Science Based Targets initiative, o “iniciativa de objetivos basados en ciencia”), que ayuda a las empresas a fijar metas de reducción de emisiones que de verdad tengan sentido científico, no solo buenas intenciones.

Imagen 1 – NDVI a lo largo de la secuencia temporal

Aquí es donde entra el satélite. En vez de mandar a alguien a caminar por 1.52 km² de campo (que llevaría días), podemos usar imágenes satélite servidas por el programa Copernicus de la UE Sentinel-2, que toma imágenes de toda la superficie de la Tierra cada pocos días (dependiendo de cuál sea tu latitud, la cadancia de paso por el mismo sitio, varía).

Con esas imágenes calculamos algo llamado NDVI (Normalized Difference Vegetation Index, o “índice de vegetación de diferencia normalizada”). No te asustes con el nombre — es simplemente un número entre 0 y 1 que nos dice cuánta planta verde y sana hay en un lugar. Cuanto más alto el número, más vegetación viva hay ahí.

La idea es sencilla: comparamos el NDVI de las parcelas de ACME hace unos años con el NDVI ahora. Si la vegetación ha crecido más, probablemente se está absorbiendo más carbono. Si ha disminuido, puede significar que se ha perdido cultivo, se ha abandonado la tierra, o algo ha cambiado para peor.

Quieres probar con tus datos?. Sube un ASSET y simplemente dale a “Ejecutar análisis”. ¿Así de fácil?. Así de AL-GIS 🙂

https://analysis202601.projects.earthengine.app/view/mrv-emissions-estimations-flag

Todo este cálculo lo hacemos con una herramienta de Google llamada GEE (Google Earth Engine), que permite analizar miles de imágenes de satélite sin tener que descargarlas una por una.

Imagen 2 – Las 5 parcelas de la empresa, Total 1,521 km2

Después de analizar las 5 parcelas, comparando el vigor de la vegetación entre dos periodos distintos, y convirtiendo ese cambio en toneladas de carbono, este es el resultado:

Balance neto CO2e de la cadena de suministro: 369.39 toneladas

(CO2e significa “CO2 equivalente” — es una forma de expresar distintos gases de efecto invernadero todos con la misma unidad, como si fueran “todos CO2”, para poder compararlos fácilmente.)

¿Qué significa este número?

Un balance positivo de +369.39 toneladas de CO2e quiere decir que, en conjunto, las tierras de ACME están absorbiendo más carbono del que están soltando. Dicho de otra forma: las plantas de esas parcelas han crecido más ahora que antes, así que están actuando como una especie de “esponja” que saca CO2 del aire y lo guarda en forma de materia vegetal.

Balance neto CO2e: 369.39 t

Balance positivo: la cadena de suministro está absorbiendo más carbono del que emite

Para darte una referencia: 369 toneladas de CO2 es aproximadamente lo que emitirían unos 80 coches en un año entero de circular por carretera. Así que ACME, en vez de sumar esa cantidad a la atmósfera, la está restando — buena noticia para su reporte de sostenibilidad.

Pero (y esto es importante) el resultado no fue igual en las 5 parcelas. Cuando miramos parcela por parcela, encontramos que 4 de las 5 mejoraron, pero una parcela mostró una caída real — una señal de que ahí algo sí merece revisión más de cerca, quizá un cambio de cultivo, un abandono parcial, o una mala campaña agrícola.

Imagen 3 – Comienzo y final de la secuencia. Vigor fenológico 2020-2025

Aquí viene la parte más interesante del proyecto: al principio, el análisis pareció detectar problemas en 3 parcelas, no solo en 1. Pero al investigar más, descubrimos que 2 de esas 3 “alarmas” eran falsas — el satélite había tomado imagenes de esas parcelas justo después de la cosecha en un año, y antes de la cosecha en el otro, así que parecía que la vegetación había desaparecido cuando en realidad solo era el ciclo normal del cultivo (el cereal se siembra, crece, se cosecha, y el campo queda “pelado” una temporada, para volver a empezar al año siguiente).

Esto nos enseña algo clave sobre medir carbono con satélites: hay que comparar las cosas en el momento correcto del año, o los resultados pueden engañarnos. Es como comparar una imagen de un árbol en invierno (sin hojas) con una foto en verano (con hojas) y concluir que el árbol está enfermo — cuando en realidad solo es la estación del año.

Imagen 4 – output CSV con cuantificación precisa de huella de carbono CO2e

Con imágenes de satélite gratuitas y unas cuantas líneas de código, es posible estimar si un terreno agrícola está ayudando o perjudicando en la lucha contra el cambio climático — sin necesidad de pisar el campo. Eso sí, hay que tener cuidado con las trampas metodológicas, como comparar fechas equivocadas, porque pueden hacer que saques conclusiones equivocadas.

Imagen 5 – Interfaz de mi aplicación MRV-Emissions-Estimations-FLAG

Nota: este análisis es una demostración técnica con fines de portfolio, usando factores de conversión simplificados. Un informe FLAG oficial para reporting corporativo requeriría validación de campo y auditoría externa siguiendo la metodología completa de SBTi.

Alberto Concejal
Analista Geoespacial

Fuentes:
https://www.miteco.gob.es/es/cambio-climatico/temas/registro-huella/que_es_registro.html
https://www.boe.es/buscar/doc.php?id=BOE-A-2025-7439
https://www.myeasyfarm.com/es/sbti-flag-cest-quoi/
https://eco-act.com/es/blog/sbti-lanza-la-primera-guia-flag/
https://grupoaltius.com/certificado-de-huella-de-carbono-altius/
https://www.asociacionhuelladecarbono.org/

Start · Engage · Match. Un simulador de compatibilidad social en un bar de verdad (sin decirse ni una palabra)

1. Resumen ejecutivo

Start Engage Match es un simulador interactivo, autocontenido en un único archivo HTML/JavaScript, que modela cómo un grupo de personas con gustos, orientaciones y niveles de paciencia distintos se cruza en el espacio físico de un bar y, en determinadas condiciones, genera afinidad y —ocasionalmente— una conexión completa («match»).

A lo largo de este documento, la aplicación y el local que representa comparten un único nombre: Start · Engage · Match, que además describe con precisión sus tres fases —se pulsa Empezar, se produce el Engage al cruzarse dos personas, y algunas veces surge el Match—.

https://start-engage-match.netlify.app

El sistema combina cuatro capas de simulación que se ejecutan en tiempo real sobre un lienzo (canvas) de 20×20 metros: un modelo espacial del local (barra, pista de baile, zonas de sofás), un modelo de comportamiento individual (movimiento hacia puntos de interés, paciencia, abandono), un modelo de interacción social (el «engage» o encuentro, con una capa de compatibilidad y una capa de atracción física aleatoria) y un modelo temporal y económico que reproduce el ciclo de una noche real de bar, de 17:00 a 05:00.

El resultado se expresa como una animación en vivo, un panel de estadísticas con métricas de negocio (ingresos, coste por match) y un registro narrativo de los encuentros completos, generado automáticamente.

2. Portada de la aplicación

Al abrir el archivo, antes de acceder al simulador, se muestra una pantalla de portada con el logotipo de la aplicación y un botón «Entrar» que da paso a la sala.

El logotipo es un lockup horizontal —icono y nombre en la misma línea, como cualquier marca convencional—: a la izquierda, un pequeño icono con dos siluetas de género indefinido (sin rasgos que las identifiquen como hombre o mujer), cada una de un color distinto (ámbar y violeta, los mismos tonos que identifican la barra y la pista de baile dentro del propio simulador), con los morros encontrándose y un pequeño corazón en el punto de contacto; a la derecha, el nombre «Start · Engage · Match». El mismo icono, en una versión más pequeña, se repite junto al título dentro de la aplicación para mantener la identidad visual coherente en toda la interfaz. Es una pieza gráfica simple, generada íntegramente en SVG vectorial dentro del propio archivo, sin imágenes externas.

3. Objetivo y motivación

El proyecto nace como ejercicio de modelización de un fenómeno social —el encuentro casual entre personas— usando herramientas propias del análisis espacial y la simulación basada en agentes (agent-based modelling), aplicadas aquí a un dominio lúdico en lugar de a un dominio geográfico convencional. ¿Todo es GIS?. La respuesta es no, ¡pues eso!

Cada persona se comporta como un agente autónomo con reglas de movimiento, atributos propios y una función de decisión (el «engage») que determina si, al cruzarse físicamente con otro agente, se produce algún tipo de conexión. El objetivo explícito no es predecir comportamiento real, sino disponer de una maqueta interactiva y visual sobre la que iterar reglas de compatibilidad, probabilidad y economía, viendo el efecto agregado de cada cambio de forma inmediata.

4. Modelo del espacio físico

El local se representa como un cuadrado de 20 × 20 metros (560 × 560 píxeles en pantalla). Dentro de ese cuadrado se han definido cuatro zonas de interés, cada una con su propia probabilidad de ser elegida como destino por los agentes, y dos puertas físicamente separadas:

Barra: franja a lo largo de la pared superior (18 × 2,4 m). Probabilidad de ser destino: 30 %.
Pista de baile: zona central (10 × 7 m), la de mayor densidad esperada. Probabilidad: 40 %.
Sofás y Mesas altas: dos rincones en las esquinas inferiores (4,5 × 3,5 m cada uno). Probabilidad: 12 % cada uno.
Deambular libre: un punto aleatorio del local, sin zona asociada. Probabilidad: 6 %.

La Entrada está fijada en el centro de la pared inferior; toda persona nueva accede siempre por ese punto. La Salida está fijada en la pared izquierda, en una posición distinta de la entrada. Esta separación física busca un flujo más orgánico: quien entra atraviesa la sala hacia su primer destino, y quien se marcha recorre el local en sentido contrario hacia una puerta distinta, en lugar de desaparecer por el borde más cercano en el momento de irse.

5. Modelo de la población

Cada persona (agente) se genera con los siguientes atributos, fijados en el momento de entrar y constantes durante toda su estancia salvo que se indique lo contrario:

Nombre: asignado aleatoriamente de un listado de nombres españoles, distinto para cada género.
Género: masculino o femenino, con probabilidad 50/50.
Orientación sexual: heterosexual, homosexual o bisexual (ver apartado 7).
Preferencias personales: un vector de 5 gustos booleanos (Viajar, Cocina, Estudiar, Deporte, Música), cada uno asignado de forma independiente con probabilidad 50 %. Estas preferencias son la base de la compatibilidad (apartado 9).
Historial de intentos: el conjunto de personas con las que ya se ha intentado un encuentro (con o sin éxito), para no repetir nunca el mismo emparejamiento.
Paciencia acumulada: contador de tiempo en el local sin lograr un match completo (apartado 10).

6. Modelo de movimiento

En lugar de un paseo aleatorio uniforme por todo el local —que en la práctica apenas generaría cruces entre pocas personas repartidas en 400 m²—, cada agente elige un punto de destino concreto dentro de una de las zonas de interés (ver apartado 4) y camina hacia él en línea recta con velocidad propia (0,5–1,0 m/s equivalentes).

Al llegar a su destino, el agente permanece inmóvil un intervalo aleatorio (entre 0,7 y 2,2 segundos simulados aproximadamente) —simulando que pide en la barra o baila— y a continuación elige un nuevo destino, repitiendo el ciclo. Esta atracción hacia puntos calientes concretos (sobre todo la pista de baile) es lo que produce cruces frecuentes y realistas incluso cuando la población activa es reducida.

7. Modelo de atracción y orientación sexual

Antes de intentar cualquier encuentro, el sistema comprueba si existe atracción mutua real entre las dos personas que se han cruzado físicamente, en función de su género y orientación:

Heterosexual: atracción únicamente hacia el género opuesto.
Homosexual: atracción únicamente hacia su mismo género.
Bisexual: atracción hacia ambos géneros.

La atracción debe ser mutua: si una persona no está interesada en el género de la otra, no se produce ningún intento de encuentro, aunque se hayan cruzado físicamente; simplemente siguen su camino, y ese cruce queda registrado como «sin interés» para no volver a evaluarse entre esas dos mismas personas. Esto significa, por ejemplo, que dos hombres heterosexuales que se crucen nunca iniciarán un encuentro entre sí, mientras que dos mujeres bisexuales sí podrán hacerlo.

El porcentaje de población no heterosexual y el reparto entre bisexualidad y homosexualidad dentro de ese porcentaje son parámetros configurables (apartado 16).

8. El encuentro: «engage» y «challenge» visual

Cuando dos personas con atracción mutua se cruzan físicamente (sus círculos se solapan en el lienzo) y no se han probado antes entre sí, ambas quedan congeladas en el sitio durante aproximadamente 1,8 segundos: es el «challenge». Durante ese tiempo se dibuja una línea de conexión entre ambas y, de forma escalonada, van apareciendo cinco casillas de color —una por cada una de las cinco preferencias—, iluminadas si ambas personas coinciden en esa preferencia (ya sea porque a las dos les gusta o porque a ninguna le gusta) y apagadas si no coinciden.

Transcurrido ese tiempo se resuelve el encuentro (apartado 9) y ambas personas quedan marcadas como ya intentadas entre sí, de modo que nunca vuelven a evaluarse la una a la otra.

Periodo de gracia de entrada: durante los primeros 5 segundos desde que una persona ha entrado por la puerta, no puede iniciar ningún encuentro. Sin esta pausa, dado que todo el mundo entra por el mismo punto, la mayoría de los encuentros se producirían de forma artificial justo en el umbral de la puerta, antes de que la gente tuviera ocasión de dispersarse hacia la barra, la pista o los rincones.

9. Compatibilidad y «chispa»: el modelo de dos niveles

La resolución del encuentro se calcula en dos pasos independientes, lo que da lugar a tres desenlaces posibles:

Paso 1 — Compatibilidad de intereses: se cuenta en cuántas de las 5 preferencias coinciden ambas personas. Si ese número iguala o supera un umbral configurable (por defecto 4 de 5, ajustable por franja horaria; ver apartado 11), se consideran «compatibles».

Paso 2 — La chispa: solo si son compatibles, se lanza una probabilidad —la «chispa»— configurable (50 % por defecto). Solo si esta también se cumple se considera un match completo.

Los tres desenlaces posibles son, por tanto:

Match completo (compatibles + chispa): aparece un destello dorado con un corazón, ambas personas brillan, se muestra su nombre y se genera una entrada en el registro narrativo (apartado 13). Salen juntas del local.
Compatible sin chispa (compatibles, pero sin suerte): destello azul, no hay match; ambas personas siguen su noche con normalidad, contando ese intento como uno de los tres disponibles.
Sin compatibilidad: destello rojo; mismo efecto práctico que el caso anterior.

Esta separación entre «compatibilidad objetiva» y «chispa aleatoria» evita que el modelo sea puramente determinista: dos personas con gustos idénticos no están garantizadas de conectar, igual que en la vida real la afinidad de intereses no siempre se traduce en atracción.

10. Condiciones de abandono del local

Cada persona puede abandonar el bar por cuatro vías distintas, todas ellas evaluadas continuamente:

Tres intentos agotados: si una persona acumula 3 encuentros sin lograr un match completo, ya no puede conseguirlo esa noche. Se le concede un breve intervalo de «terminando la copa» (entre 0,8 y 2,2 segundos) antes de dirigirse a la salida.
Paciencia agotada: si pasa un tiempo prudencial (configurable, 25 segundos reales por defecto) sin lograr ningún match completo, se cansa de esperar y abandona, con el mismo intervalo de cortesía anterior.
Sin candidatos disponibles: si a una persona no le queda nadie activo en el local con quien no haya probado ya (o con quien no exista atracción mutua), abandona de inmediato, sin ningún intervalo de cortesía —no tiene sentido que siga esperando si no hay nadie más con quien intentarlo—. Este es el caso típico de las dos últimas personas del local que ya se probaron entre sí sin éxito.
Cierre del local: a las 05:00 (apartado 11) se detiene la entrada de gente nueva; quienes ya estén dentro siguen su curso normal hasta resolverse, momento en el que la simulación concluye.

11. Modelo temporal: el ciclo de una noche

La simulación reproduce el horario de un bar real, de 17:00 a 05:00 (12 horas), comprimido en un intervalo de tiempo real configurable (5 minutos por defecto). El reloj interno se muestra en pantalla y determina tres franjas horarias con reglas propias:

17:00 – 00:00 («ambiente tranquilo»): se aplican el umbral de compatibilidad y la probabilidad de chispa configurados por el usuario, sin modificación.
00:00 – 04:00 («late», «la cosa se anima»): el umbral de compatibilidad baja automáticamente a un máximo de 3 de 5 (es decir, hace falta coincidir en menos cosas para ser compatible), y la probabilidad de chispa aumenta de forma gradual y lineal desde el valor configurado hasta un 90 %, a medida que se acerca la última hora.
04:00 – 05:00 («última hora»): el umbral se mantiene en 3 de 5 y la chispa se produce siempre (100 %) si hay compatibilidad, reproduciendo la conocida sensación de «cuanto más tarde, menos exigente se es».

Visualmente, el local se tiñe de un violeta muy sutil durante la franja intermedia y de un tono cálido/rojizo durante la última hora, a modo de ambientación de «última copa».

12. Modelo económico

La entrada al local tiene un coste fijo por persona: 5 € hasta medianoche, y el doble — 10 € — desde las 00:00 en adelante. Una vez dentro, la persona no vuelve a pagar y puede permanecer el tiempo que desee, sujeto únicamente a las condiciones de abandono del apartado 10.

El panel de estadísticas (la «cuenta del bar») acumula en tiempo real los ingresos totales realmente cobrados —no una simple multiplicación, sino la suma de lo que pagó cada persona según la hora exacta en la que entró— y calcula un coste medio por match completo (ingresos totales entre número de matches completos), como indicador simplificado de la rentabilidad del local en relación con su función social.

13. Generación narrativa del registro de la noche

Cada vez que se produce un match completo, el sistema compone automáticamente una breve crónica combinando los nombres reales de ambas personas, una frase de apertura elegida al azar de un banco de diez variantes (miradas, silencios, una sonrisa de más), una frase de cierre que menciona los gustos concretos que ambos comparten —o, si no comparten ningún gusto en positivo, que coinciden en lo que no les va—, una mención a la orientación de cada persona cuando no es heterosexual (por ejemplo, «(ambos son gais)» o «Marta es bisexual»), y finalmente un epílogo elegido al azar de un banco de seis variantes con distintos grados de insinuación, siempre sugerente y nunca explícito.

Estas crónicas se muestran en una sección con desplazamiento propio dentro del panel de estadísticas, conservando las últimas 25 entradas.

14. Ambientación sonora

El simulador incorpora una pista de música electrónica generada en tiempo real mediante la Web Audio API del navegador —no se reproduce ningún archivo de audio externo, evitando así cualquier cuestión de derechos—. El motor sintetiza un bombo (kick) con caída de frecuencia, un bajo en patrón repetitivo de cuatro notas y un hi-hat de ruido filtrado, todo ello a 126 pulsaciones por minuto en bucle continuo, con un interruptor para activarla o silenciarla.

15. Panel de métricas

El panel «Cuenta del bar» muestra en todo momento: entradas totales, personas en sala, número de encuentros intentados, cruces sin interés por incompatibilidad de orientación, encuentros compatibles, matches completos, personas que abandonaron sin match, la tasa de match completo por encuentro, el precio de entrada vigente, los ingresos totales acumulados y el coste medio por match completo.

16. Parámetros configurables

Todos los parámetros del modelo son ajustables en tiempo real mediante controles deslizantes, lo que permite explorar el efecto de cada regla sin modificar el código:

Parámetro	Rango / valor por defecto	Efecto
Personas	6 – 60 (24 por defecto)	Tamaño de la población simulada
Umbral match	2 – 5 sobre 5 (4 por defecto)	Coincidencias necesarias para ser «compatibles» (antes de medianoche)
Chispa	10 % – 90 % (50 % por defecto)	Probabilidad de match completo una vez hay compatibilidad
Paciencia	10 – 60 s (25 s por defecto)	Tiempo sin match completo antes de abandonar por cansancio
% no heterosexual	0 – 30 % (12 % por defecto)	Proporción de la población gay, lesbiana o bisexual
De ese %, % bi	0 – 100 % (50 % por defecto)	Reparto entre bisexualidad y homosexualidad exclusiva
Noche dura	3 – 20 min (5 min por defecto)	Minutos reales que representan las 12 horas de apertura
Reponer gente	activado / desactivado	Si se genera gente nueva para sustituir a quien se va
Música	activada / desactivada	Pista electrónica de ambientación

17. Notas de implementación técnica

El simulador es un único archivo HTML autocontenido (HTML, CSS y JavaScript en el mismo documento), sin dependencias externas ni conexión a internet, por lo que funciona igual abierto como archivo local que servido desde un navegador. El motor de animación usa Canvas 2D con un bucle basado en requestAnimationFrame; la física de movimiento, las colisiones y la resolución de encuentros se recalculan en cada fotograma sobre una lista de agentes en memoria, sin frameworks ni librerías externas.

Esta sencillez deliberada facilita que cualquier regla del modelo —umbrales, probabilidades, zonas, horarios— pueda ajustarse directamente en el código o mediante los controles de la interfaz, sin necesidad de recompilar ni de dependencias de terceros.

18. Limitaciones y posibles líneas futuras

El modelo de compatibilidad es simétrico y binario por preferencia (gusta / no gusta); no pondera la intensidad de cada gusto ni introduce afinidades parciales.
La orientación bisexual se modela como atracción indiferenciada a ambos géneros, sin matices adicionales.
El coste de entrada y los ingresos son indicadores simplificados; no se ha modelado gasto en consumiciones ni otros ingresos del local.
Posibles ampliaciones: perfiles de personalidad más ricos (más de 5 preferencias, pesos distintos), grupos de amigos que entran y se mueven juntos, eventos especiales (barra libre, DJ invitado) que alteren temporalmente las reglas, o exportación de los resultados de una noche simulada a un informe descargable.

Ahora, si os gusta, a a contarlo,

Alberto Concejal
GIS Analyst

KALMAN RADAR TRACKER: SEGUIMIENTO DE BLANCOS AÉREOS

Cuando alguien me pregunta sobre radar, pienso sobre todo en radares montados en satélites (sesgo geospacial) pero en realidad hay mucho más, hoy voy a hablaros de de radares aeroportados, de filtros de Kalman y seguimiento de blancos aéreos en movimiento… ¡Qué interesante!

Imagen 1- KALMAN RADAR TRACKER – El vuelo del blanco

Lo primero que pienso no es en el radar en sí, sino en el problema que resuelve, porque ese problema lo llevo resolviendo de otra forma desde hace años sin llamarlo por su nombre técnico. Un radar mide la posición de un avión con ruido. Un GPS mide la posición de un coche con ruido. Un sensor SAR mide el desplazamiento del terreno con ruido. En los tres casos hay una señal real escondida detrás de mediciones que saltan, que tiemblan, que nunca coinciden exactamente con la trayectoria verdadera. Y en los tres casos la respuesta es la misma matemática: combinar lo que predice el modelo físico con lo que dice el sensor, ponderando cada fuente según cuánto te fías de ella.

Eso es un filtro de Kalman, despojado de jerga. Llevo construyendo herramientas geoespaciales que rondan esta misma idea sin que nadie me lo pidiera explícitamente. Cuando trabajo con series temporales de NDVI en Earth Engine y aplico un suavizado para separar la tendencia real del ruido atmosférico de cada imagen Landsat, estoy haciendo una versión simplificada de lo mismo. Cuando proceso cambios en backscatter de Sentinel-1 sobre una mina y tengo que decidir qué variación es señal geológica y qué es ruido del sensor, vuelvo a estar en el mismo terreno conceptual. La estadística no cambia, cambia el dominio de aplicación.

Imagen 2- KALMAN RADAR TRACKER – Seguimiento de blancos aéreos

Lo interesante de pasar unos días metido en simulación de trayectorias radar fue confirmar hasta qué punto esto es transferible. Construí un simulador que genera el vuelo de un avión con maniobras aleatorias, le añade ruido de medición como si fuera un radar real, y luego aplica el filtro para reconstruir la trayectoria verdadera a partir de esas mediciones imperfectas. La mejora respecto a quedarte solo con el dato bruto del sensor ronda el cuarenta o cincuenta por ciento de reducción de error, dependiendo de cuánto ruido metas y cuánto maniobre el blanco. Verlo animado, ping a ping, mientras la línea cian del filtro converge sobre la trayectoria real mientras la línea naranja del radar bruto sigue saltando erráticamente, es de las pocas veces que una ecuación de álgebra matricial se vuelve intuitiva con solo mirarla.

Imagen 3 – KALMAN RADAR TRACKER – Seguimiento de blancos aéreos

Esto me lleva a algo que pienso desde hace tiempo sobre el sector geoespacial y por qué cada vez se parece más a otros sectores que en apariencia no tienen nada que ver. La frontera entre GIS, teledetección, radar de defensa y ciencia de datos se está disolviendo, no porque las aplicaciones converjan, sino porque la base matemática siempre fue la misma y durante años cada comunidad la vistió con su propio vocabulario. Un analista GIS que entiende bien la incertidumbre espacial entiende sin mucho esfuerzo el tracking radar.

Imagen 5 – KALMAN RADAR TRACKER – Exportando a KML todas las trayectorias y datos puntuales

Un ingeniero de radar que entiende el filtrado de señal entiende sin mucho esfuerzo el procesado SAR. La diferencia real no está en la herramienta, está en el dominio de aplicación y en el contexto operativo, que sí importan mucho, pero no son la barrera que parecen desde fuera.

Imagen 6 – KALMAN RADAR TRACKER – Exportando a KML todas las trayectorias y datos puntuales

Esto también explica por qué el geointeligencia y la observación terrestre están viviendo un momento tan interesante ahora mismo. Hay una demanda creciente de perfiles que sepan moverse entre estos mundos, que entiendan tanto la física de la señal como la lógica espacial del problema, y que no se queden bloqueados cuando el vocabulario cambia de “ground truth” a “blanco” o de “pixel” a “celda de resolución radar”. La tecnología emergente en este espacio no va de inventar matemática nueva, va de aplicar matemática ya madura a dominios que históricamente estuvieron separados por silos institucionales más que por silos técnicos.

Voy a seguir publicando sobre esto, porque cuanto más meto las manos en código de tracking y en estadística de procesos espacio-temporales, más confirmo que el geógrafo que sabe programar y el ingeniero que sabe leer un mapa están resolviendo, en el fondo, el mismo tipo de incertidumbre.

Descarga un KML de ejemplo. Renombra el ZIP en KML y ya lo tienes!Descarga

Alberto Concejal
GIS Analyst

Sources:
https://kalmanfilter.net/

Imagen 7 – KALMAN RADAR TRACKER – Output: GIF y KML

VENEZUELA EARTHQUAKE RESPONSE using DuckDB, Overture Maps and R

Just wanted to update on the usage of the tool I developed (OVERTURE MAPS EXTRACTOR) for extraction of Open data from Overture Maps for a quick hands on.

Overture Maps Extractor developed by Alberto Concejal (Open Interface AOI1)

Summary:

Latest release 2026/06/17
3 km buffer over Caracas downtown: 5 minutes
Buildings 52,006 items
Roads 5,482 items
POIS 4,711 items
LULC 398 items
LAND 441 items
Admin Bounds 77 items
Infrastructure 2,442 items

Exported to a 17 MB geopackage GPKG file

Please let me know if this interests anybody, free use of course,

Overture Maps Extractor developed by Alberto Concejal (Open Interface AOI2)

Overture Maps Extractor developed by Alberto Concejal (Global Mapper)

Hugs to all my friends from Venezuela!

Alberto Concejal
Geospatial Analyst

Overture Maps Extractor developed by Alberto Concejal (buildings’ output)

Sources:
https://developmentseed.org/stac-map/?href=https://vantor-opendata.s3.amazonaws.com/events/Venezuela-Earthquake-Jun-2026/B1400011000BDF10.json
https://radiantearth.github.io/stac-browser/#/external/vantor-opendata.s3.amazonaws.com/events/Venezuela-Earthquake-Jun-2026/collection.json?.language=es
https://x.com/vantortech/status/2070496092131569833

Bingham Canyon: El deslizamiento más grande de la historia minera moderna analizado con radar SENTINEL-1

Análisis de cambios con SAR (Radar de Apertura Sintética) usando Sentinel-1 sobre la mina Bingham Canyon en Utah, donde ocurrió uno de los mayores deslizamientos de tierra de la historia minera el 10 de abril de 2013. El análisis no es PRE/POST del evento en sentido estricto. Es una detección de cambios entre dos períodos posteriores al deslizamiento:

*PRE en el script = oct 2014 – jun 2015 (primera referencia disponible)
POST en el script = jul 2015 – mar 2016 (un año después)

Lo que se detecta no es “antes vs después del colapso de 2013”, sino la evolución de la cicatriz entre 2015 y 2016: reconfiguración de taludes, movimiento de material, estabilización o actividad residual de la zona afectada.

Las cicatrices geomorfológicas de un deslizamiento de esa magnitud no desaparecen en meses. La rugosidad anómala, los depósitos de escombros y la geometría alterada del pit siguen siendo detectables por el radar años después. Lo que el análisis captura es la dinámica post-colapso, no el colapso en sí. el radar detecta los cambios superficiales ocurridos entre 2015 y 2016 sobre la zona afectada por el deslizamiento de 2013. Es un matiz importante que señalo de entrada para no generar confusión.

Imagen 1 – Contexto (imagen reciente 2025)

La clave, el backscatter, pero ¿qué es?. El satélite emite un pulso de microondas hacia la Tierra, ese pulso golpea la superficie y se dispersa en todas direcciones. El backscatter es la fracción que regresa exactamente hacia el sensor. Se mide en decibelios (dB), donde valores más negativos = menos energía devuelta.

Qué determina cuando vuelve?. Tres factores principales: 1 Humedad/dieléctrico: suelo húmedo o vegetación densa absorben y devuelven más energía 2 Rugosidad superficial: una roca fragmentada devuelve muchísimo más que una superficie lisa 3 Geometría: esquinas y estructuras verticales crean “corner reflectors” que disparan el backscatter

Imagen 2 – Los datos crudos: así “ve” el radar

Antes del colapso*: la mina tiene taludes estables, geometría conocida, señal SAR consistente.

Después: millones de toneladas de roca fragmentada y removida cambian radicalmente la rugosidad y geometría de la superficie. El radar lo ve como un cambio brusco de backscatter, aunque haya nubes, aunque sea de noche.

Ahí está la clave: el radar no necesita luz solar ni cielo despejado. Ve a través de todo.

Valor Cercano a 0 dB Casi toda la energía vuelve (metal, agua agitada, roca desnuda)

Valor −10 a −15 dBVegetación, suelo moderado

Valor < −20 dBAgua calma, superficies muy lisas (casi nada vuelve)

En este análisis, un Δ de +3 dB o más indica que esa zona devuelve el doble de energía que antes, señal inequívoca de que algo cambió físicamente en la superficie.

Como S1 no se lanzó hasta 2014, el script usa las primeras imágenes disponibles como referencia base en lugar de tener un “antes” real del evento. El flujo tiene tres grandes bloques:

Preparación de datos

Filtra la colección COPERNICUS/S1_GRD en modo Interferometric Wide (IW), manteniendo solo imágenes con ambas polarizaciones VV y VH. Define dos ventanas temporales: PRE (oct 2014 – jun 2015) y POST (jul 2015 – mar 2016). De cada ventana extrae una mediana, que por sí sola ya reduce bastante el speckle. Encima aplica un filtro boxcar 3×3 adicional por banda.

Imagen 4 – La mina en 3D usando datos LIDAR del USGS de 2019

Detección de cambios

Calcula la diferencia POST − PRE en decibelios para VV, VH y su media. Un Δ positivo indica aumento de backscatter (material acumulado, mayor rugosidad superficial), un Δ negativo indica pérdida o remoción. Aplica un umbral de ±3 dB para distinguir cambio significativo del ruido de fondo.

Salidas y análisis

Visualiza cuatro capas SAR (PRE/POST × VV/VH), los tres mapas de diferencia y un RGB multitemporal donde el canal R lleva POST-VV, G lleva PRE-VV y B lleva la diferencia, produciendo tonos magenta donde hay ganancia y verdes donde hay pérdida. Calcula el área afectada en hectáreas con pixelArea y genera una serie temporal de backscatter medio en el AOI entre 2014 y 2016. Finalmente exporta a Drive los rásteres de diferencia VV, VH y la máscara de cambio binarizada.

Imagen 5 – RGB Multitemporal (R=POST, G=PRE, B=Diff

Imagen 6 – El cambio, clasificado ¡a que mola!

Diagrama 1 – Sumarios de ganancias y pérdidas

Un detalle metodológico relevante: el script no fuerza una órbita concreta (ascending o descending) porque la mediana temporal compensa la mezcla de geometrías de adquisición, aunque para un análisis más riguroso lo ideal sería separar órbitas.

Conclusión

El deslizamiento de Bingham Canyon ocurrió en abril de 2013. Sentinel-1 no existía todavía. Y aun así, el radar fue capaz de leer las cicatrices que dejó en el terreno más de un año después.

Eso dice algo importante sobre la naturaleza del SAR: no necesita estar en el momento exacto para detectar que algo cambió. La geometría del terreno, la rugosidad de la roca fragmentada, la reconfiguración de los taludes… todo queda impreso en el backscatter durante meses, incluso años.

Lo que este script demuestra no es solo que GEE puede procesar imágenes SAR en la nube sin descargar un solo píxel. Demuestra que con datos abiertos, código reproducible y una ventana temporal bien elegida, es posible reconstruir la huella espacial de un evento catastrófico desde cero.

El siguiente paso natural es la tercera dimensión. El radar nos dice dónde cambió la superficie. El LiDAR USGS 3DEP (Imagen 4) nos dice cuánto volumen se desplazó. La combinación de ambas fuentes: SAR multitemporal + MDT de alta resolución, es exactamente el tipo de análisis que los equipos de gestión de riesgos geológicos necesitan, y que hoy es accesible sin infraestructura dedicada, solo conociendo las fuentes.

Imagen 7 – Usando LIDAR de alta resolución para medir ganancias y pérdidas de la zona de análisis

Espero que te haya gustado!

Alberto Concejal
GIS Analyst
https://storymaps.arcgis.com/stories/a5398ca1f6ea4b05b90272e38281c903
https://apps.nationalmap.gov/lidar-explorer

SolarScope: cuando el catastro, el LiDAR y el sol se sientan a la misma mesa

Llevo unos días dándole vueltas a una idea que, en el fondo, es bastante sencilla: si tenemos la huella de cada edificio, su altura y un modelo digital de superficies de alta resolución, ¿por qué seguimos viendo estudios de potencial solar que tratan los tejados como manchas homogéneas sobre un mapa? De esa pregunta, y de unas cuantas sesiones intensas de R, ha salido SolarScope, una aplicación Shiny que estoy desarrollando para hacer scoring de potencial fotovoltaico tejado a tejado, con datos abiertos y un flujo que se puede reproducir tanto en España como en cualquier sitio del mundo donde pueda conectarme a un DSM de alta resolución!

Imagen 1 – Solar Scope, midiendo el potencial fotovoltaico de TODOS los edificios de España

La motivación es doble. Por un lado, profesional: vengo de quince años moviéndome entre geografía, teledetección y GIS aplicado, y cada vez que he tocado proyectos de energía solar he visto el mismo cuello de botella. Los modelos de potencial suelen apoyarse en rásteres de baja resolución (SRTM, Copernicus DEM a 30 m) que son perfectamente válidos para planificación territorial a gran escala, pero que se quedan cortos en cuanto entras en el detalle de una nave industrial o un polígono residencial: ahí lo que importa es la sombra que proyecta el edificio de al lado, la orientación real de la cubierta y cuántos metros cuadrados aprovechables tiene cada tejado después de descontar lucernarios, antenas y pasillos técnicos. Por otro lado, hay una motivación más simple: tenía ganas de construir algo vistoso, con mapas 3D, que sirviera como pieza de presentación ante empresas del sector —y de paso, demostrar que con herramientas open source se puede llegar muy lejos sin depender de licencias de software propietario.

Cómo funciona SolarScope (vídeo YouTube)

De dónde vienen los datos

El corazón de SolarScope es la combinación de tres fuentes. La primera es Overture Maps, el proyecto colaborativo (Meta, Microsoft, Amazon, TomTom y otros) que publica footprints de edificios a escala global con atributos de altura y número de plantas, distribuidos como Parquet sobre S3. Aquí es donde DuckDB se convierte en la pieza más elegante del stack: con la extensión httpfs y spatial, puedo lanzar una consulta SQL directamente contra los ficheros remotos, filtrar por bounding box usando los campos bbox.xmin/xmax/ymin/ymax y traerme solo los edificios que caen dentro del área de interés, sin descargar nada de más. Cuando la altura no está disponible —que pasa más a menudo de lo que gustaría— caigo en una estimación a partir del número de plantas, y si tampoco hay eso, asumo una nave de una planta. No es perfecto, pero es razonable para naves industriales, que es justo el tipo de cubierta que más interesa a un desarrollador solar.

https://albertogis.shinyapps.io/SolarScope

Imagen 2 – Solar Scope, midiendo el potencial fotovoltaico de TODOS los edificios de España

La segunda fuente es el Modelo Digital de Superficies (MDS) del vuelo LiDAR del PNOA, servido por el CNIG a través de un servicio WCS. Aquí sí que tuve que arremangarme: el endpoint correcto no es el de siempre (el del MDT del IGN), sino wcs-mds.idee.es/mds, y el identificador de cobertura tampoco sigue la convención que uno esperaría —nada de Elevacion25830_5, sino simplemente mds05—. Una vez resuelto eso (y la consabida reproyección de EPSG:4326 a EPSG:25830, porque el servicio trabaja en metros UTM, no en grados), el DSM permite calcular, para cada edificio, si hay construcciones vecinas más altas que le proyecten sombra, y con eso derivar un factor de sombreado real en lugar de uno inventado. Para Estados Unidos, el equivalente es USGS 3DEP, que ofrece DSM de hasta 1 metro de resolución allá donde hay cobertura LiDAR —el conector está escrito y solo pendiente de pruebas con datos reales, pero la arquitectura ya contempla ambos países sin tocar el resto de la aplicación.

La tercera pieza es, simplemente, la geometría de cada footprint: a partir de la relación de aspecto del bounding box estimo un factor de orientación, asumiendo que la mayoría de cubiertas industriales son planas (donde la orientación pesa poco) pero penalizando ligeramente las naves muy alargadas en sentido norte-sur frente a las que se extienden este-oeste, que en el hemisferio norte “miran” más al sur.

El cálculo: del tejado al kWp

Con esos tres ingredientes —área, altura, orientación y sombreado—, el motor de scoring aplica un modelo bastante directo inspirado en los valores de referencia de PVGIS: irradiación global horizontal anual (en torno a 1.650 kWh/m²/año para Madrid), un porcentaje de área útil tras descontar elementos técnicos, una eficiencia de sistema fotovoltaico del 20% y una densidad de potencia instalable de 0,18 kWp por metro cuadrado útil. El resultado es, para cada edificio, una potencia instalable en kWp, una producción anual estimada en MWh y un Solar POI Score normalizado de 0 a 100 que combina producción total con superficie disponible —porque un tejado grande y mediocre puede ser más interesante para un desarrollador que uno pequeño y perfecto—. Los tejados se clasifican en tres niveles (bajo, medio, alto), lo que permite, de un vistazo, identificar qué activos merecen una visita técnica.

Imagen 3 – Solar Scope. Interfaz apaisada, búsqueda de usabilidad al máximo

La aplicación: de la idea al mapa interactivo

Todo esto vive dentro de una app Shiny con un diseño oscuro deliberadamente “de producto”, construido sobre bslib con tipografías Inter y Space Grotesk, y una paleta que va del morado profundo al amarillo solar —la misma que reaparece en cada gráfico, en la leyenda del mapa y, por qué no, en la portada de la propia aplicación, donde un skyline de edificios generado en SVG (con sus correspondientes “sombreros” de colores en cada tejado) hace de fondo desenfocado tras el logo.

Imagen 4 – Solar Scope. Vista en 3D. Dentro de poco meteré los nuevos Landmarks de MAPBOX!!!!!

La interacción es deliberadamente simple: el usuario hace clic en el mapa para fijar un punto central, ajusta con un slider el radio de análisis —entre 100 y 1.000 metros— y pulsa “Analizar zona”. En ese momento, la app reconstruye el bounding box, relanza las consultas a Overture y al MDS del CNIG, recalcula todas las métricas y redibuja tanto el mapa 2D (con CartoDB Dark Matter como base) como una vista 3D con extrusión de edificios por altura y coloreada por score, esta última construida con mapdeck, que en el fondo es un envoltorio de deck.gl sobre Mapbox GL. Si el conector de datos reales falla por cualquier motivo —sin conexión, cambio de release de Overture, servicio del CNIG caído—, la app cae automáticamente a un generador de datos sintéticos con la misma estructura, y lo indica con un discreto badge de color para que nunca te quedes con una pantalla en blanco en mitad de una demo. Para quien necesite explotar los resultados fuera de la app, hay un botón de exportación a GeoPackage con todos los atributos calculados, y otro que genera un informe ejecutivo en HTML autocontenido —mapa, KPIs y ranking incluidos— listo para enviar por correo.

Como guiño visual adicional, y porque a veces lo más vistoso no tiene por qué ser lo más complejo, incorporé también una capa opcional de imagen de alta resolución (Esri World Imagery) con control de opacidad sobre el mapa base oscuro: sirve únicamente para contextualizar visualmente la zona —el cálculo de sombreado sigue apoyándose en el DSM del CNIG—, pero al venir servida como teselas por CDN carga muchísimo más rápido que el WMS del PNOA, que para un uso puramente visual resultaba innecesariamente pesado.

Imagen 5 – Solar Scope. Acceso pormenorizado a todos los edificios del AOI

El stack, en una frase

Si tuviera que resumir la pila tecnológica en un párrafo: R y Shiny como columna vertebral, bslib y CSS personalizado para la interfaz, sf y terra para todo lo geoespacial vectorial y ráster, DuckDB con httpfs/spatial como motor de consulta sobre datos en la nube sin descargas intermedias, leaflet para el mapa 2D y mapdeck para la vista 3D, DT para las tablas interactivas y rmarkdown para los informes ejecutivos. Todo open source, todo reproducible, y todo pensado para que el mismo esqueleto sirva tanto para un polígono industrial en Vicálvaro como, cambiando el conector de DSM, para un parque empresarial en Arizona.

Para quién es esto

El público natural son desarrolladores y operadores de energía solar que necesitan priorizar carteras de tejados —ya sea para autoconsumo industrial, comunidades energéticas o grandes cubiertas logísticas— sin tener que encargar un estudio LiDAR específico cada vez que aparece una oportunidad. También tiene sentido para consultoras de sostenibilidad que necesiten estimar potencial fotovoltaico como parte de informes ESG, para administraciones locales que quieran mapear el potencial solar de sus polígonos industriales, o simplemente para cualquier estudio de GIS que quiera mostrar que el análisis espacial de alta resolución no tiene por qué vivir solo dentro de un escritorio ArcGIS. Y sí, en estos días concretos la estoy preparando como pieza de demostración para una conversación con una empresa del sector solar —si sale adelante, ya contaré más por aquí.

Imagen 6 – Solar Scope, midiendo el potencial fotovoltaico de TODOS los edificios de España

Como suele pasar en este oficio, la parte más “glamurosa” —el mapa 3D girando con la cámara, los colores del score, la portada con el skyline desenfocado— es la que menos tiempo me ha llevado. Lo que de verdad ha consumido las horas ha sido, cómo no, encontrar el COVERAGEID correcto de un servicio WCS y pelearme con la codificación de caracteres en una consola de R en Windows: si alguna vez os preguntáis por qué los geógrafos envejecemos mal, no es por el sol de las salidas de campo, es por los acentos UTF-8 dentro de backticks de R. Reproject responsibly.

Imagen 7 – Solar Scope. Exportando geometrías a otro software, en este caso Global Mapper

Iré documentando en este blog los siguientes pasos: cerrar el conector de Estados Unidos con USGS 3DEP, refinar la orientación de cubierta con geometría de fachadas reales, y —si el tiempo lo permite— un modelo de sombreado hora a hora basado en la posición solar real a lo largo del año.

Si todo va bien, la próxima entrada debería poder escribirse en mucho menos tiempo que esta: la idea es que cada iteración de SolarScope deje el terreno un poco más allanado para la siguiente.

Espero que os haya interesado!

Alberto Concejal
Geospatial Analyst

Time Series Analyzer: Análisis multitemporal de índices espectrales en Google Earth Engine

He desarrollado una aplicación interactiva en Google Earth Engine para la extracción y análisis estadístico automático de series temporales de cinco índices espectrales (NDVI, EVI, SAVI, NDWI y NBR) sobre cualquier geometría definida por el usuario en cualquier sitio del mundo. El objetivo es pasar de una imagen satélite puntual a una comprensión temporal del territorio: qué ha pasado, qué patrón subyace, y qué cabe esperar.

Imagen 1 – Time Series analyzer, the interface

La app está escrita íntegramente en JavaScript usando la GEE UI API, sin dependencias externas. El procesamiento corre en la nube de GEE sobre las colecciones oficiales de Landsat (L5/L7/L8/L9, Collection 2 SR, desde 1984) y Sentinel-2 SR Harmonized (desde 2017). El cálculo de la ACF se realiza en el cliente una vez extraída la serie como FeatureCollection. La interfaz se organiza en tres paneles: controles a la izquierda (selección del índice, plataforma, fechas, nubosidad límite), mapa y serie temporal en el centro, y análisis estadístico a la derecha con sistema de pestañas para separar gráfico, resultado e interpretación. Aquí abajo puedes acceder a la aplicación:

https://analysis202601.projects.earthengine.app/view/timeseriesanalyzer

Imagen 2 – the original index data over the selected dates

Metodología

El flujo parte del filtrado de imágenes por fecha, geometría y porcentaje de nubosidad máximo, con enmascarado de nubes por QA_PIXEL (Landsat) o QA60 (Sentinel-2). Sobre esa colección se calculan los índices espectrales aplicando los factores de escala de Collection 2 sobre reflectancia de superficie. Los cinco índices disponibles son NDVI, EVI, SAVI, NDWI y NBR, cada uno orientado a una pregunta diferente sobre la cobertura: estado general de la vegetación, respuesta en zonas densas, corrección del efecto suelo, contenido hídrico o severidad de incendios.

La serie temporal resultante se analiza estadísticamente mediante cuatro módulos. El más relevante metodológicamente es la función de autocorrelación (ACF), que mide la correlación de la serie consigo misma en distintos desfases temporales. Un pico significativo en lag 1 indica que la vegetación tiene inercia: lo que ocurre hoy predice lo que ocurrirá en la siguiente adquisición. Un pico en lag 6 o lag 23 —dependiendo de la cadencia del satélite— revela un ciclo semestral o anual. El umbral de significancia se calcula según el criterio de Bartlett al 95% (±1.96/√n), lo que permite distinguir entre estructura real y ruido estadístico.

Imagen 3 – Función de Autocorrelación y sus intervalos de confianza

La interpretación de la ACF se estructura automáticamente en cuatro bloques: memoria a corto plazo, ciclo estacional con estimación del período en meses, longitud de memoria total y recomendación de modelo. Si la autocorrelación permanece significativa hasta lags altos, la serie tiene memoria larga y probablemente una tendencia no estacionaria que requiere diferenciación antes de modelar. Si hay un pico estacional claro, la estructura es compatible con un modelo SARIMA(p,d,q)(P,D,Q)[s] donde s es el período detectado. La app complementa esto con un análisis de tendencia lineal que aporta la pendiente y el R², y una curva suavizada que permite comparar la amplitud del ciclo estacional entre años.

Comprensión de patrones y proyección

Lo que hace útil el análisis temporal no es la fotografía de un año sino la estructura que emerge a lo largo de varios ciclos. La ACF permite responder preguntas concretas: ¿es el ciclo estacional de este pastizal estable año a año o su amplitud está decreciendo? ¿La caída de NDVI en 2022 fue un evento puntual o marcó un cambio de régimen? ¿Cuántos meses tarda la vegetación en recuperar sus valores tras un incendio?

Identificada la estructura temporal, el paso natural será el modelado predictivo (para un próximo post si me lo pedís:-)). Una serie con estacionalidad anual clara y memoria moderada es directamente modelable con SARIMA, cuyo ajuste óptimo puede automatizarse con auto.arima() en R o SARIMAX en Python sobre el CSV exportado por la app. El modelo resultante permite proyectar valores futuros del índice, construir intervalos de confianza estacionales y detectar anomalías como desviaciones significativas respecto al patrón esperado, lo que equivale a una señal de alerta temprana ante degradación, sequía o cambio de uso del suelo.

Aplicaciones

La combinación de Landsat desde 1984 con series temporales largas abre un abanico amplio de usos. En el contexto de pastizales y agricultura, permite cuantificar la respuesta de la cobertura vegetal a años secos o húmedos y comparar la dinámica entre parcelas con distinto manejo. En el ámbito forestal, la caracterización fenológica mediante el ciclo anual del NDVI o EVI permite detectar adelantos o retrasos en la brotación asociados a cambios climáticos. Con NBR, el seguimiento post-incendio revela tanto la severidad inicial como la trayectoria de recuperación. En zonas de expansión urbana, la tendencia negativa sostenida en NDVI a lo largo de décadas es un indicador directo de sellado del suelo y pérdida de cobertura vegetal.

En investigación, la exportación CSV permite integrar los resultados en flujos de trabajo más complejos: correlación con datos meteorológicos, validación con trabajo de campo o calibración de modelos de simulación de ecosistemas. En docencia, la app funciona como entorno de demostración interactivo para explicar autocorrelación, estacionalidad y modelado de series temporales sobre datos reales sin necesidad de instalar nada.

Aquí va el resultado del análisis de autocorrelation en una zona muy cercana a Zaragoza, España, usando Landsat, un periodo que comprendía los tres últimos años.

Imagen 6 – Análisis extra cerca de Ejea de los Caballeros en Zaragoza, España

Imagen 7 – Función de Autocorrelación y sus intervalos de confianza

WHAT THIS ANALYSIS DOES

The ACF measures how similar the series is to a time-shifted version of itself. Each bar is a lag: lag 1 = correlation between observation i and the next; lag 2 = two steps back, etc. Dashed lines mark the 95% significance threshold (±1.96/√n). Bars exceeding that threshold indicate a real pattern, not noise.

AUTOMATIC RESULT

1. SHORT-TERM MEMORY (lag 1 = 0.89) ► Significant (very strong). Consecutive values are correlated. A high index today predicts a high index in the next image.

2. SEASONAL CYCLE (strongest lag = 2, r = 0.75) ► Significant peak → clear periodicity detected. Landsat 8-9 cadence: cycle = 8-16 days. Sentinel cadence: cycle = 3-5 days. This is consistent with a short intra-seasonal fluctuation.

3. MEMORY LENGTH (last significant lag = 24) ► Long memory — ACF remains significant up to lag 24. This suggests a non-stationary trend in the data. Recommendation: apply first-order differencing before fitting ARIMA/SARIMA.

4. MODEL SUGGESTION ► Non-stationary series. Difference first, then fit ARIMA(p,1,q).

READING GUIDE

Reading guide: → High lag 1 (>0.5): vegetation has strong “memory”, changes slowly. → Peak at lag 6 or 12 (~16-day data): semi-annual or annual cycle — typical grassland seasonality. → ACF that decays slowly into a “tail”: possible non-stationary trend in the series. → ACF oscillating between positive and negative: clear cyclic pattern, ideal for SARIMA modeling. → All bars within the lines: series with no temporal structure — possibly noise or heterogeneous geometry.

Espero que os haya resultado interesante,

Alberto Concejal
https://geovisualization.net/