Jose Escobar — Independent geospatial data engineer

Four systems, end to end

One technical function — geospatial data systems — applied across four adjacent environmental problems. Each starts from a decision someone has to make and ends with the evidence and the caveats needed to make it. Open any case study for the full method, validation and limitations.

Disaster response

Haiti 2010 · Kumamoto 2016
Airborne LiDAR, post-event

Python
laspy
SciPy
GeoPandas
pyproj
Overpass API
Leaflet
GPX

Structural Triage Engine

Turns a post-earthquake laser scan into a ranked inspection list and a field route, on day one, with no internet connection.

The problem: Hours after an earthquake, a municipal government has thousands of standing buildings and a handful of qualified inspectors. Nothing tells them where to start, and connectivity is usually the first thing to fail.
Who it serves: Municipal building-safety departments, civil protection units, and disaster-response NGOs working the first 72 hours.
What I built: A prototype relative-priority heuristic, packaged as an offline-first Python CLI. One command takes a post-event airborne LiDAR point cloud and returns a self-contained interactive priority map plus an optimised GPX route for the crew that has to drive it.
Result: Runs unchanged on two independent post-disaster datasets from different countries, coordinate systems and construction typologies — Haiti 2010 and Kumamoto 2016.
Main limitation: The score ranks buildings relative to their neighbours in one scan. It is not a damage classification, and it has not been checked against engineer-assigned damage grades.

Read the full technical case study

How it works: Four geometric indicators per building footprint: vertical distribution entropy at 40%, a heuristic signal associated with irregular or debris-filled returns; point density irregularity at 30% for chaotic scatter; roof planarity RMSE at 20% by least-squares plane fitting; and point count deficit at 10% against expected intact-roof return density. Footprints come from OSM via the Overpass API. Percentile ranking assigns Critical, High, Moderate and Low tiers, and route order is nearest-neighbour within each tier — Critical first, shortest travel.
Validation: Haiti 2010, magnitude 7.0, 17.9 million points, EPSG:32618, informal concrete-block construction. Kumamoto 2016, magnitude 7.0, 8 million points, EPSG:2444, Japanese timber frame. Same codebase, no changes between runs.
Limits and next steps: The indicators are heuristics chosen for physical plausibility, not calibrated parameters — the engine says which buildings look least like their neighbours, not that a building is unsafe. Scoring against engineer-assigned damage grades is the validation that would make it operational. A real deployment would also need multi-crew route assignment and sync, authentication, and pre-event baseline scans to separate new damage from pre-existing condition.

Open the repository Research-level README: physics reasoning, known limitations, full CLI reference

Flood risk

Houston TX · Arkansas Ozarks
Public DEM, soil and rainfall data

Python
pysheds
WhiteboxTools
rasterio
Green-Ampt
Muskingum-Cunge
HAND
SSURGO

Hydrological Terrain Simulation Engine

Answers "does this site flood, and how badly" from a public elevation model in hours, before anyone commits budget to a full engineering study.

Hydrological engine output for coastal Houston — Coastal Houston: 163 independent catchments across flat terrain.

Hydrological engine output for the Arkansas Ozarks — Arkansas Ozarks: one nested watershed. Same command, no code changes.

The problem: A full engineering flood study costs weeks and thousands of dollars. Before that spend, someone has to decide which sites are even worth studying — and that screening decision is usually made on intuition or an outdated flood map.
Who it serves: Site developers and planning offices screening candidate sites, and flood-risk analysts who need a defensible first pass.
What I built: A standalone Python CLI. An elevation GeoTIFF goes in; an animated flood simulation, a PDF drainage report, GIS-ready basin data and per-building flood exposure come out. No manual GIS work at any stage.
Result: Deterministic by test rather than by assumption, and validated for generalisation on a physiographically opposite region using the same command with zero code changes.
Main limitation: A screening tool, not a substitute for a permitted hydraulic study. The routing is one-dimensional and the results are not calibrated against stream gauge records.

Read the full technical case study

