MOGPR S1 - S2: Inconsistent time series on pixel level

[JanssenBrm]

As reported by Patrick:

Within parcels there is wonderfully fused time series with a clear profile,
But within the same parcel we then get these odd profiles (2nd and 4th example below) where the fusion or fitting did not work well…

Reference job ID: j-240110934dc9433791466d5d668a0df1

[JanssenBrm]

@mlubej / @GriffinBabe / @JochemV - Do you have any insights/thoughts to share on this one? These results are generated by fusing NDVI and RVI datasets from openEO through the MOGPR process.

[JanssenBrm]

After loading in the results, I can see that the resulting NDVI has some speckles (mogpr_s1_s2_results.zip, see band 2 for NDVI). The issue seems to be occurring for these speckles.

For the other pixels, the time series profile looks quite good:

For reference this is the visualization of both result bands:

NDVI (2023-01-05)

RVI (2023-01-05)

[mlubej]

Hi @JanssenBrm

Interesting issue. perhaps there is some issue with improper cloud cleaning. In any case, since the MOGPR is applied per pixel, the MOGPR optimization can yield different parameters which then affect the overall fit, this is why having a spatially-aware process could help, but this approach is often out of hands...

It might become more clear if you provide us with raw NDVI and RVI time series for the area (the whole datacube before MOGPR). Looking at the different time series might reveal the cause of the differences.

A potential issue could be the sen2corr SCL map, if it was used. Example here, where you can see an incorrect classification on the 5th of January (since it should be all clouds): https://sentinelshare.page.link/yXSQ

[Patrick1G]

thanks for creating this issue @JanssenBrm

@mlubej - I dont think this is cloud masking related, as you see also from the below examples, within a single parcel there is a pixel-level speckle and on those speckled pixels the fused time series kind of breaks together around the mean value...

[JanssenBrm]

Meanwhile, I was also able to collect the input datacubes:
https://wetransfer.com/downloads/528ef9586d278a4e2e8cb19d0de5790720240122155402/65b259?utm_campaign=TRN_TDL_05&utm_source=sendgrid&utm_medium=email&trk=TRN_TDL_05

On the topic of the cloud coverage, we currently use the mask_scl_dilation process to remove the clouds from the data before calculating the NDVI:

def _load_ndvi(connection, polygon, date):
    """
    Create an NDVI datacube based on the SENTINEL2_L2A data collection.
    :param connection: openEO connection
    :param polygon: Area of interest
    :param date:
    :return:
    """
    base_s2 = connection.load_collection(
        "SENTINEL2_L2A", spatial_extent=polygon, temporal_extent=date, bands=["B04", "B08", "SCL"]
    )
    base_s2 = base_s2.process("mask_scl_dilation", data=base_s2, scl_band_name="SCL")
    ndvi = base_s2.ndvi(red="B04", nir="B08", target_band="NDVI")
    ndvi = ndvi.filter_bands(bands=["NDVI"])
    return ndvi.mask_polygon(polygon)

This process seems to quite aggressively remove the clouds, as shown in the image below, representing one of the NDVI input timestamps:

[mlubej]

I plotted the NDVI timeseries for a group of random pixels inside the field that @patrick-griffiths has been using. The raw NDVI looks fine:

The RVI is a bit more wild

Looking at a single pixel time series it's quite jumpy

Perhaps you are using data from both ASC and DES? We've seen that using just one tends to give better results.

Could you also try rerunning the MOGPR process and testing the same pixel? Does it always give bad results? I wonder about the stability of the method here.

[JanssenBrm]

Thanks for the feedback @mlubej! I can confirm that both ascending and descending are used in the RVI. I'll test the result again with only selecting the DESC or ASC data.

[JanssenBrm]

Using one of the orbit direction seems to be yielding much better results. However, there are still some pixels that have the a strange time series profile.

[mlubej]

@JanssenBrm could you share both the input and output datacubes, so I can take a look at the specific pixels?

Or, if you have a notebook with the area and time intervals defined, you can share that as well

[JanssenBrm]

@mlubej - I've created a notebook that generates the inputs and the outputs for the specific area and time of interest. It is available on a separate branch:
https://github.com/Open-EO/FuseTS/tree/fix/120-inconsistent-timeseries/notebooks/MOGPR%20S1%20S2%20Testing

[JanssenBrm]

I'm also generating the results, so I'll link them once they are ready.

[JanssenBrm]

The inputs are available at https://we.tl/t-vZPVwy9rqd

[JanssenBrm]

I've also collected the outputs (sorry for the late response):
https://wetransfer.com/downloads/904b6f42422d956424b3957be087980320240126150631/fc6f0f80fdd25e56026fcda284b78c6620240126150631/a35c7c?trk=TRN_TDL_01&utm_campaign=TRN_TDL_01&utm_medium=email&utm_source=sendgrid

[Patrick1G]

@mlubej would it be possible to do a test run with fixed hyperparameters per parcel or simply per 100x100px grid?

This would give us an idea of the within parcel heterogeneity is due to pixel level hyperparameters...