Cases not currently covered by the aggergation

Overview issue listing all the remaining cases that need to be implemented in aggregation; tests need to be added for each of them.

• aggregate points by labels. See dedicated issue here: https://github.com/scverse/spatialdata/issues/209
  • subtask, handle the case in which the labels are multiscale
• aggregate labels by labels
  • subtask, handle the case in which the labels are multiscale
• aggregate shapes by labels
  • subtask, handle the case in which the labels are multiscale
• aggregate labels by shapes
  • subtask, handle the case in which the labels are multiscale
• aggregate images by shapes
  • subtask, handle the case in which the images are multiscale

Additional points to consider:

• Allow aggregation of raster with different resolution or non-overlapping areas (affine transform). To do this the strategy is to call rasterize() on all the raster elements involved into a common resolution. Non-overlapping areas are padded with 0 (background) by default by rasterize().
  • I think also the case in which two raster objects contain translations is not covered (for instance having two images with the same resolution, but with different translations/rotations, so that the overlap is actually smaller). I would wait for the new coordinate systems refactoring to be ready before implementing this.
• The 3D case needs to be handled. I would add the implementation (and a corresponding Github issue to track) in the future, but I would already add all the if-else branches in the code that lead to these cases, with NotImplementedError()

Start by reviewing the existing aggregation implementation and the dedicated points-by-labels issue (#209), then map each listed element combination and its multiscale variant. Check how rasterize() and the coordinate-systems refactoring affect differing resolutions, translations, and non-overlapping areas. Done means tests cover each supported case and 3D paths explicitly raise NotImplementedError where implementation is deferred.