Urban development in Madrid from the mid-19th century to the present day

Today I’m sharing a post from a while back about a project I worked on for an architecture firm, looking at Madrid’s urban development since the 19th century.

All existing buildings in Madrid currently listed in the Land Registry database have their year of construction recorded. This map shows, by decade, where the bulk of that urban development took place. For example, in the 1920s it was in the Salamanca district, in the 1930s in Chamartín… shifting from development in the city centre to the outskirts.

Figure 1 – The data obtained from the land registry was used to provide content for this exhibition at the CANAL Foundation

CLIFFORD. VIEWS OF MADRID UNDER ISABEL II

The Canal Foundation presents ‘Clifford: Views of Madrid under Queen Isabella II’, an exhibition dedicated to the work of one of the pioneers of photography. It comprises a selection of almost a hundred images organised into four sections: ‘The Pleasures of Photography’, ‘Old and New Madrid’, ‘In the Service of the Monarchy’ and ‘The Construction of the Canal de Isabel II: a project worthy of the Romans’. The exhibition offers a glimpse of Madrid before the arrival of running water – a city very different from the one we know today, to which the most ambitious engineering project of its time managed, almost a century late, to open the doors to modernity.

Added Value of GIS and Geovisualization in Urban Evolutionary Analysis

  • Spatiotemporal Data Synthesis: GIS facilitates the integration of disparate cadastral datasets into a unified spatial framework, transforming longitudinal construction records into high-density visual intelligence.
  • Dynamic Morphological Tracking: The transition from static cartography to animated geovisualization (e.g., temporal GIF rendering) enables the identification of urban “pulses,” capturing the velocity and direction of sprawl, infill development, and densification cycles that remain obscured in traditional tabular formats.
  • Heatmap Analytics & Kernel Density Estimation: By utilizing spatial Interpolation and density-based clustering, GIS highlights hotspots of urban intensity, allowing for a comparative analysis between centralized vertical growth and peripheral horizontal expansion.
  • Infrastructure Correlational Mapping: Geovisual tools allow for the overlay of historical urban growth against transport network expansion, providing a technical basis for evaluating the causal relationships between infrastructure deployment and land-use evolution.
  • Interactive Chronological Filtering: Modern geovisualization interfaces support granular temporal querying, enabling researchers to isolate specific socioeconomic eras and visualize the physical footprint of policy-driven urban shifts in real-time.
Figure 2 – Exhibition leaflet
Figure 3 – GIS map using ArcGIS Desktop

Hope you guys like it!

Alberto C.
GIS Analyst

Sources:
https://www.sedecatastro.gob.es/
https://www.fundacioncanal.com/exposiciones/clifford-vistas-del-madrid-de-isabel-ii/

Bienvenido a Madrid Río, donde el carril único lo usa todo el mundo… pero solo la mitad lo usa bien

Madrid Río va a su bola. Y tengo los datos para demostrarlo. Madrid Río, una de las arterias verdes más importantes de la capital: casi 7 km de recorrido por sentido, desde el Puente de los Franceses hasta el Parque Lineal del Manzanares, sin semáforos, sin coches, y con una norma tan sencilla que casi da vergüenza tener que recordarla: ve por la derecha.

Diagrama 1 – Si no quieres atropellar o ser atropellado, ve por tu derecha 🙂

No hay señales. No hay carriles diferenciados para peatones, corredores, ciclistas, patinetes, patines o skates. Solo una convención tácita, no escrita, que funciona… cuando la gente la respeta. El problema es que mucha gente no la respeta.

Diagrama 2 – Madrid Rio esquema. Estudio Álvarez-Sala (2011)
Diagrama 3 – Si vas por tu derecha, el mundo funciona! (norma no escrita sugerida)

Y cuando eso ocurre, se genera un caos silencioso. Normalmente se resuelve en segundos con ese equilibrio dinámico tan mediterráneo que tenemos —un quiebro, una mirada, un gesto— pero no siempre. He visto bicis arrollar a personas que iban por su lado. Grupos andando en paralelo, bloqueando la vía entera. Patinetes a velocidad de vértigo a punto de llevarse por delante a un niño que, irónicamente, iba exactamente donde debía. Yo mismo llevo usando esta vía desde casi su inauguración, hace más de once años, y puedo decir que el problema no ha mejorado: ha crecido, a medida que el carril se ha llenado de nuevas tipologías de movilidad.

¿Qué quiero hacer? Quiero medir esto. Con rigor, con datos, y con herramientas actuales. Mi objetivo es retratar estadísticamente quién va en el sentido correcto y quién no, desagregando por tipo de movilidad, edad, género y comportamiento en grupo. ¿Son los ciclistas los que más incumplen, o los patinetes eléctricos? ¿La gente mayor es más respetuosa que los jóvenes? ¿Los grupos de tres o más personas son el mayor factor de caos? No lo sé aún. Pero lo voy a descubrir.

Para ello uso mis conocimientos de análisis GIS para generar mapas de calor y patrones espaciales. La app está construida con tecnologías web estándar, sin ningún framework ni dependencia externa, como no podía ser de otra forma, me he ayudado de una IA, no la digo por no hacer publicidad pero en este caso he usado la que empieza por CL y termina por AUDE.

  • *HTML5 — estructura y contenido. Todo en un único fichero autocontenido, sin necesidad de servidor ni build process.
  • *CSS3 puro — estilos, layout con Grid y Flexbox, animaciones, variables CSS para el sistema de colores y soporte automático de dark mode con prefers-color-scheme.
  • *avaScript vanilla — sin React, sin Vue, sin jQuery, sin nada. Todo el comportamiento, la lógica de captura, el simulador, los gráficos y la gestión de datos está escrito en JS nativo del navegador.

Para los elementos específicos:

  • *Blob + URL.createObjectURL — generación y descarga del CSV directamente desde el navegador, sin servidor
  • *Canvas API (nativa del navegador) — el donut chart de OK/NOK en estadísticas
  • *localStorage — persistencia de datos entre sesiones, sin base de datos ni backend
  • *Geolocation API (nativa del navegador) — captura de coordenadas GPS en tiempo real

¿Por qué me importa? No soy escandinavo. No espero perfección. Entiendo que en Madrid las cosas funcionan a su manera y que eso tiene su gracia, pero me gustaría que mis paseos —y los de mis hijos— por esta vía fueran un poco más seguros. Y si de paso consigo que alguien lea esto, lo comparta, y la próxima vez que salga a correr piense dos segundos antes de cruzarse al carril contrario… misión cumplida.

A veces hacer las cosas un poco mejor no requiere una ordenanza municipal. Solo requiere información. Este proyecto empezó hace 11 años con un cuaderno y un bolígrafo. Hoy empieza de nuevo, con mejores herramientas. Aquí tenéis el post de hace ya 11 años!

Tipologías usuarios Madrid Río. Estadísticas y tendencias interesantes

