Mapping Spatialdata/scverse to SPE/SFE

[Artur-man]

In essence, the SpatialData framework establishes a FAIR storage for arbitrary spatial data readouts. However, its user interface and usage is challenging for those who want to use the Python implementation scverse/spatialdata for downstream analysis.

it would be useful to implement additional utilities to packages like SpatialExperiment and SpatialFeatureExperiment to lazily (delayed) read components of on-disk representation of the spatialdata object. Thus we can use SPE/SFE compatible BioC packages while mapping the actual data from the SpatialData zarr store.

CC @drighelli (we discussed this before)

[jdhenaos]

Hi!

I have also shown interest in this regard.

As far as I understood, it is to create a "spatialdataR" with additional translation capabilities into SPE/SFE. Am I correct?

[Artur-man]

There is an implementation that we work on https://github.com/HelenaLC/SpatialData. But instead of converting we can link components across classes. Thus, the interface would be SPE/SFE but data is stored (or originally linked) in SpatialData.

This is a nice (and quick) alternative to rewriting downstream analysis packages to depend on SpatialData directly, and use the existing SPE/SFE connections instead.

[HelenaLC]

This will be heard to realize (I think) since SPE/SFE don't support lazy representation of points/shapes? SPE has nothing of the sort, so would need new int_colData. SFE realizes everything into memory? I might be missing something... but agree, the idea of a readSDasSPE/SFE() function that does not depend on SD is nice and should be fairly straightforward to implement.

[mjemons]

can we convert the sdata.tables["AnnData"] directly to a SCE/SPE via anndataR? Maybe extending to have the sdata.points information in the SpatialCoords slot of the SPE
Or then extending anndataR to be able to read in the sdata.shapes of the cell polygons to then build an SFE?

[HelenaLC]

Yes, we already have this... And I put together a function that does that in ~10 lines or so. But it's more tricky than one might think...

• to know which element to retrieve, one needs to check the spatialdata_attrs
• then read that element only and compute centroids to use as spatialCoords
• this is trivial for points, but harder for, e.g., multiscale images
• then there is no native support for points/shapes in SPE
• so we go to SFE, but that requires realizing things into memory
• along the way, everything that doesn't map to an obs. is dropper
• or needs to be moved into some list or altExp

...all that to say it's not hard, but also no class is intended to represent arbitrary omics of arbitary shapes in the same .zarr/.parquet backed manner.

# running example
# xy = centroids from the 'label' element being annotated
# (i.e., average of non-zero ZarrArray indices)

> x <- file.path("extdata", "blobs.zarr")
> x <- system.file(x, package="SpatialData")
> (spe <- readSDasSPE(x))
class: SpatialExperiment 
dim: 3 10 
metadata(0):
assays(1): X
rownames(3): channel_0_sum channel_1_sum
  channel_2_sum
rowData names(0):
colnames(10): 3 4 ... 15 16
colData names(1): sample_id
reducedDimNames(0):
mainExpName: NULL
altExpNames(0):
spatialCoords names(2) : x y
imgData names(0):