Mosaic artifacts for Sentinel 3 composites


I am using openEO for the first time to retrieve Sentinel 3 SLSTR L2 LST composites of Canada. I’ve used the following code to query the collection and produce a 10 day mean composite:

datacube = conn.load_collection(
  spatial_extent={"west": -140.99778, "south": 41.6751050889, "east": -52.6480987209, "north": 83.23324},
  temporal_extent=["2020-08-01", "2020-08-10"],

timeseries = datacube.mean_time()

result = timeseries.save_result("GTiff")
job = result.create_job()

The issue that I am running into is that there appear to be some mosaic artifacts in the output? Perhaps value ranges of individual tiles are not normalized going into the mosaic, resulting in this strange tile pattern? Am I missing a key processing step that would remedy this?

Thanks in advance for any advice!

Hi @melser ,

what openEO connection URL are you using here? I haven’t seen this SENTINEL3_SLSTR_L2_LST collection before

Hi @stefaan.lippens ,

I’m connecting through:

conn = openeo.connect("")

Which yields the following response:
<Connection to ‘’ with OidcBearerAuth>

The Level 2 LST is described as an available product in the EO data overview from the Copernicus Data Space Ecosystem (see link below), and I am able to pull up a collection description using:


I came across the correct collection description (SENTINEL3_SLSTR_L2_LST) when browsing for collections on

Note that SENTINEL3_SLSTR_L2_LST is not a production ready collection. It is not listed for example with

>>> con.list_collection_ids()

It is indeed available as a “hidden” collection, but I don’t know its readiness status.

That being said, I can confirm that something is wrong with the data even without temporal reduction:

import openeo
import xarray
con = openeo.connect("").authenticate_oidc()
datacube = con.load_collection(
  spatial_extent={"west": -100, "south": 50, "east": -90, "north": 60},
  temporal_extent=["2020-08-01", "2020-08-05"],
ds = xarray.load_dataset("")
ds["LST_in:LST"].plot.imshow(col="t", col_wrap=2, vmin=-2000, vmax=10000)


I’ll see if I can get some more info on the plan/status of this collection.

(cc @jeroen.dries )

Hi @stefaan.lippens,

I was afraid that would be the case RE not being a production ready collection. Unfortunately the Sentinel 3 SLSTR Level 2 products are commonly excluded in API collections like SentinelHub.

I’m holding out hope that @jeroen.dries has some good news about upcoming availability of this collection, but would otherwise appreciate any advice on alternative pathways through which I might be able to access this dataset.

the problem is that sentinel-3 has multiple observations per day, and our current implementation just picks one of them. We will probably have to improve this to keep the original timestamps. (Screenshot of inputs for one day below.)

In general the plan was to have this available more operationally in the next 2 months, depending on how many issues we still find in testing.

Please take into account that the values have the scale of 0.002 and 290 offset:

After applying them, you should get reasonable values.
Also, it would be better if you could mask clouds with flags_in:confidence_in (I have not had a go for this one tbh!)

Just an FYI, scale and offset should now be applied automatically, so always. (This is an experimental collection, which means we are still making these kind of changes.)