1 Lo primero es comprender qué es ir bien y qué no, para ello he construido un simulador que me permite explicar tanto a la gente que va por la vía como a un posible ayudante que vaya a tomar datos. Registrar observaciones en tiempo real no es tan fácil como parece. Cuando hay mucha gente pasando a la vez —una bici, dos peatones y un patinete en tres segundos— es fácil perder el hilo, contar dos veces a la misma persona o simplemente no dar abasto.

Diagrama 4 – Entrenando el modelo, cada cuál va por donde debe…

Por eso antes de ir al campo, me entreno. El simulador recrea una sección transversal de la vía: dos sentidos de circulación, con sus zonas correctas marcadas en verde, una franja central de duda en naranja, y figuras que cruzan la pantalla a distintas velocidades según su tipo de movilidad. El ritmo puede ser tranquilo, normal o caótico —porque Madrid Río un domingo a las 11 de la mañana es, efectivamente, caótico.

Vídeo 1 – El simulador de Madrid Río 🙂

La mecánica es simple: clic izquierdo si va bien, clic derecho si va mal. El objetivo no es acertar —no hay respuesta correcta predefinida, tú eres el juez— sino desarrollar el reflejo de observar, clasificar y registrar sin perder de vista al siguiente que ya está entrando en pantalla.

Cuando el ritmo sube y aparecen tres iconos a la vez yendo en direcciones distintas, te das cuenta de que el trabajo de campo requiere más concentración de la que parece.

2 Pasamos a la acción. Ahora toca capturar los datos. El mayor reto de este proyecto no es el análisis —es el momento exacto en que alguien cruza la sección de medición.

Tienes aproximadamente un segundo. A veces menos, por eso la herramienta de captura está diseñada en dos tiempos. En el primero, solo hay dos botones: OK o NOK. Nada más. Sin pensar en si es hombre o mujer, sin estimar la edad, sin identificar si va en patinete o en patín eléctrico. Solo: ¿va por donde debe o no? Un toque y listo. El registro queda guardado con timestamp y coordenadas GPS.

El segundo tiempo llega cuando hay una pausa —entre una oleada y la siguiente. Entonces abres cada registro de la cola, que aparece marcado en amarillo si le falta detalle, y lo enriqueces con calma: tipo de movilidad, edad aproximada, género, si iba solo o en grupo. Campos que en el momento del cruce son imposibles de procesar, pero que con dos segundos de margen se completan sin problema.

Vídeo 2 – Extracción de datos y análisis de resultados

El resultado es un sistema que no te hace elegir entre velocidad y riqueza de datos. Primero capturas, luego describes. Y si pasan cuatro personas a la vez —cosa que pasa— no pierdes ninguna por intentar ser exhaustivo con la primera.

Diagrama 5 – Detallando el perfil del usuario de Madrid Río (1)

Este es el modelo de datos, cada persona que atraviesa el punto en el que tomo los datos ha de responder a este formulario. Lo has hecho bien?, Iba andando, corriendo?, Oba solo, acompañado?, Qué edad tenía?, Cuál es su género?.

Diagrama 6 – Detallando el perfil del usuario de Madrid Río (y 2)

¿Y tú, por dónde vas?

Los datos que recoja en esta primera fase son míos, de un único observador, en un punto concreto de la vía. Eso tiene valor, pero tiene límites, lo que realmente haría este proyecto significativo es escala: más puntos de medición, más horas del día, más días de la semana, más condiciones meteorológicas. Madrid Río no se comporta igual un martes lluvioso de febrero que un domingo de abril con sol, si paseas, corres, vas en bici o llevas a tus hijos por Madrid Río con cierta regularidad y te apetece participar, la herramienta es libre, funciona desde el móvil sin instalar nada, y el único requisito es estar en el sitio y tener ganas de mirar.

Diagrama 7 – Exportando a CSV (ponderando rieso)
Diagrama 8 – Hotspot analysis – importando GeoJSON desde CSV

No hace falta ser analista de datos. No hace falta saber de GIS. Solo hace falta pararse cinco minutos en un punto del recorrido y registrar lo que pasa delante de ti.

Si te interesa colaborar, tienes dudas sobre la metodología, o simplemente quieres debatir si esto tiene solución o estamos condenados a esquivarnos eternamente, déjalo en los comentarios o escríbeme directamente.

Y la próxima vez que salgas a Madrid Río… ya sabes. Ve por la derecha, por ti, por el que viene de frente, y por el niño que va exactamente donde debe.

Diagrama 8 – Interfaz de la Aplicación

Espero que os haya parecido interesante,

Alberto C.
Analista GIS

https://eas.es/proyectos/madrid-rio/
https://habitat.aq.upm.es/dubai/14/bp-52.html
https://es.wikipedia.org/wiki/Madrid_R%C3%ADo
revistes.ub.edu/index.php/ScriptaNova/article/view/42419
https://redalyc.org/journal/3692/369242871009/html/

POP ESTIMATION USING DYNAMIC LULC SETTLEMENTS VALIDATION

This methodology involves the deployment of a centralized processing interface within the Google Earth Engine (GEE) environment. The provided visualization captures the core interface of the custom GEE application, which serves as the hub for the multi-sensor LULC validation pipeline. Within this dashboard, users can define a specific Area of Interest (AOI)—highlighted here over Spain—and configure key parameters, including temporal ranges for the acquisition of sentinel-derived products. Crucially, the interface is designed to load and compare two primary datasets simultaneously: 10m Dynamic World (near real-time, probability-based LULC) and ESA WorldCover (10m resolution structured LULC). The contrasting classification schemes are represented by the legends on the left and right sides of the map view, which illustrate the varying definitions of ‘Built-up’ and urban areas between the two products. Establishing this visual and statistical comparison at the application level is the prerequisite for calculating the spatial disagreement threshold, or delta, that guides the subsequent merging and population estimation phases.

Figure 1 – Dynamic World and World Cover. LULC for pop estimation

In this stage of the workflow, the application performs a localized comparative analysis within the selected AOI (drawing a rectangle or freehand) cluster. The visualization highlights the spatial intersection between the Dynamic World and WorldCover datasets, where the red-shaded areas represent the high-confidence built-up zones confirmed by both sources.

A critical component of this dashboard is the automated calculation of the spatial disagreement (delta); as seen in the right-hand panel, the system evaluates the consistency between the LULC assets. If this delta remains below the 20% threshold, the urban pixels are merged to create a validated settlement mask. This mask then acts as the primary constraint for the population disaggregation phase. The interface displays the final output in real-time—in this instance, estimating a population of 9,643 individuals—by clipping the GHSL 2023 grid to the validated footprint. This ensures that the population count is geographically anchored only to verified human structures, providing a far more precise metric than the generalized figures typically found in administrative boundary datasets.

Figure 2 – Dynamic World extraction. If delta challenging them both is smaller than 20%, we go ahead

