Extracting Satellite Data at Points of Interest: NDVI, Temperature & More
You have a list of locations — farms, stores, weather stations, project sites — and you want to know what satellites saw there over time: how green the vegetation was, how hot the surface got, how much rain fell, how polluted the air was. This is called point-of-interest (POI) extraction, and done right, it turns terabytes of satellite imagery into a small CSV that answers your actual question.
Why extract at points instead of downloading imagery?
A single year of Sentinel-2 imagery over a mid-sized region is over 100 GB. If your question is "what was the NDVI at these 40 farms every week", you need about 100,000 numbers — a 2 MB CSV. Extracting at points of interest skips the storage problem, the processing problem, and most of the GIS learning curve.
What can you extract? Popular variables by use case
| Use case | Variable | Source | Resolution |
|---|---|---|---|
| Crop & vegetation health | NDVI, EVI, LAI | Sentinel-2, MODIS | 10 m–250 m |
| Heat & urban climate | Land surface temperature | Landsat, MODIS, Sentinel-3 | 30 m–1 km |
| Rainfall & drought | Precipitation, SPI | CHIRPS, ERA5 | ~5–30 km |
| Air quality & ESG | NO₂, CO, CH₄, aerosols | Sentinel-5P | ~5.5 km |
| Soil moisture | Surface soil moisture | Sentinel-1, SMAP | ~10 m–9 km |
| Flooding & water extent | Water masks | Sentinel-1/2 | 10 m |
Points vs. polygons: which do you need?
A point gives you the value of the single pixel containing your coordinate. That's fine for coarse data (rainfall, air quality) where pixels are kilometres wide. For high-resolution data over fields or sites, a polygon (or a buffer around the point) is better: you get the average across the whole field, which is far less noisy than one 10 m pixel, and statistics like min, max, and standard deviation come free.
The extraction workflow
- Prepare your locations. A CSV with
id, lat, loncolumns, or a GeoJSON/shapefile for field boundaries. Double-check the coordinate order — lon/lat vs lat/lon swaps are the classic bug. - Choose sources per variable. Match resolution and revisit frequency to the question (see table above).
- Apply quality filtering. Cloud-mask optical data, filter poor-quality retrievals, and record how much data was dropped per location per period.
- Aggregate sensibly. Decide the temporal step (daily, weekly, monthly) and the spatial statistic (mean, median, percentile) before extracting — not after.
- Export long-format CSV. One row per location per date, with a quality column. Details in our guide to converting satellite data to CSV.
Common mistakes in POI extraction
- Trusting single pixels. Registration error means a coordinate can land one pixel off. Buffer and average.
- Comparing across sensors casually. Sentinel-2 NDVI and MODIS NDVI are not interchangeable — band definitions and resolutions differ.
- Ignoring gaps. In cloudy regions, optical time series can lose most of the winter. A CSV without a quality column hides this and skews trends.
- Mixing coordinate systems. Extracting WGS84 points against a UTM raster without transforming puts every value in the wrong place.
DIY or done for you?
If you're comfortable with Python or Google Earth Engine, our CSV conversion guide covers the tooling. If you'd rather spend the time on analysis instead of pipelines, that's exactly what we're for.
Send us your points, get back a CSV. Coordinates, addresses, or field boundaries in — cloud-masked, quality-flagged time series out. Request your data →