sentinelhub collections not handling overlap?

[jdries]

This forum issue: https://discuss.eodc.eu/t/reduce-dimension-using-count/420/11 seems to suggest that a datacube based on sentinelhub can contain the same data twice. I believe in catalog based datacubes, there's a merging procedure in place which avoids exactly this.

[dthiex]

FYI: When you download the whole bbox (overlapping several tiles) in one request, the mosaicking parameter within the evalscript (documentation determines how the data looks (the default SIMPLE should only return 1 sample). When you do mosaicking: Tile (or download both tiles separately) you get what the forum user experienced .

[jdries]

Existing piece of code to filter out duplicate regions based on distance to edge: https://github.com/Open-EO/openeo-geotrellis-extensions/blob/develop/openeo-geotrellis/src/main/scala/org/openeo/geotrellis/layers/FileLayerProvider.scala#L341

[EmileSonneveld]

@soxofaan Can it that the issues in this forum thread are already fixed? This query (over overlapping sentinel tiles) gives an OK looking result:

{
  "process_graph": {
    "loadcollection1": {
      "process_id": "load_collection",
      "arguments": {
        "bands": [
          "B02",
          "B03",
          "B04",
          "B08",
          "CLP",
          "SCL",
          "sunAzimuthAngles"
        ],
        "id": "SENTINEL2_L2A_SENTINELHUB",
        "spatial_extent": {
          "west": -74.1226,
          "east": -73.99,
          "south": 4.4222,
          "north": 4.5444,
          "crs": "epsg:4326"
        },
        "temporal_extent": [
          "2021-01-01",
          "2021-01-31"
        ]
      }
    },
    "reducedimension1": {
      "process_id": "reduce_dimension",
      "arguments": {
        "data": {
          "from_node": "loadcollection1"
        },
        "dimension": "bands",
        "reducer": {
          "process_graph": {
            "arrayelement1": {
              "process_id": "array_element",
              "arguments": {
                "data": {
                  "from_parameter": "data"
                },
                "index": 4
              }
            },
            "divide1": {
              "process_id": "divide",
              "arguments": {
                "x": {
                  "from_node": "arrayelement1"
                },
                "y": 255
              }
            },
            "gt1": {
              "process_id": "gt",
              "arguments": {
                "x": {
                  "from_node": "divide1"
                },
                "y": 0.3
              },
              "result": true
            }
          }
        }
      }
    },
    "mask1": {
      "process_id": "mask",
      "arguments": {
        "data": {
          "from_node": "loadcollection1"
        },
        "mask": {
          "from_node": "reducedimension1"
        }
      }
    },
    "reducedimension2": {
      "process_id": "reduce_dimension",
      "arguments": {
        "data": {
          "from_node": "mask1"
        },
        "dimension": "t",
        "reducer": {
          "process_graph": {
            "count1": {
              "process_id": "count",
              "arguments": {
                "data": {
                  "from_parameter": "data"
                }
              },
              "result": true
            }
          }
        }
      },
      "result": true
    }
  }
}

[soxofaan]

@EmileSonneveld it might be that your process graph example will not suffer from the original issue of that forum post because the duplication problem might already be eliminated when you reach the count reduction. And if you look closely to that screenshot of your result, you still can see some vertical structures that might be symptoms of this bug.

Can you try the same without the reducedimension1 and mask1 nodes?

[EmileSonneveld]

I see the small vertical structures that are probably where tiles overlap, but they are not as drastic as the user noted.

Without those nodes, a plain image is returned where everything has value 6. Except band 5 has some minor noise

[soxofaan]

I reran my notebooks I used for investigating https://discuss.eodc.eu/t/reduce-dimension-using-count/420/12 and I can indeed not reproduce the problem anymore (against current "openeo.vito.be"), so I guess we can consider this issue to be fixed