Weird projection when doing standard Sentinel2 datacube download

openEO Platform
1

Dear OpenEO forum,

I ran into the following issue when doing some straightforward Sentinel2 datacube extraction from OpenEO:

{
  "process_graph": {
    "loadcollection1": {
      "arguments": {
        "bands": [
          "B02",
          "B03",
          "B04",
          "B05",
          "B06",
          "B07",
          "B08",
          "B8A",
          "B11",
          "B12",
          "SCL",
          "CLM",
          "CLP",
          "AOT",
          "SNW",
          "dataMask"
        ],
        "id": "SENTINEL2_L2A_SENTINELHUB",
        "properties": {
          "eo:cloud_cover": {
            "process_graph": {
              "lte1": {
                "arguments": {
                  "x": {
                    "from_parameter": "value"
                  },
                  "y": 75
                },
                "process_id": "lte",
                "result": true
              }
            }
          }
        },
        "spatial_extent": {
          "crs": "EPSG:32634",
          "east": 761220,
          "north": 4979370,
          "south": 4969470,
          "west": 751320
        },
        "temporal_extent": [
          "2022-01-01",
          "2023-01-01"
        ]
      },
      "process_id": "load_collection"
    },
    "saveresult1": {
      "arguments": {
        "data": {
          "from_node": "loadcollection1"
        },
        "format": "NetCDF",
        "options": {}
      },
      "process_id": "save_result",
      "result": true
    }
  }
}

Requested EPSG is 32634 (UTM 34N which is the projection of Sentinel2 data from tile 34TGQ), but the datacube returned by openEO is actually in EPSG 4037, which seems like a local projection for Moldavia:

##### Projection
Bounding Box
[ "277 060", "4 967 690", "287 670", "4 978 300" ]
Image Dimensions
1 061 × 1 061
Code
[EPSG:4037](https://spatialreference.org/ref/epsg/4037/)

This happens for tiles 34TGQ, 34TGR, 34TGS, while requests for other tiles, generated by the same code, have the correct SRS.

Any idea what might be the problem ?

Regards,

Julien

2

Hi Julien,
I also spotted this very recently.
My theory is that these CRS’s are equivalent according to the proj library, and that it for whatever reason returns this local CRS rather than the more standardized one.
So we probably have to find a way to force the use of the proper UTM crs.

best regards,
Jeroen