POP ESTIMATION USING DYNAMIC LULC SETTLEMENTS VALIDATION

The foundational step of 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 the Iberian Peninsula and North Africa—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: 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.

Setting up Mapterhorn terrain in RStudio

¿Alguna vez has querido visualizar el relieve de un territorio en 3D directamente desde R, 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.

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.

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 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.

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

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. 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!

URBAN ATLAS 2018 + WORLDPOP 100m/GHSL 100m estimates over Madrid

Urban Atlas (UA) representa el estándar de oro dentro del Copernicus Land Monitoring Service (CLMS) para el análisis de la morfología urbana en Europa. A diferencia de Corine Land Cover, UA ofrece una resolución temática y espacial drásticamente superior (Unidad Mínima de Mapeo de 0.25 ha para clases urbanas), permitiendo discriminar entre tejidos urbanos continuos y discontinuos con una precisión de densidad del 10% al 80%.

Testing GEMINI for 3D environments. From SketchUp to an unlikely future!

The exercise shows how a simple SketchUp 3D volume, defined solely by its basic geometry, can be transformed into a complex architectural proposal. Starting from the initial schematic model, the system interprets proportions, levels, and shapes, and converts them into a fully developed building, complete with textures, vegetation, lighting, and an urban context

Precision Elevation Data for Forest Giants: LiDAR vs ETH Global Canopy Height in Mata do Buçaco (Portugal)

High‑resolution elevation data underpins almost every spatial analysis we do in GIS—especially in forests where vertical structure defines habitat, biomass, wind exposure, fire behavior, hydrology, and the microclimates that sustain rare species. In rugged or densely vegetated environments, a coarse or biased elevation model propagates error everywhere: orthorectification drifts, hillshades mislead, slope/aspect misclassify, and canopy metrics saturate. The result is decisions made on blurred terrain that hides the very patterns we seek to manage. Precision elevation—derived from airborne LiDAR (Light Detection and Ranging)—solves this by separating the ground from the vegetation and delivering both a bare‑earth Digital Terrain Model (DTM) and a Digital Surface Model (DSM). Subtracting DTM from DSM gives a Canopy Height Model (DHM) that captures the true vertical architecture of the forest at sub‑meter resolution.

Using Excel to calculate the RMSE for LiDAR vertical ground control points

The height accuracy of the collected LiDAR data can be verified by comparing with independently surveyed ground control points on hard, flat, open surfaces. It is essentially just calculating the height differences for all the control points and then determining the height root mean squared error (RMSE) or differences. Most LiDAR processing software have the reporting function built-in. However, plain Microsoft Excel can also do the job (except for extracting the elevation from the LiDAR data).