What it does. Draw a field, pick a cloud-free Sentinel‑2 pass, and get the vegetation index over it: the picture, the numbers behind the picture, and a ranked list of the patches that are furthest below the field’s own baseline — with a walking route between them and an export your handheld or tractor display will open.
Your browser does all of it. It asks the public Sentinel‑2 catalogue which scenes cover the outline, pulls only the tiles it needs out of the archive on AWS with HTTP byte‑range requests, computes the index on the scene’s own UTM grid, and does the statistics and the patch-finding here on your machine.
Who sees the request. Element84’s
earth-search.aws.element84.com sees the coordinates of the box
you search, because that is the query. The AWS Open Data bucket
sentinel-cogs sees which tiles and which byte ranges you read,
which is a coarse version of the same thing. OpenStreetMap sees the map tiles
you scroll over. My server sees nothing, because there is no
server. There is no proxy in the path and there will not be one: a
proxy would put every visitor’s field boundary in a log, and avoiding
that is the entire reason this is built the way it is. Saved fields go to
localStorage on this device and are never transmitted.
It is a preview, and here is what that means. The desktop tool does all of the following and this page does none of it: change maps between two dates, season curves across a whole growing year, persistence of a patch across successive passes, whole-farm checks over every saved field at once, farm profiles, place-name search, farm-website lookup, importing your own GeoTIFF, and downloading the index raster as a GeoTIFF in the scene’s native CRS. What is here is one date, one index, one AOI.
Resolution, and why the number moves. Sentinel‑2 red and near-infrared are 10 m, but a whole 10 m tile is a large download for a look at one field, so this page walks down the COG’s overview ladder and may read the 20 m or 40 m level instead. It prints which level it used next to every result. This is not merely a blurrier picture: the overviews average the raw band values, and NDVI of averaged reflectance is not the average of NDVI, because the ratio is nonlinear. A coarse level therefore gives different numbers, not softer ones — mixed pixels at a field edge pull hardest. Read at native 10 m if the number is the point.
How closely it matches the desktop tool, in numbers. The
whole pipeline is diffed against the Python end to end, on real scenes:
6,970,025 pixels bit-identical across four AOI-and-index combinations,
52 statistics bit-identical, and the ten ranked problem areas coming
out in the same order with the same acreages. Areas and walking
distances are computed on the WGS84 ellipsoid and agree with the desktop's
pyproj to about 4×10−10.
Two things do not match exactly, and this is the whole list. The display warp agrees with GDAL to rms 0.0009 NDVI with no pixel differing by more than 0.0031 — and every statistic in the panel is computed on the native array before any warp, so that affects the picture and nothing you read. And the pin dropped inside a problem area is placed by our own port of the interior-point algorithm rather than GEOS's: on two of forty patches it landed 5 cm outside the outline it belongs to.