SAM en ArcGIS Pro: probando la segmentación semi-automática sobre ortofotos PNOA en formato COG

Desde hace unas semanas he estado probando el modelo Segment Anything Model (SAM) de Meta AI integrado como modelo preentrenado dentro de ArcGIS Pro, aplicándolo sobre ortofotos del Plan Nacional de Ortofotografía Aérea (PNOA) descargadas del Centro de Descargas del CNIG en formato COG. Este artículo recoge el proceso completo: qué es SAM, qué licencias y extensiones necesitas, cómo se instalan las librerías, de dónde salen los datos de origen, qué formatos intervienen y los problemas reales que me he ido encontrando por el camino, con sus soluciones.

Qué es SAM y por qué interesa en un flujo GIS

SAM es un modelo fundacional de segmentación de imágen desarrollado por Meta AI, entrenado sobre más de mil millones de máscaras y once millones de imágenes del dataset SA-1B. A diferencia de los modelos de detección de objetos tradicionales, que necesitan entrenarse desde cero con un dataset etiquetado para cada tipo de objeto, SAM funciona con aprendizaje zero-shot: es capaz de delinear los contornos de prácticamente cualquier elemento presente en una imagen sin haber visto ese tipo de objeto antes durante el entrenamiento. ESRI lo integró como modelo preentrenado dentro de ArcGIS Living Atlas, lo que permite ejecutarlo directamente desde la herramienta Detect Objects Using Deep Learning en ArcGIS Pro, sin necesidad de entrenar nada previamente.

Imagen 1 – Detect Objects Using Deep Learning en ArcGIS Pro (Parameters)

La contrapartida de esa generalidad es que SAM segmenta absolutamente todo lo que reconoce como objeto diferenciado dentro de la imagen: edificios, coches, sombras, vegetación, piscinas, cualquier polígono con un contorno reconocible, sin asignarle una clase semántica. Es decir, obtienes máscaras, no una clasificación temática. Para quien venga de flujos de clasificación supervisada esto es un cambio de paradigma: primero segmentas todo, y después filtras o clasificas en post-proceso. Esri ha desarrollado además una variante, Text SAM, que combina SAM con Grounding DINO para poder indicar mediante texto qué tipo de objeto interesa extraer, lo cual resulta muy útil cuando quieres, por ejemplo, solo edificaciones y no absolutamente todo lo detectable en la escena.

Imagen 2 – Detect Objects Using Deep Learning en ArcGIS Pro (Environment)

Requisitos de licencia y extensión necesarios

Para ejecutar SAM en ArcGIS Pro hace falta la extensión Image Analyst activa en la licencia. Esto se comprueba entrando en Project, dentro del backstage, y accediendo al apartado Licensing, donde debe aparecer Image Analyst marcada como disponible. Conviene tener en cuenta que la pestaña contextual de imagen en el ribbon solo se muestra cuando hay una capa ráster seleccionada en el panel de contenidos, así que si no ves las herramientas de Image Analyst en el ribbon no significa necesariamente que falte la licencia: puede ser simplemente que no tengas ninguna capa de imagen activa. La vía más fiable para comprobar la disponibilidad real es buscar directamente la herramienta Detect Objects Using Deep Learning dentro de Image Analyst Tools, en el panel Catalog.

Además de la extensión, hace falta instalar las Deep Learning Libraries de Esri, un paquete adicional que añade PyTorch, torchvision y las dependencias específicas de los modelos de deep learning de Esri sobre el entorno Python clonado de ArcGIS Pro. Este instalador debe coincidir exactamente con la versión de ArcGIS Pro que tengas instalada, y hay que ejecutarlo con ArcGIS Pro cerrado.

Descarga e instalación del modelo SAM