This third capture demonstrates the robustness of the methodology when applied to larger, more complex urban fabrics. In this scenario, the dashboard processes a more extensive metropolitan area, showcasing the comparative histogram between ESA WorldCover and Dynamic World (highlighted in the right-hand panel). These bar charts represent the pixel-wise distribution across various LULC classes, specifically comparing the extent of “Built-up” or “Urban” areas between the two assets. By analyzing these frequency distributions, we can quantitatively assess the spatial agreement before merging.

The visualization confirms that even at this broader scale, the logic remains consistent: the system validates the urban footprint by identifying where the two global products intersect geographically. As shown in the population indicator, the disaggregated estimate for this specific zone reaches 83,522 individuals. This illustrates the scalability of the GEE application, moving seamlessly from small clusters to large urban centers while maintaining the same rigorous validation threshold. The ability to visualize these distributions through real-time charting allows for immediate auditing of the spatial data quality, ensuring that the final population figures are derived from a high-confidence settlement mask rather than a single, potentially biased source.

Figure 3 – World Cover. LULC for pop estimation

This fourth visualization provides a critical look at the methodology’s sensitivity to agricultural-urban fringes and smaller, isolated settlements. In this specific Area of Interest (AOI), the application processes a more fragmented settlement pattern, where the population estimate is calculated at 3,009 individuals.

Figure 4 – GHSL23 pop estimation

The side-panel charting once again highlights the comparative analysis of LULC classes, emphasizing the “Urban” category (marked in the red circle on the histogram). This demonstrates the system’s ability to maintain a rigorous validation threshold even in peri-urban environments where spectral mixing between built-up areas and bare soil or crops is common. By requiring cross-product agreement before merging, the model avoids over-estimating population in rural-urban transition zones—a frequent error in static administrative datasets. The consistency of the population disaggregation, as seen here, proves that the workflow is robust across various settlement morphologies, ensuring that only structurally verified pixels are used to “anchor” the human presence data provided by GHSL 2023.

Figure 5 – Dynamic World and Worl Cover. LULC for pop estimation

In summary, the transition from rigid administrative boundaries to dynamic, LULC-validated population modeling represents a significant advancement in urban spatial analytics. By implementing a dual-source validation pipeline—leveraging the temporal frequency of Dynamic World and the structural precision of ESA WorldCover—we create a refined “Human Presence” mask that is far more representative of physical reality. This methodology effectively addresses the Modifiable Areal Unit Problem (MAUP) by anchoring population counts from GHSL 2023 to verified built-up pixels rather than generalized polygons. For researchers and urban planners, this granular approach is not merely a technical refinement; it is a vital tool for identifying socio-spatial vulnerabilities and ensuring that resource allocation is based on high-resolution, empirical evidence of where communities actually thrive. As urban landscapes continue to evolve at an unprecedented pace, these satellite-derived workflows provide the scalability and precision necessary to map the future of our cities accurately.

Hope you like it,

Alberto C.
Geospatial Analyst

Agricultura de precisión (II). APP para integración con Catastro rural en España

La convergencia entre los las aplicaciones geoespaciales actuales y la administración pública ofrece una oportunidad sin precedentes para la optimización agronómica. La capacidad de procesamiento de Google Earth Engine (GEE), vinculada a la cartografía vectorial del Catastro rural, permite transformar las series temporales de misiones como Sentinel-2 en herramientas de diagnóstico directo sobre la parcela. Este enfoque desplaza el análisis de una observación puramente visual a una monitorización cuantitativa basada en la respuesta espectral de los cultivos.

Agricultura de Precisión (I). Uso del Satélite para la toma de decisiones en el campo

El núcleo de esta aplicación reside en la intersección geométrica de las parcelas catastrales con colecciones de imágenes multiespectrales. Mediante el uso de la API de JavaScript en GEE, se automatiza el cálculo de indicadores biofísicos críticos como el NDVI (Índice de Vegetación de Diferencia Normalizada), el NDWI (Índice de Agua de Diferencia Normalizada), el EVI (Índice de Vegetación Mejorado) y el SAVI (Índice de Vegetación Ajustado al Suelo). Estos índices no solo reflejan el vigor fotosintético, sino que permiten identificar anomalías de crecimiento, estrés hídrico o variaciones en la densidad foliar que son invisibles al ojo humano en las fases tempranas del ciclo fenológico.

La integración técnica busca simplificar la toma de decisiones complejas en el campo. Al normalizar los datos del Catastro, la herramienta facilita que cualquier usuario técnico pueda extraer un informe en formato PDF con la evolución histórica y actual de su explotación. Este reporte actúa como un cuaderno de campo digital, proporcionando la base científica necesaria para determinar con precisión las ventanas temporales óptimas para la siembra, la aplicación selectiva de fitosanitarios para el control de plagas o la programación de la cosecha según el estado de madurez y los niveles de humedad detectados en el terreno.

A satellite map view of the area around Cadalso de los Vidrios, featuring geographical details such as roads, vegetation indices, and cadastral reference information.
Figura 1 – Interfaz de la aplicación en GEE

El funcionamiento de la aplicación se articula mediante la consulta de la base de datos catastral (cargada en GEE como un ASSET), permitiendo al usuario introducir una REFERENCIA CATASTRAL específica o buscar por POLÍGONO/PARCELA. Una vez reconocida la geometría de la parcela, el sistema actúa como un motor de filtrado espacial y temporal que realiza una llamada a las colecciones de imágenes satelitales disponibles en el repositorio de Google Earth Engine. Esta arquitectura permite que, de forma automatizada, se extraigan los valores de los píxeles contenidos exclusivamente dentro de los límites de la propiedad, eliminando el ruido de las parcelas colindantes o de elementos infraestructurales que podrían sesgar los resultados del análisis agronómico.

La potencia de esta integración reside en la generación dinámica de gráficos de series temporales y leyendas explicativas que traducen los valores espectrales en estados fenológicos comprensibles. Al seleccionar una parcela, la interfaz despliega una comparativa de índices (NDVI para vigor, NDWI para humedad y SAVI/EVI para densidades foliares complejas) que facilitan la detección de patrones de estrés hídrico o anomalías de crecimiento. Esta capa de información técnica es la que finalmente se consolida en el informe PDF, ofreciendo un registro histórico y actual del comportamiento del cultivo. De este modo, la herramienta no solo visualiza datos espaciales, sino que proporciona un respaldo estadístico para programar tareas críticas como la fertilización, el tratamiento de plagas o la determinación de la ventana de cosecha más eficiente según la madurez hídrica del terreno.

A satellite image of a land parcel with a yellow outlined boundary. Attribute information is displayed on the right, including details like area, coordinates, and various identifiers.
Figura 2 – Visualización de capas SHAPE descargadas desde https://www.sedecatastro.gob.es/. Global Mapper

