Introducing 𝐆𝐞𝐞-𝐋𝐮𝐦𝐚: Turning Plain-English Prompts Into Satellite Maps

Why I built an AI agent that speaks fluent Google Earth Engine, so you don’t have to

A year ago, I wanted something simple: an NDVI map of a district I cared about for a specific three-month window, with the clouds removed. Nothing exotic. The kind of map a journalist, a student, or a local environmental officer might need in five minutes.

Getting it took most of an afternoon.

Doing it meant knowing which Google Earth Engine collection actually had cloud-free Sentinel-2 imagery for that window, which band combination NDVI needed, how to bitmask the QA60 band to mask clouds, how to filter by an administrative boundary that wasn’t in any dataset I already had loaded, and then how to turn the resulting raster into something that looked like an actual map, not just a colourful rectangle with no scale bar, no north arrow, and no legend.

And that last step, turning the raster into a map, is a separate marathon of its own. Earth Engine doesn’t hand you a finished map; it hands you a layer. To get something you can actually put in a report, you export the result to a raster or vector format, kick off the task, and wait a few minutes if you’re lucky or a lot longer for a large area at full resolution, then fish the file out of Google Drive. Only then does the real cartography begin: open it in QGIS or ArcGIS, fix the symbology and stretch the colour ramp by hand, and build a print layout where you manually drop in the scale bar, the north arrow, the legend, and the title; nudge each one into position; and finally export a PNG. That’s a second piece of software and a second skill set entirely — and you run the whole ritual again for every single map.

For me, none of that is hard. After more than three years doing remote sensing, masking QA60, tracking down the right boundary, or wiring up a print layout is a reflex, muscle memory I don’t even think about anymore. But that’s exactly the trap: it’s only easy because I already paid for it, one hard-won detail at a time. For someone who genuinely doesn’t know this stack, every single step is a wall, and it’s the same wall, over and over, for every new question. Soil moisture, land cover, nighttime lights, burnt area, and methane concentration: each one comes with its own dataset quirks, band names, scale factors, and cloud-masking logic. Earth Engine is extraordinary. The distance between “I have a question about a place” and “I have an answer I can show someone” is not vast — unless you’ve already spent years closing it yourself.

So I built 𝐆𝐞𝐞-𝐋𝐮𝐦𝐚 to close that distance.

What Gee-Luma actually does

EarthLens is a Streamlit application that takes an actual sentence, typed in plain English, and turns it into a finished, publication-style map.

You type something like:

“NDVI map for Sri Lanka using Sentinel-2, last 3 months, with cloud removal”

or

“Sentinel-1 SAR VV/VH RGB composite over Bangladesh flood 2022”

and EarthLens figures out the rest: which satellite collection to pull from, which bands to use, how to scale and mask them, where the boundary is, and how to lay all of it out as a map with a title, a scale bar, a north arrow, and a proper legend — ready to download as a PNG.

And NDVI is just the example I keep reaching for because it’s where I started. Gee-Luma isn’t an NDVI tool — it isn’t even an “index” tool. It speaks to the whole Earth Engine catalog: hundreds of spectral indices and dozens of full datasets, from optical and radar imagery to elevation, climate, air quality, population, and land cover. If the data lives in Earth Engine, the goal is for a plain sentence to be enough to turn it into a map. NDVI is simply the door I walked in through.

The part that makes this possible isn’t a single clever trick. It’s a small AI agent sitting on top of a fairly deep knowledge base of how dozens of real Earth Engine datasets actually behave, wired into a deterministic pipeline that does the heavy GEE work.

What a single sentence can trigger

Under that one text box is a surprising amount of range:

• Spectral indices. Through the spyndex library, EarthLens can compute over 200 spectral indices — NDVI, EVI, NDWI, NBR, BAIS2, kNDVI, and many more specialized ones — across whichever sensor actually has the right bands for the job.
• Multi-sensor support. Sentinel-2, Landsat 5 through 9, MODIS, Sentinel-1 SAR, ALOS PALSAR, Sentinel-5P, plus static datasets like SRTM, Copernicus DEM, ESA WorldCover, and Hansen Global Forest Change.
• Map types beyond spectral math. True-color and false-color composites, SAR RGB, elevation, slope, aspect, hillshade, land cover classification, land surface temperature, nighttime lights, precipitation, air temperature, soil moisture, tree cover, forest loss, biomass, canopy height, fire detection, NO₂/CO/aerosol/CH₄/SO₂ air quality, population density, and evapotranspiration.
• Automatic cloud handling. EarthLens detects cloud-removal intent directly from your wording (“cloud-free,” “remove clouds,” “mask clouds”) and applies the correct per-sensor masking logic — QA60 bitmasking for Sentinel-2, QA_PIXEL for Landsat, state flags for MODIS, quality flags for VIIRS.
• Place names that just work. Type a country, a province, or a district, and EarthLens detects which administrative level you mean and pulls the matching boundary automatically. You can also upload your own GeoJSON area of interest in any coordinate system, and it reprojects to WGS-84 on the fly.

The point of all that breadth is that the same sentence-to-map promise holds no matter which corner of the catalog you reach into. You shouldn’t have to relearn the workflow just because you switched from vegetation to air quality.

Built to get the map right, not just a map

The part I’m most particular about is accuracy, because a wrong map that looks confident is worse than no map at all.

EarthLens follows a strict decision order: if a dataset already has the value you want as a precomputed band, MODIS already ships NDVI, for instance, it uses that band directly rather than recomputing it from raw reflectance. Only when no precomputed band exists does it fall back to computing the index from spectral bands via spyndex. This sounds like a small detail, but it’s the difference between trusting the dataset’s own science team and re-deriving something yourself with extra room for error.

The same care shows up elsewhere: scale factors and offsets are applied per sensor; static datasets like DEMs skip date filtering entirely instead of returning empty collections; and even datasets that aren’t in the built-in catalog get introspected at request time so the app can detect their actual band names rather than guessing.

A map that actually looks like a map

The output isn’t a raw raster dump. EarthLens renders a full cartographic layout, a centred title, a north arrow, a scale bar in kilometres sized dynamically to the region’s actual width, and either a continuous colour bar or a discrete land-cover legend, depending on what you asked for. RGB composites get their own red/green/blue swatch key. Everything ships as a single downloadable PNG, named for the index, region, and year.

In other words, the entire export-to-Drive-then-rebuild-it-in-QGIS marathon I described at the start collapses into the few seconds it takes to read your sentence, and you didn’t open a second piece of software to get there.

Who this is for

I built EarthLens for the version of myself from that afternoon, someone who knows what they want to see but doesn’t want the Earth Engine documentation to be the thing standing between the question and the answer. That covers a lot of people: students learning remote sensing, NGO field teams who need a quick visual for a report, journalists covering a flood or a wildfire, local government offices without a dedicated GIS analyst, or just the geographically curious.

What’s coming next

This series delivers a technical breakdown of the EarthLens architecture, analysing its natural-language agent for dynamic sensor-band selection alongside its cloud-masking and boundary-detection pipelines. We will evaluate the core engineering workflows of the spectral-index engine and cartographic renderer, highlighting optimization lessons learned from data pipeline failures. The series concludes with an end-to-end implementation walkthrough and an analysis of the system’s developmental roadmap.