El modelo llega empaquetado como archivo .dlpk, un Deep Learning Package que incluye los pesos del modelo y el script Python que ArcGIS Pro ejecuta internamente. Se descarga desde ArcGIS Living Atlas of the World buscando el ítem correspondiente a Segment Anything Model, y se puede descargar tanto desde dentro de Pro, a través del panel Catalog conectado al portal, como desde el navegador. Si lo descargas desde dentro de ArcGIS Pro suele quedar en la carpeta local de paquetes de deep learning del usuario; si lo bajas desde el navegador aterriza en la carpeta de descargas habitual de Windows, y desde ahí conviene moverlo a una ubicación estable del proyecto, por ejemplo dentro de la carpeta Packages del proyecto de ArcGIS.

Una vez localizado el .dlpk, se referencia directamente como parámetro Model Definition dentro de la herramienta Detect Objects Using Deep Learning, sin necesidad de ningún paso de instalación adicional más allá de tener las Deep Learning Libraries correctamente instaladas.

El origen de los datos: PNOA y el cambio a formato COG

El Plan Nacional de Ortofotografía Aérea arrancó en 2004 con el objetivo de obtener cobertura fotográfica aérea digital de todo el territorio español, con un ciclo de actualización que actualmente es de tres años por comunidad autónoma. Durante años las ortofotos PNOA se distribuyeron en formato ECW, un formato de compresión propietario de Hexagon/Leica Geosystems. En 2023 el IGN dio el paso de sustituir ese formato propietario por Cloud Optimized GeoTIFF, un GeoTIFF estándar pero con teselado interno, pirámides incorporadas y estructura pensada para el acceso remoto parcial vía HTTP Range Requests, de modo que en teoría un cliente puede pedir solo la porción de píxeles que necesita sin descargar el archivo completo. En la práctica, el Centro de Descargas del CNIG sirve estos ficheros mediante peticiones POST en lugar de GET, lo que limita esa ventaja de acceso parcial cuando se consume directamente desde la web de descargas, aunque el archivo en sí conserva toda la estructura interna de un COG válido y funciona perfectamente como cualquier GeoTIFF una vez descargado.

Imagen 3 – Descargando COG desde el CNIG

Junto con el cambio de formato, el IGN también cambió el corte de las hojas de distribución de la ortofoto de máxima actualidad, pasando de hojas MTN50 a hojas MTN25, con el objetivo de reducir el tamaño de cada fichero individual y agilizar la descarga.

Conviene distinguir varios productos dentro del catálogo PNOA porque cada uno tiene su propia disponibilidad temporal y su propio corte de hoja. Las ortofotos históricas PNOA cubren mosaicos anuales desde 2004 hasta la actualidad y se distribuyen según hoja oficial 1:25.000 en COG. Las ortofotos provisionales, que a su vez se dividen en expeditas y rápidas, son productos no definitivos generados a partir de la orientación directa del vuelo mediante GNSS/IMU, disponibles temporalmente hasta que se publica la versión definitiva, y se distribuyen en hoja 1:5.000. La tesela que he usado en mis pruebas, correspondiente al huso 30 y con el prefijo MA de máxima actualidad, entra dentro de esta lógica de actualización continua por lotes autonómicos.

Además de las ortofotos ópticas, el PNOA incluye la componente LiDAR, con modelos digitales de superficie y terreno derivados de las nubes de puntos, también distribuidos en COG, con pasos de malla de cinco metros en el caso del MDS05 y de 2,5 metros en los modelos normalizados de edificación y vegetación de coberturas más recientes.

Formatos necesarios para trabajar con SAM en ArcGIS Pro

SAM está diseñado para trabajar con imagen de tres bandas en color natural RGB y profundidad de 8 bits. Antes de lanzar la herramienta conviene comprobar en las propiedades de la fuente del ráster que el Pixel Type sea efectivamente entero sin signo de 8 bits y que el número de bandas sea tres. Las ortofotos PNOA en COG normalmente ya cumplen este requisito de fábrica, pero si trabajas con productos de mayor número de bandas, como composiciones con infrarrojo cercano, o con productos LiDAR de 16 bits, necesitarás recomponer un ráster de tres bandas de 8 bits mediante herramientas como Composite Bands o Copy Raster antes de poder ejecutar el modelo.