How it works: Automated acquisition of NHD hydrography, SSURGO soils and NOAA Atlas 14 rainfall, then stream-burned terrain conditioning, D8 flow routing, drainage-area-threshold sub-basin delineation, Green-Ampt infiltration using real SSURGO soil parameters and cross-validated against SCS Curve Number, Muskingum-Cunge kinematic wave routing through DEM-derived compound channels, and HAND-based flood mapping.
What broke: Repeated runs on an identical DEM were producing different basin summaries. Hashing every pipeline intermediate across runs localised the fault to terrain conditioning, where two WhiteboxTools operations break ties non-deterministically on flat ground and shift drainage divides between otherwise identical runs. I replaced conditioning with priority-flood filling in pysheds and added a permanent reproducibility gate: two runs, byte-identical summaries, or the test fails. That fix exposed a second design flaw — the stream threshold was a fraction of the DEM's own peak flow accumulation, so basin count was hostage to whatever the largest stream happened to carry — which I redesigned as an absolute drainage-area parameter in square kilometres.
Validation: The Arkansas Ozarks resolved correctly to an 8.4 in design storm against 17.7 in for the Gulf Coast, and to the opposite drainage topology — 64 basins organised as one nested watershed draining 33.5 of 48.5 sq mi through a single outlet, against the coastal corridor's 163 independent catchments — from the same command with no code changes.
Limits and next steps: One-dimensional routing means no backwater, storm surge or built drainage infrastructure. Nothing is calibrated against gauge records. Coverage is currently US-only because of the NHD, SSURGO and Atlas 14 dependencies. The next steps that matter are gauge calibration, 2D routing where the terrain demands it, and data adapters for non-US regions.

Open the repository

Conservation enforcement

Pará · Amazonas · Mato Grosso · Rondônia
Hansen GFC 2001–2023, WDPA 2024

PostgreSQL 17
PostGIS 3.6
Supabase
Earth Engine
Hansen GFC
MODIS
Leaflet

Amazon Deforestation Intelligence Platform

Identifies which satellite forest-loss detections fall inside registered protected areas, with the evidence attached to each one.

The problem: A conservation NGO receives a generic alert that deforestation is happening in the Amazon. Without knowing whether a given detection sits inside a protected boundary, there is nothing to report and nobody to report it to.
Who it serves: Conservation NGOs, protected-area managers, and environmental enforcement teams who need a location and a source, not a headline.
What I built: A spatial join between satellite forest-loss detections and protected-area boundaries, published as a live filterable web map backed by a real database rather than a static export.
Result: 66 potential protected-area overlaps identified using ST_Within, each one resolving to full detail traceable back to its original public source.
Main limitation: Hansen detects canopy loss, not legality. An overlap is a lead for investigation, never evidence of a crime.

Read the full technical case study

How it works: 1,121 Hansen GFC v1.11 forest-loss pixels exported from Google Earth Engine across four Brazilian states for 2001–2023. Loss drivers derived from MODIS MCD12Q1 post-loss land cover using the published proxy methodology that INPE and Global Forest Watch use — forest degradation 569, cattle ranching 541, fire 5, agriculture 4, mining 2 — not synthetic labels. 370 WDPA v2024 boundaries covering indigenous territories, national parks and extractive reserves. PostgreSQL 17 and PostGIS 3.6 with GIST spatial indexes, migrated to Supabase for live hosting, with a Leaflet frontend querying the Supabase REST API.
Result: 66 of the 1,121 loss detections fall inside a registered protected-area polygon under ST_Within. The map filters by year, driver and overlap status, and every point resolves to full detection detail.
Limits and next steps: Hansen loss is annual and 30 m, and it records canopy loss rather than legality — an overlap is a lead, not proof. The MODIS-derived driver is a 500 m proxy, coarser than the detections it labels, and WDPA boundaries carry their own positional error. To be operationally useful this needs near-real-time alert ingestion such as GLAD or RADD instead of annual Hansen, scheduled automated updates, and authentication with an audit trail on anything exported for a report.

Open the live platform

Agriculture and water

