The heat programme wants the July NDVI broken down by borough, on the borough polygons, for the same allocation formula the tree programme uses. The Sentinel-2 clip is in UTM zone 30N and the boroughs are in WGS 84, and the analyst before you reprojected the raster to match the polygons — with bilinear resampling, which smeared the index across the Thames. The programme wants it done the other way round.
Return one feature per borough — the borough polygon — carrying:
namendvi_mean — mean NDVI over the valid Sentinel-2 pixels inside the borough, four decimalsCompute NDVI as in the scene-level challenge (both bands > 0, float arithmetic). Reproject the borough polygons into the raster's CRS (EPSG:32630) to cut the raster; do not resample the raster. Return the boroughs in EPSG:4326, least green first.
These are where the teaching is. Read them twice.
Raster in one CRS, admin polygons in another is the normal state of a monitoring pipeline, and 'move the vectors, not the pixels' is the rule that keeps the index honest.
7 scored, 0 informational
One feature per borough
15%Carries name and ndvi_mean
15%The greenest borough's mean NDVI
15%The least green borough's mean NDVI
15%Sum of the borough means
23%Result is polygons
8%Submitted in EPSG:4326
8%