El formato COG en sí no requiere ninguna conversión previa para usarse en ArcGIS Pro: se añade al mapa como cualquier ráster GeoTIFF y Pro lo interpreta de forma nativa aprovechando su estructura teselada internamente, aunque al trabajarlo en local esa ventaja de acceso remoto parcial deja de tener relevancia práctica, ya que el archivo completo reside ya en disco.

Licencia de uso de los datos del IGN y del CNIG

Toda la cartografía y ortofotografía distribuida a través del Centro de Descargas del CNIG, incluyendo las series PNOA, se rige por la Orden FOM/2807/2015, que establece una licencia de uso compatible con Creative Commons Reconocimiento 4.0. Esto permite el uso libre y gratuito de los datos para cualquier propósito legítimo, incluido el uso comercial, con la única obligación estricta de reconocer el origen y la propiedad del IGN y del CNIG en cualquier producto derivado. Cuando se genera una obra derivada, como sería el caso de las máscaras de segmentación producidas por SAM a partir de una ortofoto PNOA, la fórmula de atribución recomendada añade la mención “obra derivada de” antes de la referencia al producto original y su fecha, de modo que en un post o publicación técnica la cita adecuada sería algo del tipo “obra derivada de PNOA, IGN/CNIG, CC BY 4.0“, ajustando el año del vuelo correspondiente.

Problemas reales encontrados durante las pruebas y cómo se resolvieron

Aunque sobre el papel el flujo es sencillo, en la práctica me he encontrado con tres obstáculos consecutivos que merece la pena documentar porque no son evidentes desde la documentación oficial de Esri.

El primero (1) apareció nada más lanzar la herramienta con los parámetros por defecto: un error de conversión de tipo dentro del propio script del .dlpk, que fallaba al intentar convertir a número decimal el valor del umbral de estabilidad de máscara. La causa resultó ser la configuración regional de Windows en español, donde el separador decimal por defecto es la coma. El script interno de SAM espera notación con punto decimal, así que aunque el campo de la interfaz mostrara correctamente “0,95”, al serializarse internamente como argumento de Python fallaba la conversión a float. La solución de fondo no está en el propio formulario de la herramienta, sino en cambiar el símbolo decimal del sistema operativo de coma a punto desde la configuración regional de Windows, y reiniciar ArcGIS Pro por completo para que el cambio se propague.

El segundo problema (2), ya con el separador decimal corregido, fue un error genérico de tipo “unspecified error” al generar la tabla de salida, con referencia a un ráster ausente. Este patrón de error suele apuntar a un fallo en la inicialización del motor de PyTorch, típicamente por ausencia de driver NVIDIA compatible cuando el tipo de procesador se deja sin especificar. Fijar explícitamente el Processor Type a CPU, en el apartado Environments de la herramienta, resolvió ese fallo al forzar una ruta de ejecución que no depende de encontrar una GPU CUDA disponible.

El tercer problema (3) surgió ya con la ejecución corriendo establemente sobre CPU: un timeout del procesamiento paralelo. ArcGIS Pro reparte por defecto el ráster de entrada en varias instancias paralelas para acelerar el procesamiento, pero al ser SAM un modelo computacionalmente muy exigente, correr varias instancias simultáneas sobre CPU compite por los mismos recursos y ninguna llega a completarse dentro del tiempo límite asignado. Poner el factor de procesamiento paralelo a cero para forzar ejecución secuencial, o alternativamente aumentar el valor de timeout desde las opciones de geoprocesamiento del proyecto, resuelve el bloqueo, a costa de un tiempo de ejecución total mayor.

Recomendaciones para una primera prueba

Antes de lanzar el modelo sobre una tesela PNOA completa, que en corte 1:25.000 con resolución de 25 centímetros supone un volumen de píxeles considerable, conviene acotar el extent de procesamiento a un área muy pequeña, del orden de una manzana urbana, para validar que toda la cadena funciona correctamente: licencia activa, librerías instaladas, configuración regional correcta y tipo de procesador explícito. Una vez confirmado el funcionamiento en un área reducida, escalar progresivamente el extent permite calibrar tiempos de ejecución reales antes de comprometerse a procesar la tesela entera o un mosaico de varias teselas contiguas.