13 Vietnamese provinces · Kandal · Prey Veng
Sentinel-2 · three-crop calendar

Earth Engine
Sentinel-2 SR
Synthetic parcels
GDAL / COG
PostGIS
Supabase
AWS S3
Leaflet
Chart.js

Mekong Delta Agricultural Intelligence Platform

A parcel-level spectral monitoring interface for a delta with no public cadastre — real Sentinel-2 imagery, a modelled parcel layer.

Mekong Delta platform, Sentinel-2 band composite — Sentinel-2 composite over the delta, switchable across five bands.

Mekong Delta platform, parcel time series — Per-parcel NDVI and NDWI series across the rice calendar.

The problem: An agricultural insurer deciding flood crop-loss payouts cannot visit hundreds of parcels in person. In the Mekong Delta the three-crop calendar means paddies are flooded by design for part of the year, so a single image cannot distinguish normal flooding from loss — it takes a time series.
Who it serves: Agricultural insurers assessing claims, water and irrigation agencies tracking the delta, and agri-analytics teams needing parcel-level condition data.
What I built: A live platform over one of the most intensively farmed river systems on earth: five switchable Sentinel-2 band composites served as pre-rendered tiles, with a per-parcel spectral time series held in a spatial database and charted on click.
Result: A tiled, database-backed, parcel-queryable interface over a delta that has no public parcel registry, serving instantly from static hosting. The generated NDWI series reproduces the region's published three-crop calendar, which confirms the simulation is internally consistent.
Main limitation: The imagery is real; the parcel boundaries and the per-parcel spectral values are synthetic. No public cadastre exists for the delta at parcel level, so this demonstrates an interface and a data architecture — it does not measure conditions in any actual field.

Read the full technical case study

How it works: Five Sentinel-2 SR Harmonized composites exported from Earth Engine with SCL cloud masking and a fallback composite — true colour, NDVI, NDWI, NDRE and false-colour NIR. Converted to Cloud Optimized GeoTIFF with GDAL and then to 23,245 XYZ tiles at zoom 7–13 via gdal2tiles, served from GitHub Pages so band switching is instant with no download wait, with the COGs held on AWS S3. A PostGIS schema on Supabase holds 499 parcel polygons and 4,981 spectral observations. Both are synthetic: the polygons are a grid on real province coordinates, and the values are derived from published spectral profile ranges rather than sampled per polygon from the composites, because no public cadastral registry exists for the delta. The Leaflet and Chart.js frontend gives a temporal NDVI and NDWI chart on any parcel click, plus land-use and country filters and a flood overlay.
Result: The generated NDWI series follows the delta's three-crop planting and flooding calendar — December 0.464, May 0.324, September 0.185. This is a check that the simulation is phenologically consistent, not evidence about the delta.
Limits and next steps: The analytics layer is modelled, so nothing in the per-parcel charts is an observation of a real field and no conclusion about actual crop or flood conditions is supported. The imagery layer is real and is the part that carries information. One change dominates the rest: compute zonal statistics per polygon directly from the real composites and replace the synthetic series with measured values — the tiling, schema and frontend all stay, and that single step turns this from an interface demonstration into a measurement system. After that, a real or segmented parcel layer, Sentinel-1 SAR for cloud-independent water detection, and validation against a claims or yield dataset.

Open the live platform

The rest of the log

The sprints behind the four systems above, newest first. Earlier ones are applied analysis rather than shipped software, and the UAV work at the end is where the pipeline discipline came from before it was applied at satellite scale.

Sprint 13

My_Satellite — real-time Earth observation satellite visualiser

Zero-backend web app rendering 25 real NASA, NOAA, ESA and JAXA satellites in true real-time 3D. Client-side SGP4 orbital propagation via satellite.js, everything drawn procedurally in Pixi.js with no image assets. An independent Python and skyfield pipeline refreshes TLEs on a 6-hour GitHub Actions schedule, self-throttled to CelesTrak's own usage guidance, with diff-gated commits and a heartbeat file for staleness monitoring. Five production bugs found and fixed before shipping, including an inertial-versus-Earth-fixed reference frame error in the orbital maths and three separate gimbal-lock failures in a custom trackball camera.

