[main] Feature: SpatialData I/O support

[enric-bazz]

This PR ports the changes from the v2-incremental branch into main, primarily to introduce SpatialData I/O support.

Key features

• SpatialData support

  • Accepts SpatialData objects as input, including data read from Zarr stores

  • Produces output as a Zarr-backed SpatialData object

  • Output is controlled via the save_spatialdata flag (default: true), consistent with existing AnnData behavior

  • Supports configurable boundary construction methods:

    • convex_hull
    • delaunay

• 3D segmentation

  • Enabled when a valid z coordinate is present and the feature is activated (default: false)

• Quality value (QV) filtering

  • Default threshold: QV > 20

Provenance of changes

Most of the implementation is derived and adapted from prior changes to the v2-incremental branch, namely:

• commit: 5c4cc5a

• prior PRs:

  • [v2-incremental] Fix regex filter and table parsing on spatialdata I/O #29
  • Debugged spatialdata writer with refactored shapes #28

[Tobiaspk]

Hi @enric-bazz thanks for the PR. These are good features, but the scope is too large to review in a single PR (really helpful to get them below 400 lines per PR). I'd suggest to split it into smaller PRs grouped by functionality, such as:

• 3d support
• SpatialData support (ideally part of preprocessor.py; XeniumPreprocessor could be a good reference)
• Custom qv parameter
• Lazy loading and variable exports

For lazy loading, I'd suggest to only use where truly needed. Otherwise it adds lots of complexity overhead. For example StandardBoundaryFields loads quickly and doesn’t need lazy loading. there's also some duplicated logic between get_preprocess and preprocess for example. This can be simplified too.

Thanks!