La interfaz se ha estructurado para priorizar la visualización simultánea de la cartografía y la estadística multiespectral. En el panel lateral, el usuario gestiona la entrada de datos mediante la referencia catastral, lo que activa de forma inmediata el renderizado de la parcela seleccionada y la carga de sus atributos espaciales. El visor central ofrece una representación de alta resolución del terreno, mientras que el área de análisis despliega gráficos interactivos que segmentan las series temporales por índices. Esta disposición permite correlacionar directamente las variaciones visuales sobre el mapa con las fluctuaciones en las curvas de vigor y humedad, facilitando una interpretación técnica rápida de la evolución fenológica del cultivo sin salir del entorno de trabajo.

Aerial map view displaying a defined agricultural plot outlined in red, with various vegetation types and nearby structures. Accompanying graphs show indices for vegetation health, including SAVI and EVI, over a specified time period.
Figura 3 – Resultado de la búsqueda por “Referencia Catastral”

El componente analítico se materializa en la generación de series temporales multianuales, donde la superposición de los índices permite una lectura cruzada de la salud del cultivo. Al graficar conjuntamente métricas como el NDVI y el NDWI, es posible identificar con rigor técnico el desfase entre el estrés hídrico y la pérdida de vigor fotosintético. Esta serie histórica no solo sirve para el diagnóstico actual, sino que permite establecer líneas base de comportamiento fenológico, fundamentales para predecir anomalías climáticas o evaluar la efectividad de tratamientos agronómicos previos a escala de detalle.

Line graph comparing NDVI, NDWI, SAVI, and EVI over time from May 2020 to January 2026, displaying fluctuations in values.
Figura 4 – Resultado de la búsqueda por “Referencia Catastral”. Detalle de extracción de todos los índices

La aplicación culmina con la generación de un informe PDF que traduce el Big Data en decisiones de campo inmediatas. Al automatizar la integración entre GEE y Catastro, se elimina la barrera técnica, permitiendo que cualquier usuario interprete los ciclos críticos de su explotación sin necesidad de procesamientos complejos. Es, en definitiva, convertir el rigor científico en una herramienta operativa, legible y directamente aplicable para maximizar la eficiencia en cada parcela.

Espero que lo encuentres interesante, si es así, manda un saludo al menos! La verdad es que hay un millón de cosas que se pueden hacer usando Javascript en GEE, construyendo APP operativas desde el minuto cero, orientadas a Smart Cities o en este caso más concretamente a Smart Towns 🙂

Alberto C.
Analista Geoespacial

catastro.gob.es @catastro_es #MinisterioTransformaciónDigital #GEE #AgriculturaDePrecisión #GIS #RemoteSensing #Teledetección #BigData #Sentinel2

Super-résolution 1 m a Cadalso de los Vidrios, Madrid avec Sentinel 2 (10m). Magique !

Passer d’une résolution de 10 mètres à 1 mètre change radicalement la perspective du suivi agricole : on ne regarde plus une parcelle dans sa globalité, on observe ce qui se passe à l’intérieur même des rangs de culture. Ce saut qualitatif est possible grâce à l’algorithme S2DR3, un modèle de Deep Learning qui ne se contente pas d’agrandir les pixels, mais reconstruit l’information manquante. En s’appuyant sur les corrélations entre les différentes bandes spectrales de Sentinel-2 et en s’entraînant sur des images de très haute résolution, l’IA parvient à synthétiser une image à 1 m/pixel d’une précision étonnante.

Figura 1 – Super-résolution Sentinel-2 à 1 m – Cadalso de los Vidrios, Madrid

Le processus est entièrement automatisé : le code interroge le catalogue Copernicus pour extraire la scène la plus récente sur Cadalso de los Vidrios, en écartant systématiquement les passages nuageux pour garantir une donnée pure. Pour un utilisateur sur geovisualization.net, cela signifie obtenir un fond de plan ultra-précis sans dépendre de vols de drones coûteux ou d’imagerie commerciale privée.

Agricultura de Precisión. Uso del Satélite para la toma de decisiones en el campo

Une fois cette base de 1 mètre générée, l’exploitation en agriculture de précision devient chirurgicale. En calculant des indices comme le NDVI pour la vigueur végétative ou le NDWI pour le stress hydrique, on peut détecter des anomalies de croissance ou des besoins en irrigation sur des micro-zones spécifiques. L’utilisation d’indices plus fins comme le SAVI (qui ajuste l’influence du sol) ou l’EVI (plus sensible en zone de forte biomasse) permet de piloter chaque étape du cycle cultural.

Figura 2 – Extracción de índices de vegetación desde Sentinel -2
Figura 3 – S2DR3 Python Super-résolution Sentinel-2 à 1 m

On peut ainsi décider du moment exact de la plantation selon l’humidité résiduelle du sol, moduler l’apport d’engrais zone par zone, ou identifier les foyers de maladies avant qu’ils ne se propagent à toute l’exploitation. C’est le complément technique indispensable pour transformer la donnée satellite en une véritable aide à la décision sur le terrain.

# =========================================================
#       S2DR3 - Super-résolution Sentinel-2 à 1 m
#       Zone : Cadalso de los Vidrios, Madrid
# =========================================================
# --- 1. Monter Google Drive ---
from google.colab import drive
import os
from datetime import datetime
drive.mount('/content/drive')
# Nouveau dossier spécifique pour Cadalso
output_path = '/content/drive/MyDrive/Sentinel2_Cadalso1m'
!mkdir -p {output_path}
# Nettoyage et création du lien symbolique pour le moteur S2DR3
!rm -rf /content/output
!ln -s {output_path} /content/output
# --- 2. Installer le paquet S2DR3 ---
# Utilisation du wheel que vous avez validé
!pip -q install https://storage.googleapis.com/0x7ff601307fa5/s2dr3-20250905.1-cp312-cp312-linux_x86_64.whl
# --- 3. Importer le module principal ---
import s2dr3.inferutils
# --- 4. Définir la zone d'intérêt (Cadalso de los Vidrios) ---
# Coordonnées du centre du village. 
# Le moteur S2DR3 traite généralement une zone autour de ce point (buffer inclus).
lonlat = (-4.44, 40.30)
# --- 5. Définir la date Sentinel-2 ---
# On utilise la date d'aujourd'hui pour forcer la recherche de la scène la plus récente
date_actuelle = datetime.now().strftime('%Y-%m-%d')
# --- 6. Lancer le traitement ---
# La fonction 'test' gère automatiquement le téléchargement de la scène 
# la moins nuageuse proche de la date indiquée.
print(f"Lancement de la super-résolution pour Cadalso (Date cible : {date_actuelle})...")
s2dr3.inferutils.test(lonlat, date_actuelle)
print(f"✅ Traitement terminé. Les fichiers sont dans : {output_path}")

Le processus se déroule entièrement dans l’environnement Google Colab à l’aide d’un script Python.

J’espère que cela vous plaira,

Cordialement,
Alberto C.
Analyste géospatial

#AgroTech #S2DR3 #Télédétection #SuperResolution #AI #AgTech #Geovisualization #Sentinel2 #InteligenciaArtificia #Sentinel2 #Cadalso