Python · skyfield · satellite.js · Pixi.js · Web Audio API · GitHub Actions

My_Satellite live orbital view — Live orbital view, propagated client-side from refreshed TLEs.

My_Satellite satellite index — The index of the 25 tracked NASA, NOAA, ESA and JAXA spacecraft.

Launch app

Sprint 08

Solar panel fault detection — YOLOv8n, seven fault classes

A solar operator with thousands of panels cannot inspect each one monthly. Fine-tuned YOLOv8n on 2,763 aerial RGB images across seven fault classes by transfer learning from COCO weights on a T4 GPU. Overall mAP50 0.321, strongest on Defective at 0.640, weakest on Physical Damage at 0.097 and Bird Drop at 0.149 — attributable to high intra-class visual variability and thin per-class sample counts. Training curves show clean convergence without overfitting. This is the object-localisation layer the thermal pipeline was missing.

YOLOv8 · PyTorch · transfer learning · Roboflow · Google Colab

View analysis

Sprint 07

Land cover classification — Sentinel-2 and Random Forest, Jalisco

A land-use planning agency needs to know how a region is actually being used without sending a survey team. Queried 462 Sentinel-2 L2A scenes over Jalisco through the Earth Engine Python API, built a median composite from scenes under 10% cloud across six bands, and trained a 100-tree Random Forest on GEE infrastructure against 25 georeferenced training points over known ground. The classified map resolves Lago de Chapala as water, metropolitan Guadalajara as urban and the Sierra Madre footprint as forest — the sanity check that the classifier learned geography rather than noise.

Google Earth Engine · Sentinel-2 · Random Forest · geemap · GeoTIFF

View analysis

Sprint 06

LiDAR terrain and structure detection — Utah State Capitol

A planning office needs building heights for flood modelling or clearance checks without commissioning a survey. Processed 2,515,216 classified points from USGS and OpenTopography in EPSG:26912, separated 836,431 ground returns from non-ground, rasterised both to 1 m grids as DTM and DSM, filled occlusion gaps beneath the building footprint by nearest-neighbour interpolation, then differenced them into a normalised height model independent of terrain slope. Dual-threshold detection at 2 m and 10 m captured the Capitol dome at 75.9 m above local terrain. The same differencing method transfers directly to mining stockpile volumetrics and transmission-corridor clearance.

LiDAR · laspy · DTM/DSM · USGS OpenTopography · GeoTIFF

View analysis

Sprint 05B

Solar thermal triage — severity scoring dashboard

A maintenance team that has already found dozens of overheating panels needs to know which need a technician tomorrow and which can wait a month. Built a per-panel 0–100 severity score from four signals — temperature delta above healthy baseline, hotspot area percentage, thermal gradient irregularity and a domain-reasoned defect-class risk weight — then applied it across all 20,000 images: 403 Critical, 3,700 Moderate, 5,897 Monitor, 10,000 Healthy. Shipped as a static dashboard with ironbow colorisation, live filtering, detail modals and CSV export of any active filter. Scope stated honestly: demonstrated on a public benchmark, with the spatial array-position layer pending real flight metadata.

Python · OpenCV · scikit-image · InfraredSolarModules (ICLR 2020)

Open dashboard

Sprint 05

Solar thermal inspection — hotspot detection pipeline

Ingested 20,000 real thermal drone images across 12 defect classes and built the full inspection pipeline: metadata parsing, per-image thermal statistics, class-level profiles across the whole set, and hotspot detection by 85th-percentile threshold with overlay masking. Hot-Spot-Multi ranked highest on mean intensity at 183.6 against a 150.9 baseline; Cracking scored the highest thermal gradient at 8.61, the most irregular heat distribution, consistent with a structural fracture signature.

Python · OpenCV · scikit-image · anomaly detection · Jupyter

View analysis

Sprint 04

Multispectral agriculture — Sentinel-2 vegetation indices, Jalisco