Imagen 5 – Primer test éxito (algunos fallos ya que no cambié parámetros por defecto)

Conclusión: hacia dónde lleva esto

Más allá de la prueba de concepto sobre una tesela urbana, el interés real de SAM en un flujo GIS aparece cuando se combina la segmentación óptica con otras capas ya disponibles en el propio catálogo del CNIG, en particular con el componente LiDAR del PNOA. Las máscaras que produce SAM a partir de la ortofoto son polígonos sin altura ni clase semántica; cruzarlas con el modelo digital de superficie o con la nube de puntos clasificada de la misma zona permite dar profundidad real a esa segmentación: asignar una altura a cada máscara detectada, diferenciar edificación de vegetación por su perfil vertical en lugar de solo por su forma en planta, o generar de forma semiautomática capas de volumetría 3D a partir de contornos que SAM ha extraído en segundos sobre un área que manualmente llevaría horas de digitalización.

Esto es especialmente interesante ahora mismo porque la tercera cobertura del proyecto PNOA-LiDAR, capturada con una densidad homogénea de cinco puntos por metro cuadrado en todo el territorio, muy superior a los 0,5 puntos por metro cuadrado con los que arrancó la primera cobertura en 2009, acaba de completar su publicación para Castilla y León, una de las últimas comunidades en incorporarse a este ciclo. Y ahí es donde el cruce entre segmentación SAM y LiDAR de tercera cobertura se vuelve realmente vistoso: en las zonas de alta montaña de la Cordillera Cantábrica y del Sistema Central leonés, por ejemplo, donde la densidad de puntos y la resolución de la ortofoto asociada capturan un nivel de detalle del terreno que hace unos años solo se conseguía con vuelos específicos de proyectos puntuales, no con una cobertura nacional sistemática.

Imagen 6 – Detalle de 3ª cobertura PNOA en Castilla y León (Ávila)

DESCRIPTION=PNOA_2014_CYL-SW_314-4460_ORT-CLA-COL.laz
LIDAR POINT COUNT=6,953,827
LIDAR POINT DENSITY=2.022 samples / m^2
LIDAR POINT SPACING=0.703 m
LIDAR OFFSET=( 314000, 4458000, 0 )
LIDAR SCALE=( 0.001, 0.001, 0.001 )
UPPER LEFT X=314000.000
UPPER LEFT Y=4459999.990
LOWER RIGHT X=315999.990
LOWER RIGHT Y=4458000.000

Combinar ahí la segmentación de SAM sobre la ortofoto con el modelo digital de superficie o con el modelo digital de terreno de tercera cobertura abre la puerta a extraer de forma casi automática elementos como afloramientos rocosos, morfología glaciar residual, o el trazado exacto de sendas y cortafuegos en terreno muy complejo, con un nivel de detalle que hasta ahora exigía trabajo manual intensivo de fotointerpretación.

En definitiva, SAM no sustituye el criterio del analista ni resuelve por sí solo la clasificación temática, de hecho, nada lo hace, pero como capa de segmentación rápida sobre cualquier ortofoto PNOA, combinada con el LiDAR de la misma cobertura, se perfila como un acelerador muy serio para flujos de extracción de elementos del territorio que hasta ahora dependían casi en exclusiva de digitalización manual.

Imagen 8 – Segundo test SAM de mayores dimensiones. Éxito en la configuración!

Lo que sí que se podría decir es que la segmentación ha venido para quedarse y saber segmentar, separar de acuerdo a texturas, patrones, tipologías, alturas, etc va a ser crucial para poder aprovecharlo para verificar cambios en los usos del suelo o tracking de fenómenos como la nueva urbanización o mismamente los incendios…

Alberto Concejal
Analista Geoespacial
Geovisualization.net

Fuentes:
https://ai.meta.com/research/sam2/
https://doc.arcgis.com/es/pretrained-models/latest/imagery/introduction-to-segment-anything-model-sam-.htm
https://learn.arcgis.com/es/projects/detect-objects-with-text-sam/
https://geospatialtraining.com/metas-sam-3-a-game-changer-for-gis-feature-extraction/

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