https://www.sigterritoires.fr/index.php/es/uso-de-s2dr3-en-google-colab-para-el-estudio-de-los-corales-en-mauricio/
https://colab.research.google.com/
https://medium.com/@ya_71389/sentinel-2-deep-resolution-3-0-c71a601a2253
https://www.youtube.com/watch?v=zNX4vp1hGWI

Setting up Mapterhorn terrain in RStudio

¿Alguna vez has querido visualizar el relieve de un territorio en 3D directamente desde RStudio, sin depender de software GIS externo? Mapterhorn es un proyecto open source que distribuye modelos digitales de elevación (MDT) de alta resolución — hasta 2 metros en España — empaquetados en formato PMTiles, un estándar moderno que permite servir datos geoespaciales sin necesidad de un servidor propio.

En este post veremos cómo configurar Mapterhorn en R usando el paquete mapgl en Rstudio, que nos permite crear mapas interactivos con terreno 3D en pocas líneas de código. El resultado: visualizaciones como la que ves abajo, con sombreado de relieve (hillshade) generado directamente desde los datos de elevación del IGN.

No necesitas experiencia previa en cartografía — si sabes instalar paquetes en R, puedes seguir este tutorial.

Figura 1 – Empezamos a visualizar Mapterhorn

El siguiente paso es combinar el terreno de Mapterhorn con un estilo cartográfico que aporte contexto geográfico. En este ejemplo vemos la Sierra Norte de Madrid — con el embalse de Bustarviejo al fondo y municipios como Torrelaguna en primer plano — renderizada con una inclinación de cámara (pitch) de 60° y exageración de relieve moderada.

install.packages(c("mapgl", "terra", "elevatr", "sf", "tidyterra", "ggplot2"))
---------------------------------
library(mapgl)
library(terra)
library(elevatr)
library(sf)
maplibre(
  style  = carto_style("voyager"),
  center = c(-3.703, 40.416),
  zoom   = 14,
  pitch  = 40
) |>
  add_raster_dem_source(
    id       = "mapterhorn_pro",
    url      = "pmtiles://https://download.mapterhorn.com/planet.pmtiles",
    tileSize = 512,
    encoding = "terrarium"
  ) |>
  set_terrain(source = "mapterhorn_pro", exaggeration = 0.1) |>
  add_layer(
    id     = "sombras",
    type   = "hillshade",
    source = "mapterhorn_pro",
    paint  = list(
      "hillshade-exaggeration"          = 0.5,
      "hillshade-shadow-color"          = "#333333",
      "hillshade-illumination-direction" = 315
    )
  )

El resultado es un mapa donde el relieve deja de ser un dato abstracto y se convierte en algo inmediatamente legible: puedes ver de un vistazo la diferencia de altitud entre el fondo del valle del Jarama y las cumbres de la sierra, algo que un mapa plano convencional no transmite con la misma fuerza.

Figura 2 – Aportando contexto geográfico con un basemap (Google)
library(mapgl)
maplibre(
  style  = carto_style("voyager"),
  center = c(-3.60, 40.75),
  zoom   = 11,
  pitch  = 60
) |>
  add_raster_dem_source(
    id       = "mapterhorn",
    url      = "pmtiles://https://download.mapterhorn.com/planet.pmtiles",
    tileSize = 512,
    encoding = "terrarium"
  ) |>
  set_terrain(source = "mapterhorn", exaggeration = 1.5)
Figura 3 – Line of Sight analysis entre La Cibeles y la Puerta de Alcalá

Análisis de visibilidad: ¿se ven Cibeles y la Puerta de Alcalá entre sí?

Más allá de la visualización estética, los datos de elevación de Mapterhorn permiten hacer análisis geoespaciales reales. Un ejemplo clásico es el análisis de línea de visión (Line of Sight, LOS): dado un observador en un punto A, ¿puede ver el punto B sin que el terreno lo obstaculice?

En este caso trazamos el perfil de elevación entre la Fuente de Cibeles y la Puerta de Alcalá — apenas 500 metros de distancia en el centro de Madrid. La línea marrón representa el terreno real; la línea roja discontinua es la línea de visión teórica desde los ojos del observador (a 1,70 m de altura, ten en cuenta que la escala del eje Y está magnificada para mejor comprensión).

El resultado es claro: el terreno queda por encima de la línea de visión en todo el trayecto, lo que indica que el suelo sube progresivamente desde Cibeles hacia Alcalá. Curiosamente, aunque ambos monumentos son perfectamente visibles entre sí en la realidad (la calle es recta y despejada), el propio desnivel del terreno hace que la línea de visión rasante quede por debajo del suelo si no se tienen en cuenta los edificios ni la altura real de los monumentos.

Ahora comparemos nuestro Mapterhorn 2m con el Copernicus 30m, a pesar de que esta comparación es inconsistente más allá de una interpretación puramente visual.

Figura 4 – Visualizamos el DSM-ish 30m de Copernicus y el DTM-ish 2m del IGN (alerta de inconsistencia QC)
library(elevatr)
library(terra)
library(ggplot2)
# 1. Zona y descarga de ambos MDTs
puntos <- data.frame(x = c(-4.0, -3.8), y = c(40.7, 40.9))
dem_low  <- rast(get_elev_raster(puntos, z = 8,  prj = "EPSG:4326", clip = "bbox"))
dem_high <- rast(get_elev_raster(puntos, z = 14, prj = "EPSG:4326", clip = "bbox"))
# 2. Perfil de elevación (path profile) a lo largo de una transecta
pasos <- 200
lon_seq <- seq(-4.0, -3.8, length.out = pasos)
lat_seq <- seq(40.7, 40.9, length.out = pasos)
coords  <- cbind(lon_seq, lat_seq)
z_low  <- extract(dem_low,  coords)[, 1]
z_high <- extract(dem_high, coords)[, 1]
dist_m <- seq(0, 25000, length.out = pasos) # ~25km de transecta
# 3. Path profile comparativo
perfil_df <- data.frame(
  distancia  = rep(dist_m, 2),
  elevacion  = c(z_low, z_high),
  fuente     = rep(c("Copernicus GLO-30 (~30m)", "Mapterhorn IGN (~2m)"), each = pasos)
)
ggplot(perfil_df, aes(x = distancia / 1000, y = elevacion, color = fuente)) +
  geom_line(linewidth = 0.8, alpha = 0.85) +
  scale_color_manual(values = c("Copernicus GLO-30 (~30m)" = "#e74c3c",
                                "Mapterhorn IGN (~2m)"     = "#2c3e50")) +
  labs(
    title    = "Perfil de elevación: Copernicus vs Mapterhorn",
    subtitle = "Transecta SW-NE sobre la Sierra de Guadarrama",
    x        = "Distancia (km)",
    y        = "Altitud (m)",
    color    = NULL
  ) +
  theme_minimal(base_size = 13) +
  theme(legend.position = "top")