An agribusiness needs to know which parts of a large farming region are stressed without scouting it on foot. Connected to the Microsoft Planetary Computer with pystac-client and stackstac, selected the cleanest available scene at 0.002% cloud, and stacked five bands at 10 m across roughly 245 km² in EPSG:32614. Computed NDVI (mean 0.186), NDWI water stress (mean −0.254), NDRE via the red-edge band (mean 0.117) and soil-adjusted SAVI (mean 0.279), with 5.2% of valid pixels classifying as healthy vegetation above NDVI 0.4.

Sentinel-2 · Planetary Computer · stackstac · rasterio · NDVI/NDWI/NDRE/SAVI

View analysis

Sprint 03

Orthomosaic and NDVI — georeferenced aerial map

A survey or precision-agriculture client needs one measurable map of a site, not hundreds of separate photos. Processed a real 77-image aerial dataset through a full photogrammetry pipeline in WebODM and OpenDroneMap, producing a georeferenced orthomosaic in EPSG:32617 at 0.08 m/px, 4457×3355 px, covering 4.64 ha. Extracted capture positions and altitude profile from EXIF, then computed NDVI from RGB and NIR bands with rasterio: mean 0.382, 73.4% healthy vegetation.

WebODM · OpenDroneMap · rasterio · photogrammetry · GeoTIFF

View analysis

Sprints 01–02

UAV mission and failsafe validation — PX4 SITL

Where the pipeline methodology started. Before a drone is trusted with a paid mission, its autopilot has to prove in simulation that it recovers correctly from failure. Five validated tests, each with the full nav_state timeline extracted from the flight log through a pyulog and Jupyter pipeline: signal loss triggering return-to-launch mid-mission at t=268.5s across a 42-waypoint flight; GPS loss at t=30.0s with the EKF dropping to dead reckoning and a blind-land descent with zero reaction lag; battery failure injected at t=33.2s producing a 5-second loiter hold then auto-land at t=65.3s; a 1,115.2 m photogrammetric grid survey at 80 m AGL ending in autonomous safe recovery; and a 12.6-minute dual-pass transect for high-density coverage. Sprint 01 is the environment build these ran on — PX4 SITL from source on macOS arm64, dependency conflicts resolved in an isolated venv, jMAVSim rebuilt against OpenJDK 17, QGroundControl over MAVLink UDP.

PX4 v1.18 · jMAVSim · QGroundControl · pyulog · MAVLink

Signal loss GPS loss Battery Grid survey Dual pass

Stack

Grouped by capability, because what matters is that a spatial ETL system gets built — the package names underneath are interchangeable.

Spatial data engineering

ETL from raw source to queryable output, CLI tooling, coordinate-system handling.

Python · GeoPandas · Shapely · pyproj · pandas · NumPy · SciPy

Earth observation and remote sensing

Catalogue search, cloud masking, composites, spectral indices, land cover.

Google Earth Engine · Sentinel-2 · MODIS · Hansen GFC · WDPA · Planetary Computer · STAC · stackstac

Spatial databases and APIs

Schema design, spatial indexing, spatial joins, and serving the result over the wire.

PostgreSQL · PostGIS · GIST indexes · ST_Within / ST_Intersects · Supabase · REST · SQLAlchemy

Raster, LiDAR and terrain

Point cloud processing, DTM and DSM generation, flow routing, hydrological modelling.

rasterio · laspy · pysheds · WhiteboxTools · GDAL · COG · XYZ tiles · USGS / OpenTopography

Deployment and reproducibility

Scheduled ingestion, determinism gates, documented pipelines, live front ends.

Git · GitHub Actions · GitHub Pages · Docker · AWS S3 · Leaflet.js · Chart.js · Jupyter

Machine learning for aerial imagery

Object detection, transfer learning, thermal anomaly scoring, supervised classification.

PyTorch · YOLOv8 · scikit-learn · OpenCV · scikit-image · Random Forest on GEE

Background

An industrial engineer who moved into software and data engineering through sustained independent work, now focused on geospatial systems for environmental risk and decision support.

2026 – present

