.plan-26-38: Near, far, wherever you are, Tessera infers on

DClimate released global wall-to-wall v1.1 Tessera embeddings on AWS covering 2017-2025, the first complete embeddings coverage across so many years for any Tessera model, funded by an AWS Open Data grant. dClimate independently reimplemented the Tessera inference engine for high-performance cloud processing, and Mark Elvers and the project lead are integrating the new embeddings into GeoTessera. Cross-validation found the AWS Element 84 Earth Search and Microsoft Planetary Computer Sentinel-2 L2A archives differ, including a reflectance offset that, if mishandled, makes every pixel silently too bright or too dark by the same amount.

The big news this week is that Tessera community member dClimate announced https://blog.dclimate.net/mapping-a-changing-planet-tesseras-global-earth-observation-embeddings-now-openly-available-on-aws/ that global wall-to-wall v1.1 Tessera https://anil.recoil.org/projects/tessera embeddings are now available on AWS for 2017-2025 This marks the first time that we have complete embeddings coverage for so many years for any of our models, which is a giant milestone for the project. This inference was possible thanks to a grant that dClimate received from AWS Open Data https://aws.amazon.com/opendata/ . This also highlights just how cool working in the open is, since dClimate reimplemented the Tessera inference engine to specialise it to high-performance processing on cloud infras. We've been exchanging tips since May on our Zulip https://eeg.zulipchat.com/ narrow/channel/587016-Embeddings-Generation/topic/Open.20Source.20cloud.20TESSERA.20repo/with/625660416 and clarifying various details in their codebase https://github.com/dClimate/tessera-embeddings . Having an independent validation of our inference methods is as much of a big deal as the embeddings themselves, given the importance of these to such a variety of downstream tasks https://anil.recoil.org/notes/geotessera-a-year-on from which important policy decisions may be driven. Mark Elvers https://www.tunbury.org/ and I have been working this week on integrating all this smoothly into GeoTessera https://anil.recoil.org/notes/geotessera-python so that our users can take advantage of the new embeddings. Here are some of my working notes on the topic. In brief: cross-validating the two v1.1 runs https://anil.recoil.org/ cross-validating-the-new-v11-embeddings-and-sources , checking their coverage https://anil.recoil.org/ checking-equivalent-coverage-across-the-two , converting Icechunk to Zarr v3 https://anil.recoil.org/ converting-from-icechunk-to-zarr-v3 and weaving the matrix into GeoTessera https://anil.recoil.org/ weaving-the-matrix-of-embeddings-into-a-client , then threatened species near you https://anil.recoil.org/ dash-of-life-finds-threatened-species-near-you and some fun photos https://anil.recoil.org/ fun-photos . The first thing we did was to cross-validate the embeddings to make sure there weren't big differences in performance. One notable change resulting from the inference mechanism running on Amazon is that they switched to a slightly different satellite data source. While both are derived from the same ESA Sentinel-2 L2A products https://sentiwiki.copernicus.eu/web/s2-products , they aren't quite identical. On AWS, Element 84 runs " Earth Search https://element84.com/earth-search/ " over its own cloud-optimised GeoTIFFs https://registry.opendata.aws/sentinel-2-l2a-cogs/ , whereas the Planetary Computer https://planetarycomputer.microsoft.com/dataset/sentinel-2-l2a maintains its own archive and until mid-2024 ran Sen2Cor directly https://github.com/microsoft/PlanetaryComputer/discussions/369 to produce the L2A data. The inventories therefore differ subtly; e.g. one user found ~98k scenes on Element 84 vs ~76k on MPC https://github.com/microsoft/PlanetaryComputer/discussions/371 for the same UK fields and dates. The data formats also need different handling due to encoding differences. For example, ESA adds a +1000 offset to every reflectance value so that -ve reflectance can be represented. However, AWS removes this offset in the Element84 dataset, but MPC serves the values raw. dClimate found that https://github.com/dClimate/tessera-embeddings/blob/main/context docs/decisions/020-boa-offset-applies-to-every-valid-dn.md getting it wrong makes every pixel silently too bright or too dark by the same amount In order to test this all, we did a few lightweight tests. Our usual 'go to' has been requesting James G. C. Ball https://patball1.github.io to run his Trentino tree species mapping https://anil.recoil.org/papers/2026-tessera-trentino but he was on a well deserved vacation this week. So instead Mark Elvers https://www.tunbury.org/ used the ESA WorldCover map https://esa-worldcover.org/en to label a 100m grid over Cayenne, and then used 80% of the points to fit a linear classifier and predict classes. Both performed identically. Then Sadiq Jaffer https://toao.com ran his tiny solar farm segmentation model https://toao.com/blog/earth-observation-budget-solar-farms-tiny-model and also found equivalent performance. However, one important finding https://eeg.zulipchat.com/ narrow/channel/527258-Tessera/topic/geotessera.200.2E11.20being.20prepared/near/625758530 from Sadiq is that we cannot use the differently inferred v1.1 embeddings in the same analysis, since both were inferred from different sources: | train source | test source | IoU | Dice | Precision | Recall | |---|---|---|---|---|---| | cambridge | cambridge | 0.600 ± 0.004 | 0.750 | 0.632 | 0.922 | | dclimate | dclimate | 0.616 ± 0.010 | 0.763 | 0.642 | 0.941 | | cambridge | dclimate | 0.493 ± 0.047 | 0.659 | 0.535 | 0.903 | | dclimate | cambridge | 0.540 ± 0.019 | 0.701 | 0.627 | 0.819 | Sadiq's checks above show that each set of v1.1 embeddings works equally well on its own, but a model trained on one and tested on the other loses between 0.06 and 0.11 IoU, and its variance rises sharply. Although both runs used the same v1.1 model, the embeddings are computed from different copies of the input imagery, with different scene inventories and offset handling. We will therefore keep 1.1-cam and 1.1-dclimate as separate variants in GeoTessera, and you should be careful to pick one and stick with it for any given analysis but swapping them wholesale should make no practical difference . One persistent problem with most GeoFMs is that some areas of the world have many fewer observations than others, and so the quality of inference can vary if the number of annual satellite observations is very low. Our Tessera v1 paper https://anil.recoil.org/papers/2025-tessera ran ablations to show that performance dropped sharply if n<10 for S2. The dClimate folks decided to take the route of not generating embeddings for those areas for which we have low coverage, to keep a consistent quality bar. Robert showed https://eeg.zulipchat.com/ narrow/channel/587016-Embeddings-Generation/topic/missing.20dclimate.20v1.2E1.20embeddings/near/625739045 that this is only a very small percentage of areas, so most users should hopefully never notice. Kristian Bodolai from Space Intelligence started a discussion https://github.com/ucam-eo/geotessera/issues/424 about what to do with these embeddings, and apparently they are still getting excellent results doing palm oil classification https://eeg.zulipchat.com/ narrow/channel/587016-Embeddings-Generation/topic/missing.20dclimate.20v1.2E1.20embeddings/near/625756328 even in those low coverage areas, possibly thanks to the S1 coverage still holding up the quality of the inferred embedding. We'll make more progress on this next week, and I hope to reach consensus on what to do. Even though the 'Cambridge embeddings' do cover those areas, remember that we can't mix them safely in the same task. The Amazon Sustainability Data Initiative https://sustainabilityexchange.amazon.com/ and the AWS Open Data Sponsorship Program https://opendata.aws/ that sponsored the inference also cover the hosting of the result, which dClimate publish as an Icechunk https://icechunk.io repository. Icechunk adds database-style transactions to Zarr, which matters at this scale https://github.com/dClimate/tessera-embeddings/blob/main/docs/global-store.md as a truncated write to a normal Zarr hierarchy on object storage will be undetectable. Mark Elvers https://www.tunbury.org/ and I have been converting it over to plain Zarr v3 on Source Coop https://source.coop/tessera/tessera to allow non-Icechunk clients like my OCaml code to access the data. Mark has been running the conversion on AWS Fargate Spot as we did before https://www.tunbury.org/2026/09/21/week-38/ icechunk-to-zarr-conversion , so it all runs as containers that have been churning through the world at around 113 GB/minute, and is about two-thirds done at the time of writing. One possible screwup I might have made during this conversion is picking too small a chunk size for the Zarr. The Source Coop stores keep the 1,128,32,32 inner chunks inside 4096×4096 shards that I chose back in March https://anil.recoil.org/notes/tessera-embeddings-convention . The dClimate store uses much larger 256×256 inner chunks inside 2048×2048 shards, and so a single pixel fetch is about 8.65 MB of traffic https://github.com/dClimate/tessera-embeddings/blob/main/docs/global-store.md what-a-read-costs . In practice, scattered point lookups are expensive in the dClimate store, but windowed reads are more expensive per pixel in my Source Coop store. There's therefore a tradeoff between streaming into a browser and streaming for the cloud, which we've been discussing on Zulip https://eeg.zulipchat.com/ narrow/channel/587016-Embeddings-Generation/topic/zarr.20v3.20chunk.20sizes/near/625720009 . I suspect we'll just settle on different chunk sizes for the Icechunk and Zarr v3 stores in the end to accommodate different clients. Source Coop feels more appropriate for the mobile use case due to the Cloudflare edge caching it provides. More research needed I've also been teaching https://github.com/ucam-eo/geotessera/pull/422 GeoTessera to handle this matrix of models. In the upcoming version, the v1.1 becomes the default model now that we have so much coverage. While the Zarr conversion is ongoing, streamed reads go straight to the dClimate Icechunk store. | version | variant | format and home | years | status | |---|---|---|---|---| | 1.0 | vultr | NPY + Zarr on source.coop https://data.source.coop/tessera/tessera npy/v1/ , zarr/v1 | 2017–2025 | First production line | | 1.1 | cambridge | NPY + Zarr on source.coop npy/v1.1-cam/ , zarr/v1.1 | 2015–2025 | Cambridge deployment that's the NPY-tile default, but thinner coverage | | 1.1 | dclimate | Icechunk on AWS S3 | 2017–2025 | The new global run and the streamed default; no NPY tiles at all | | 2.0 | 2B-L~beta1 | NPY + Zarr on source.coop v2-2B-L~beta1/ | 2017–2025 | v2 beta, 2B parameters, L size. Experimental | | 2.0 | 2B-L~beta2 | NPY + Zarr on source.coop v2-2B-L~beta2/ | 2017–2025 | Second v2 beta run. Experimental but poor temporal stability | Michael Dales https://mynameismwd.org also reported occasionally unusable source.coop performance https://github.com/ucam-eo/geotessera/issues/417 , which I'm tracing to some possible instability in the Source Coop Rust proxy. More on this when I investigate next week too Shane Weisz https://shaneweisz.com 's Dash of Life https://dashoflife.org from our biodiversity mapping project https://anil.recoil.org/projects/enki now has a near me page https://dashoflife.org/near-me that lists the threatened species records around a point, along with the corresponding threats that their IUCN Red List https://www.iucnredlist.org assessments cite. I added a button to zoom straight into your current location PR 555 https://github.com/shaneweisz/redlist-dashboard/pull/555 so you can learn more about your local region with a quick browser bookmark. Within 10 km of Cambridge, the list shows the common pochard https://en.wikipedia.org/wiki/Common pochard , horse chestnut https://en.wikipedia.org/wiki/Aesculus hippocastanum and European turtle dove https://en.wikipedia.org/wiki/European turtle dove as vulnerable, the European rabbit https://en.wikipedia.org/wiki/European rabbit as endangered, and the European eel https://en.wikipedia.org/wiki/European eel as critically endangered Cyrus Omar https://web.eecs.umich.edu/~comar/ has made his way to Cambridge to start his sabbatical, and Carl Henrik Ek http://carlhenrik.com/ and I rolled out the red carpet at the Mill for him And I enjoyed seeing some gorgeous bikes and races at the Goodwood Revival https://www.goodwood.com/motorsport/goodwood-revival/ , making the most of the September good weather