# 4. RMSE — remuestrea el MDT de alta res a la resolución del bajo
dem_high_resampled <- resample(dem_high, dem_low, method = "bilinear")
z_low_full  <- values(dem_low)
z_high_full <- values(dem_high_resampled)
# Elimina NAs
idx <- complete.cases(z_low_full, z_high_full)
rmse <- sqrt(mean((z_high_full[idx] - z_low_full[idx])^2))
cat(sprintf("RMSE entre Copernicus GLO-30 y Mapterhorn IGN: %.2f metros\n", rmse))
# 5. Diferencia espacial (mapa de error)
diff_raster <- dem_high_resampled - dem_low
plot(diff_raster,
     main = "Diferencia de elevación: Mapterhorn - Copernicus (m)",
     col  = hcl.colors(100, "RdBu", rev = TRUE))
Figura 5 – RMSE entre Copernicus GLO-30 y Mapterhorn IGN: 9.34 metros (alerta de inconsistencia QC)

Pero como avanzaba, Copernicus GLO-30 y Mapterhorn IGN no son dos mediciones del mismo fenómeno a distinta resolución — son dos productos con orígenes, metodologías y fechas de captura completamente diferentes. Copernicus GLO-30 se deriva del radar de apertura sintética del satélite TanDEM-X, que mide la superficie de la Tierra desde el espacio con una resolución nominal de 30 metros. Al ser una medición radar, captura la parte superior de la vegetación y los edificios, no el suelo desnudo — lo que en cartografía se llama un Modelo Digital de Superficie (MDS), no un Modelo Digital del Terreno (MDT) estricto.

Mapterhorn distribuye los datos del IGN España, obtenidos mediante vuelos LiDAR que permiten filtrar la vegetación y los edificios para obtener el suelo real. El resultado es un MDT de 2 metros de resolución que representa la topografía con una precisión altimétrica muy superior.

Por tanto, el RMSE que calculamos no mide únicamente el error de Copernicus — mide la diferencia acumulada entre dos modelos distintos, que incluye diferencias reales de resolución, diferencias metodológicas y el efecto de la vegetación sobre el radar. En zonas boscosas como la sierra de Guadarrama, estas diferencias pueden ser especialmente pronunciadas, llegando a varios metros en las áreas más densamente arboladas.

Figura 6 – Mapterhorn en Rstudio

Lo que hemos visto en este post es solo el punto de entrada. Una vez que tienes los datos de elevación conectados, las posibilidades se multiplican rápidamente.

En el ámbito del análisis de terreno puedes calcular pendientes y orientaciones para estudios de riesgo de erosión, planificación de infraestructuras o modelado de radiación solar. A partir del mismo MDT puedes delimitar cuencas hidrográficas automáticamente, trazar la red de drenaje teórica o calcular el área de captación de cualquier punto del territorio. Para proyectos de energía renovable, cruzar las orientaciones de ladera con datos de irradiación permite identificar zonas óptimas para instalaciones solares con pocas líneas de código.

En visualización avanzada puedes combinar el terreno 3D con cualquier capa vectorial propia — rutas de senderismo, límites administrativos, localizaciones de campo — y exportar el resultado como HTML interactivo para publicar directamente en la web. El paquete mapgl permite animar la cámara con fly_to() para crear recorridos virtuales sobre el terreno, algo especialmente útil para presentaciones o divulgación. También puedes generar mapas de sombreado artístico cambiando el ángulo de iluminación para conseguir efectos visuales dignos de cartografía profesional.

Para aplicaciones más especializadas, los datos de Mapterhorn son la base ideal para análisis de intervisibilidad a escala regional — por ejemplo, calcular desde cuántos puntos del territorio es visible una antena, un parque eólico o una torre de vigilancia de incendios. En urbanismo y ordenación del territorio permiten modelar el impacto visual de nuevas construcciones o calcular perfiles de ruido considerando la topografía real.

Todo esto sin salir de RStudio, sin licencias de software GIS y con datos de la máxima resolución disponible para España.

Mapterhorn ha eliminado uno de los principales obstáculos que tenían los usuarios de R para trabajar con datos de elevación de alta resolución: la complejidad de acceder, descargar y procesar MDTs de fuentes institucionales. Con una sola URL y tres líneas de código tienes acceso a los mejores datos topográficos disponibles para España y buena parte de Europa, listos para visualizar o analizar.

Espero que te haya interesado,

Alberto C.
GIS Analyst

#RStats #Mapterhorn #GIS #Cartografía #MapGL #TerrainAnalysis #OpenData #Geovisualización #RStudio #LiDAR #IGN #SpatialData #Mapping #DataViz #Topografía #RemoteSensing #OpenSource #GeospatialR #MDT #Hillshade

https://mapterhorn.com/
https://protomaps.com/blog/mapterhorn-terrain/
https://github.com/mapterhorn
https://posit.co/download/rstudio-desktop/
https://centrodedescargas.cnig.es/

Aventuras y desventuras de un geógrafo en “desarrollo”

La cartografía siempre ha sido un oficio de precisión, paciencia y criterio espacial. Durante años, el flujo de trabajo de cualquier geógrafo pasaba inevitablemente por entornos de escritorio como ArcGIS Pro o QGIS: cargar capas, ajustar simbología, exportar mapas. Herramientas sólidas, probadas, indispensables. Pero algo está cambiando.

Cada vez más, el análisis espacial ocurre en la nube, en navegadores, en entornos de código. En anteriores post habéis visto algunos test/ideas/aplicaciones que he desarrollado con Javascript Google Earth Engine, que procesa imágenes satelitales a escala planetaria sin mover un solo archivo. Deck.gl y Maplibre renderizan millones de puntos en 3D directamente en el navegador. React convierte un mapa en una aplicación interactiva con pocas líneas de código.

Figura 1 – GEE, segmentación de edificios con imagenes centimétricas en Tallin (Estonia)

Este post es el diario de ese viaje: el de un geógrafo que ha empezado a escribir código no para dejar de ser geógrafo, sino para serlo mejor. Desde la segmentación de ortofotos con algoritmos de machine learning en GEE, hasta la visualización de datos de población en 3D con Maptiler y Deck.gl, pasando por entornos propietarios y de código abierto.

Sin renunciar al criterio espacial. Solo añadiendo nuevas herramientas.

Figura 2 – Entorno de codesandbox.io, eligiendo React

El primer paso fue elegir dónde trabajar. CodeSandbox permite lanzar un entorno React completo directamente en el navegador, sin instalar nada. Basta elegir la plantilla, pegar el código y ver el resultado en tiempo real. Para un geógrafo acostumbrado a instalar plugins y configurar proyectos, la inmediatez es llamativa.

React actúa aquí como el pegamento: gestiona el estado de la aplicación (qué año se muestra, qué capa está activa) y renderiza la interfaz. No es imprescindible saber todo sobre React para empezar — con los hooks básicos useState y useEffect ya se puede construir bastante.

Figura 3 – Conectando con ficheros subidos a Maptiler