Geospatial data engineering — independent portfolio

Remote · self-directed

Thirteen documented sprints spanning environmental monitoring, satellite imagery analysis, spatial databases, hydrological simulation, LiDAR terrain analysis and computer vision. Four deployed platforms, two open-source engines, every result validated and publicly verifiable against its original data source.

2026 – present

Freelance web developer

Independent · remote

Delivered production websites and brand identity work for paid small-business clients in Greece and Canada, managing requirements, timelines and direct client communication end to end.

2024 – 2026

Front of house and customer service

Niko's Quality Cakes · Melbourne, Australia

Ran the full order lifecycle in a high-volume environment under tight deadlines. Identified and closed workflow gaps between customer intake and production execution, reducing rework, and implemented inventory tracking to hold stock accuracy and production continuity.

2021 – 2022

Sales, operations and logistics

La Italiana · Matrix Fitness · México

Client pipelines from enquiry through resolution, multi-location delivery coordination, and reporting practices to improve stock visibility across distribution sites. First-hand exposure to what poor data costs in physical operations.

Graduated 2022

Bachelor of Industrial Engineering

TecNM — ITSPR, México

Operations systems, process engineering, logistics, quality management and industrial automation. Where the habit of validating a system before trusting it came from.

2026

Diploma of Information Technology

Laneway Education, Melbourne

Databases, data pipelines and software systems design, taken in parallel with the sprint portfolio so each concept landed in working code rather than coursework.

What I'm looking for

Employment

Seeking early-career roles in geospatial data engineering, Earth observation, remote sensing, geospatial software and environmental data systems — ideally on a specialist team with experienced engineers ahead of me.

Across Earth observation, environmental monitoring, climate and flood risk, conservation technology, agricultural intelligence and disaster response. One technical function, several adjacent domains.

One-page CV LinkedIn GitHub

Research

Also open to research groups, postgraduate opportunities and technical collaborations in remote sensing, hydrology, climate adaptation and spatial data science.

My formal background is industrial engineering. I made the transition into software and data engineering by building the evidence in public: working systems, reproducible pipelines, documented validation and explicit limitations.

Research notes, PDF

Method, validation approach, limitations and open questions for each flagship project, written for a supervisor rather than a recruiter.

Get in touch

If you work on Earth observation, climate and flood risk, conservation technology, agricultural intelligence or disaster response, I would like to talk — about a role, a collaboration, or a research group where this work would compound. Email and LinkedIn are the fastest routes.

Email me Download the one-page CV

Email: jaemaciel.55@gmail.com
LinkedIn: jose-escobar-cid3000
GitHub: github.com/Goheist01
Based in: Mexico. Previously based in Australia. Available for international remote work and relocation.
Phone: +61 411 673 694 Australian number, reachable from Mexico
Languages: English, fluent. Español, nativo.

Geospatial data systems for environmental risk and decision support.

Four systems, end to end

Structural Triage Engine

Hydrological Terrain Simulation Engine

Amazon Deforestation Intelligence Platform

Mekong Delta Agricultural Intelligence Platform

The rest of the log

My_Satellite — real-time Earth observation satellite visualiser

Solar panel fault detection — YOLOv8n, seven fault classes

Land cover classification — Sentinel-2 and Random Forest, Jalisco

LiDAR terrain and structure detection — Utah State Capitol

Solar thermal triage — severity scoring dashboard

Solar thermal inspection — hotspot detection pipeline

Multispectral agriculture — Sentinel-2 vegetation indices, Jalisco

Orthomosaic and NDVI — georeferenced aerial map

UAV mission and failsafe validation — PX4 SITL

Stack

Spatial data engineering

Earth observation and remote sensing

Spatial databases and APIs

Raster, LiDAR and terrain

Deployment and reproducibility

Machine learning for aerial imagery

Background

Geospatial data engineering — independent portfolio

Freelance web developer

Front of house and customer service

Sales, operations and logistics

Bachelor of Industrial Engineering

Diploma of Information Technology

What I'm looking for

Employment

Research

Get in touch