geotrellis.raster.GeoAttrsError: invalid cols: 0

[EmileSonneveld]

Kristof encountered this error:

py4j.protocol.Py4JJavaError: An error occurred while calling o2489.mergeSpatialCubes.
: geotrellis.raster.GeoAttrsError: invalid cols: 0
	at geotrellis.raster.GridExtent.<init>(GridExtent.scala:45)
	at geotrellis.raster.GridExtent.<init>(GridExtent.scala:58)
	at geotrellis.raster.reproject.ReprojectRasterExtent$.apply(ReprojectRasterExtent.scala:71)
	at geotrellis.raster.reproject.ReprojectRasterExtent$.apply(ReprojectRasterExtent.scala:82)
	at geotrellis.raster.reproject.ReprojectRasterExtent$.apply(ReprojectRasterExtent.scala:86)
	at org.openeo.geotrellis.reproject.TileRDDReproject$.apply(TileRDDReproject.scala:73)
	at org.openeo.geotrellis.reproject.TileRDDReproject$.apply(TileRDDReproject.scala:321)
	at org.openeo.geotrellis.OpenEOProcesses.resampleCubeSpatial_spatial(OpenEOProcesses.scala:877)
	at org.openeo.geotrellis.OpenEOProcesses.mergeSpatialCubes(OpenEOProcesses.scala:931)

j-250106ead7734ec7a4d913bd3b08dcf1

This can be reproduced with a smaller process graph:

{
  "process_graph": {
    "filter1": {
      "arguments": {
        "data": {"from_node": "resample1"},
        "geometries": {
          "features": [
            {
              "geometry": {
                "coordinates": [
                  [
                    [-120.550792, 71.835099],
                    [-120.550792, 71.834899],
                    [-120.550992, 71.834899],
                    [-120.550992, 71.835099],
                    [-120.550792, 71.835099]
                  ]
                ],
                "type": "Polygon"
              },
              "id": "0",
              "properties": {},
              "type": "Feature"
            }
          ],
          "type": "FeatureCollection"
        }
      },
      "process_id": "filter_spatial",
      "result": true
    },
    "loadcollection4": {
      "arguments": {
        "bands": ["DEM"],
        "id": "COPERNICUS_30",
        "spatial_extent": null,
        "temporal_extent": null
      },
      "process_id": "load_collection"
    },
    "loadstac1": {
      "arguments": {
        "bands": ["Slope"],
        "url": "https://stac.openeo.vito.be/collections/COPERNICUS30_DEM_SLOPE"
      },
      "process_id": "load_stac"
    },
    "reducedimension2": {
      "arguments": {
        "data": {"from_node": "loadcollection4"},
        "dimension": "t",
        "reducer": {
          "process_graph": {
            "min2": {
              "arguments": {"data": {"from_parameter": "data"}},
              "process_id": "min",
              "result": true
            }
          }
        }
      },
      "process_id": "reduce_dimension"
    },
    "resample1": {
      "arguments": {
        "data": {"from_node": "reducedimension2"},
        "target": {"from_node": "loadstac1"}
      },
      "process_id": "resample_cube_spatial"
    }
  }
}

[jdries]

Note that it's important to evaluate this on staging, which already has some fixes for global extent.
However, looking at the minimal example, this issue heavily depends on this one:
Open-EO/openeo-python-driver#348

[jdries]

@EmileSonneveld as the 'GeoAttrsError' is entirely useless, I propose to put a try catch in place that converts it to an exception with a message that actually prints the relevant arguments, allowing to much more easily spot the actual problem.

[jdries]

We now get an error with more info:

java.lang.IllegalStateException: Unexpected error during resample_cube_spatial or merge_cubes of a spatial cube (null) , resampling from: EPSG:4326 / LayoutDefinition(Extent(-120.550992, 71.82628788888888, -120.5421031111111, 71.83517677777778),CellSize(2.777777777778212E-4,2.777777777778212E-4),1x1 tiles,32x32 pixels) to LayoutDefinition(Extent(585180.0, 7971640.0, 585820.0, 7972280.0),CellSize(20.0,20.0),1x1 tiles,32x32 pixels) / EPSG:32610

[jdries]

The trigger seems to be a very small area in high northern latitudes (so 'unstable' region for EPSG:4326), which is reprojected into utm.

It's probably the 'reduce_dimension' process that blocks resampling from happening at load time, which might avoid the issue.

[jdries]

We can now reproduce in geotrellis, it looks like the cube extent is smaller than a single pixel, hence the issue:

val layout = LayoutDefinition(RasterExtent(Extent(-120.550992, 71.82628788888888, -120.5421031111111, 71.83517677777778),32,32),32,32)
    val extent = Extent(-120.550992, 71.834899, -120.550792, 71.835099)
    val sourceDataGridExtent = layout.createAlignedGridExtent(extent)
    ReprojectRasterExtent(sourceDataGridExtent, LatLng, CRS.fromEpsgCode(32610))

[jdries]

Geotrellis rounds down, and as a result the extent 'collapses' into 0 pixels, probably also caused by the high latitude.

[jdries]

So this is what happens: DEM is specified in EPSG:4326, with a specific resolution in degrees, roughly corresponding to 30m. At high latitudes, the conversion of degrees to meters results in a pixel size less than 15m, and the datacube 'collapses' into having 0 pixels.
It would have been nicer of geotrellis to retain at least 1 pixel.

[jdries]

I logged the Geotrellis issue:
locationtech/geotrellis#3559

[jdries]

The fix seems to work on staging.