representing spatial AIRR data in anndata/spatialdata

In https://github.com/scverse/scirpy/issues/583 there's a proposal how to deal with spot-based spatial data. However, the spatial world has moved on and single-cell/subcellular resolution is the present and the future of spatial assays. This is good for us, because it doesn't require any changes to the scirpy receptor model and data structure which are built around single cells.

However, we still need to decide how to align the AIRR data structure with spatial information.

status quo

scirpy

• scirpy objects are AnnData objects with receptor information stored in .obsm["airr"].
• For multimodal data (AIRR + gene expression), the preferred way of handling this is a MuData object with two slots ("gex" and "airr"). Each slot is a separate AnnData object with overlapping, but not necessarily identical, observations.
• It is also supported to keep both, gene expression and AIRR data, in a single AnnData object with gene expression data in .X/.layers and AIRR data in .obsm["airr"]

SpatialData

• SpatialData is the go-to container in scverse for anything with spatial information. It builds on the open NGFF standard and is built to support any type of spatial information (hi-res images, labels (annotation), shapes (e.g. cells), points (e.g. transcripts with subcellular resolution).
• Non-spatial information related to shapes is stored in one or multiple AnnData objects in .tables.
• SpatialData does not support MuData (https://github.com/scverse/spatialdata/issues/1085), and it won't anytime soon, but it supports multiple tables.

Spatial AnnData

• 'spatial AnnData' is not an official format, but it is a convention built by squidpy which predates SpatialData
• Essentially, this is a standard AnnData object, with coordinates for each cell stored in .obsm["spatial"] and images stored in .uns.
• It is considered a "legacy" format, however the argument has been made that this simpler representation compared to SpatialData is all one needs for most spatial analyses that operate on coordinates (rather than the raw images) and it should exist in addition to SpatialData.
• squidpy by now supports SpatialData, but it will anyway convert the object to the anndata representation internally.
• There seems to be a consensus now that the spatialdata.tables objects will contain shape centroid coordinates in .obsm such that the simpler use cases can operate on the AnnData object in spatialdata.table directly.

moving forward

• For AIRR data only, it seems a straightforward solution could be to add an AnnData object with .obsm["airr"] to spatialdata.tables. In combination with .obsm["spatial"] it can be analyzed in squidpy and we can build our own, AIRR-specific spatial analysis functions in scirpy on top of that.

multimodal data

The question is how to represent multimodal (gex + airr) data due to the lack of MuData support in SpatialData. One option would be to simply add the .obsm["airr"] on top of a single AnnData object in .tables. Another option would be to use a separate object in .tables["airr"].

• functions like scirpy.tl.clonotype_modularity that actually use both GEX and AIRR data can't deal with two separate AnnData objects right now.
• We could build a MuData object from SpatialData mdata = MuData({"airr": sdata.tables["airr"], "gex": sdata.tables["gex"]}), but this probably doesn't keep references intact, such that any changes would have to be written back to SpatialData object manually.
• We could make scirpy accept a SpatialDatadata object in addition to AnnData and MuData. However, this would add a lot of complexity to all function signatures (elements_to_coordinate_systems, table_key, library_key). Also accessing elements from different modalities (e.g. gex:connectivities) as possible with MuData does not work.

--> I believe it is easiest, at least initially, to work with a single AnnData object with both GEX and AIRR data in the context of SpatialData. We can also explore how to pull out different .tables into a MuData object and how to synchronize changes back to SpatialData.

@timtreis @LucaMarconato any thought on this? Is there already a draft for the "spatial AnnData" spec you [have been discussing on Zulip](#core team > Single-cell and spatial day Basel @ 💬)?

Start with the proposal in issue 583 and the linked SpatialData and Zulip discussions, then compare how scirpy stores AIRR data in AnnData or MuData with SpatialData.tables. Done means reaching and documenting an agreed representation for AIRR-only and multimodal spatial data, including how existing functions such as clonotype_modularity should access it.