Con el entorno listo, el siguiente reto fue conectar datos reales. Los edificios del centro de Madrid — subidos previamente a Maptiler Cloud como GeoJSON — se visualizan en 3D extruidos usando Maplibre GL JS, cargado directamente desde CDN sin necesidad de instalar nada.

El atributo ESTAGL de cada polígono define la altura de la extrusión. El resultado: una vista aérea inclinada de Madrid donde cada edificio tiene volumen real. El basemap de Maptiler topo-v2 aporta el contexto geográfico debajo.

Figura 4 – Simbolización y generación de código para hacer un change detection de población en Madrid 2015-2020-2025

El siguiente experimento usó datos de WorldPop — una fuente de población global a resolución de 100×100 metros — para tres años: 2015, 2020 y 2025. Los datos, originalmente en formato raster, se convirtieron a polígonos y se subieron a Maptiler Cloud como tres datasets independientes.

El reto aquí era visual: las diferencias de población entre años son pequeñas y una escala lineal las hace invisibles. La solución fue aplicar una escala logarítmica (log1p) que comprime los valores extremos y amplifica las diferencias sutiles. El resultado es el mapa amarillo-verdoso de la imagen: la mancha urbana de Madrid claramente definida, con los núcleos de mayor densidad destacados.

Pero la visualización más interesante llegó al pasar al 3D. En lugar de mostrar los valores absolutos, se calculó el delta de cada píxel respecto a 2015 — cuánto ha cambiado la población en cada celda de 100m.

Ese delta se convierte en altura: más cambio, más altura. El color va de verde (poco cambio) a rojo (mucho cambio). El resultado es una especie de paisaje urbano donde las zonas de mayor transformación demográfica emergen literalmente del mapa, extruidas sobre el basemap de Maptiler.

La animación entre 2020 y 2025 — con transición suave usando requestAnimationFrame y una función easeInOut — permite ver cómo evoluciona ese paisaje en el tiempo.

Figura 5 – Probando con diferentes modos de simbolización, interfaces, secuencias temporales, etc

Una de las lecciones más claras de este ejercicio es que la visualización es iterativa. La primera versión del mapa 3D mostraba todos los cambios en verde — funcionaba, pero no comunicaba. ¿Verde intenso significa mucho cambio o poco?

La segunda versión introduce una paleta divergente verde→rojo donde el color codifica la magnitud del delta: verde para cambios pequeños, amarillo para cambios medios, rojo para las zonas de mayor transformación. La altura sigue siendo proporcional al delta, pero ahora el color refuerza ese mensaje.

El resultado — visible en esta imagen de abajo— es un mapa que se lee de forma intuitiva: las zonas rojas y altas son las que más han cambiado demográficamente respecto a 2015. Un lenguaje visual que cualquier persona puede entender sin necesidad de una leyenda detallada.

Figura 6 – El archivo “respira” pasando por los años 2015-2020-2025!!

Pues aquí tenemos el resultado final, un mapa de cambios VIVO (que cambia los slides a lo largo de la linea temporal elegida 2015-2020-2025). Pareciera que se infla 🙂

Espero que os guste, yo por mi parte os aclaro que mi intención no es otra que renovar mi portfolio, mostrar cositas nuevas que sé hacer desde hace poco y enseñar las potencialidades de estas metodologías y procedimientos de alguna manera nuevos para alguien como yo, acostumbrado a unos entornos con mucho fondo pero mucho menos dinámicos y mucho más encorsetados. si ves algo que te interesa, no tienes más que contármelo y hablamos. Por cierto, estoy buscando trabajo!! (por si coincide).

Saludos.
Alberto C.

https://cloud.maptiler.com/
https://codesandbox.io/templates

ESTIMATED GHSL vs INE 2025

He desarrollado este COMPARADOR DE POBLACIÓN GHSL vs PADRÓN INE 2025 en JavaScript/Google Earth Engine que cruza rapidísimamente estimaciones satelitales de población con los datos oficiales del censo español municipio a municipio.

La herramienta permite seleccionar cualquier provincia y municipio de España, visualizar la distribución espacial de población estimada por el GHSL con el último dato oficial del INE 2025, detectando municipios con alta presión turística, despoblación real o población no registrada.

Una aplicación directa para planificación de infraestructuras, gestión de emergencias o análisis de cohesión territorial donde el padrón no refleja la ocupación real del territorio.

Alberto C.

Flood assessment using RADAR (Sentinel1), SRTM v3+ and GHSL pop estimation in Spain

I have developed this NRT FLOOD RISK ASSESSMENT monitor in GEE that merges the power of RADAR and GHSL to detect impact over POPULATIONS under any weather conditions.

You can use geospatial intelligence to quickly transform satellite data into critical decisions during climate emergencies. GIS technology driving global resilience!

Hope you like it. If you need further explanation please dont hesitate to contact me.

Alberto C.
GIS Analyst

From LIDAR USGS to DSM in a few lines of code. The magic of R

Figura 1 – Exporting LIDAR to DSM (properly) (Global Mapper 26.2)

The USGS LiDAR Explorer, hosted via gishub.org, serves as a high-performance web gateway for interacting with the USGS 3D Elevation Program (3DEP) datasets. Developed by Qiusheng Wu, the platform leverages Cloud Optimized Point Clouds (COPC) and Entwine Point Tile (EPT) formats to enable seamless 3D visualization of massive LiDAR clouds directly in the browser without the need for local downloads.

Figura 2 – https://usgs-lidar.gishub.org/ search your COPC

By integrating data from Microsoft Planetary Computer and AWS Open Data, it provides an essential infrastructure for researchers and developers to search, visualize, and eventually pull high-resolution elevation data into R for sophisticated urban and environmental modeling.

Now we can start playing with LIDAR! No need to download anything, just save the names of your COPCs and you can put R to work right away.

First thing, go to this GITHUB repository https://github.com/opengeos/maplibre-gl-usgs-lidar, download code for the project (code>download ZIP), get connected with RStudio, save new project and open a script window… It’s all set up!

Figura 3 – Set up your R project

Cloud Optimized Point Clouds (COPC) represent a modernization of the standard LAZ format, specifically designed to handle massive LiDAR datasets within cloud-native environments. By reorganizing the data into a clustered octree structure, COPC allows software to stream only the specific portions or levels of detail needed for a task without downloading the entire file. This efficiency makes it the backbone of platforms like the USGS LiDAR Explorer, enabling high-speed 3D visualization and analysis directly from remote servers while maintaining full backward compatibility with traditional LAS/LAZ readers.

Figura 4 – visualize LIDAR data, make it thinner, filter by height, switch to a different classification method…
library(lidR)
library(terra) # Necesaria para manejar el DSM como una imagen/superficie
# Definimos la ruta exacta que proporcionaste
ruta_boston <- "C:/R/maplibre_lidar/maplibre-gl-usgs-lidar-main/lidar_sample/USGS_LPC_MA_Sndy_CMPG_2013_19TCG315920_LAS_2015.copc.laz"
# Leemos el archivo (usamos un filtro para no saturar la RAM si es muy denso)
las <- readLAS(ruta_boston, select = "xyzc")
# Verificamos que se ha cargado correctamente
print(las)
-------------------
# Generamos el DSM con una resolución de 1 metro
# El algoritmo p2r(0.2) rellena huecos pequeños para que parezca sólido
dsm <- rasterize_canopy(las, res = 1, algorithm = p2r(0.2))
# Visualización rápida en 2D (Mapa de calor)
plot(dsm, col = terrain.colors(50), main = "Modelo Digital de Superficie (DSM) - Boston")
-------------
# Convertimos el raster a un formato que RGL pueda renderizar como superficie
plot_dtm3d(dsm, bg = "black")
---------------------
# Crear mapa de sombras
pendiente <- terrain(dsm, v = "slope", unit = "radians")
aspecto <- terrain(dsm, v = "aspect", unit = "radians")
sombras <- shade(pendiente, aspecto, angle = 45, direction = 315)
# Visualizar el DSM con sombras
plot(sombras, col = grey(0:100/100), legend = FALSE)
plot(dsm, col = terrain.colors(50, alpha = 0.5), add = TRUE)
-------------
library(lidR)
library(terra)
# 1. Cargar el archivo completo (Ruta que confirmaste)
ruta_boston <- "C:/R/maplibre_lidar/maplibre-gl-usgs-lidar-main/lidar_sample/USGS_LPC_MA_Sndy_CMPG_2013_19TCG315920_LAS_2015.copc.laz"
las <- readLAS(ruta_boston, select = "xyzc")
# 2. Elegimos una zona con edificios (puedes ajustar estos números tras ver el summary)
# Estos valores suelen estar en el rango del summary(las)
subset_las <- clip_rectangle(las, 331500, 4691500, 331700, 4691700)
# 3. Generar el DSM (Superficie sólida) de alta resolución
# Usamos res = 0.5 para que el zoom se vea nítido
dsm_zoom <- rasterize_canopy(subset_las, res = 0.5, algorithm = p2r(0.3))
--------------------
library(lidR)
library(terra)
# 1. Cargar el archivo de Boston
ruta_boston <- "C:/R/maplibre_lidar/maplibre-gl-usgs-lidar-main/lidar_sample/USGS_LPC_MA_Sndy_CMPG_2013_19TCG315920_LAS_2015.copc.laz"
las <- readLAS(ruta_boston, select = "xyzc")
# 2. Selección automática de la zona central (Cubo de 160m x 160m)
x_mid <- mean(c(las@header@PHB$`Max X`, las@header@PHB$`Min X`))
y_mid <- mean(c(las@header@PHB$`Max Y`, las@header@PHB$`Min Y`))
subset_las <- clip_rectangle(las, x_mid - 80, y_mid - 80, x_mid + 80, y_mid + 80)
# 3. Crear el DSM (Superficie continua)
# El parámetro p2r(0.3) rellena los espacios vacíos entre rebotes del láser
dsm_final <- rasterize_canopy(subset_las, res = 0.5, algorithm = p2r(0.3))
# 4. Visualización 3D Sólida
plot_dtm3d(dsm_final, bg = "black", col = "lightblue")
--------------
install.packages("viridis")
--------------------
library(lidR)
library(terra)
library(viridis) # Ahora que ya está instalado
# 1. Aseguramos que la superficie esté bien calculada
# Usamos un radio de 0.4 para cerrar huecos sin crear "picos"
dsm_raw <- rasterize_canopy(subset_las, res = 0.5, algorithm = p2r(0.4))
# 2. Suavizado (El secreto de la visualización NEAT)
# Aplicamos un filtro de media para que los techos se vean planos y lisos
dsm_smooth <- focal(dsm_raw, w = matrix(1, 3, 3), fun = mean, na.rm = TRUE)
# 3. Renderizado 3D Estilo Maqueta
# 'border = NA' elimina las líneas negras que ensucian la imagen
# 'col = viridis(256)' aplica el degradado profesional
plot_dtm3d(dsm_smooth, 
           bg = "black", 
           col = viridis(256), 
           border = NA, 
           lighting = TRUE)
----------------
 plot_dtm3d(dsm_smooth, 
             bg = "white", 
             col = "grey90", 
             border = NA, 
             lighting = TRUE)
-----------------
install.packages("magick")
library(magick)
-----------------
library(rgl)
# 1. Asegúrate de que la ventana de RGL esté abierta con tu modelo
# 2. Definimos la función de giro (alrededor del eje Z)
girar_camara <- spin3d(axis = c(0, 0, 1), rpm = 3) # 3 revoluciones por minuto
# 3. Grabar la animación
# Esto creará un archivo llamado "boston_360_02.gif" en tu carpeta de trabajo
movie3d(
  f = girar_camara, 
  duration = 20,      # Duración en segundos
  dir = getwd(),      # Se guarda donde tengas el proyecto
  movie = "boston_360_02", 
  type = "gif",
  clean = TRUE        # Borra los fotogramas sueltos al terminar
)
----------------------
play3d(spin3d(axis = c(0, 0, 1), rpm = 10), duration = 10)
---------------------
movie3d(
    f = spin3d(axis = c(0, 0, 1), rpm = 3), 
    duration = 10,
    dir = getwd(),
    movie = "boston_360_03", 
    type = "gif",
    clean = TRUE
)
-------------------
  # Guarda la vista actual como una imagen PNG nítida
  snapshot3d("Boston_Maqueta_Pro.png", fmt = "png", width = 1200, height = 900)
Figura 5 – All set up!

Integrating LiDAR with Open Data in R transforms your POINTS into decisions by fusing i.e physical geometry (OSMs) with precise height (LIDARs), roof pitch, and volume of every structure in a neighborhood, which is essential for determining solar energy potential or tax assessments without manual surveys.

Beyond architecture, this workflow excels in environmental management when you link city-managed tree inventories with point cloud segments. By isolating individual tree crowns in the LiDAR data and joining them to open databases via their geographic coordinates, R can report on the specific health, biomass, and carbon capture of different species across the city. You can also derive micro-topography from a LiDAR ground model and intersect it with open hydrography or sewage network data to simulate precise flood pathways during extreme weather, predicting exactly which street corners will flood based on the actual height of the curbs and pavement.

Figura 6 – Split it into tiles, play with it!

It’s a lot what you can do integrating different technologies and different kind of data…

Figura 7 – My recent official certification in Global Mapper / LIDAR module

Do you want me to surf your LIDAR dataset and extract, classify, integrate, merge or challenge it with other data? Let’s talk. I’m free and easy:-) and the most important, looking for interesting projects, well, a job:-)

Alberto C.
Geodata analyst

Sources:
https://github.com/opengeos/maplibre-gl-usgs-lidar
https://usgs-lidar.gishub.org/