Adding attrs at the SpatialData object level

[quentinblampey]

As described in issue #404, it is useful to have attributes at the SpatialData object level. This will also be useful in Sopa, to simplify the API.

Example Usage

import spatialdata

from spatialdata.datasets import blobs

sdata = blobs()

sdata.attrs # empty dictionnary
sdata.attrs["test"] = 12

sdata.write("blobs.zarr") # this saves the attributes on disk

sdata = spatialdata.read_zarr("blobs.zarr") # the attributes are read normally

sdata.attrs["test"] # returns 12

What do you think @LucaMarconato?

Check-list

• Add attrs attribute to the SpatialData object
• Can write the attrs on disk when the data is not backed
• Can write the attrs on disk when the data is already backed
• Can read the attrs from disk
• Pass the attrs to new SpatialData objects
• Merge conflict keys in attrs during concatenation
• Update the format version (see Luca's comment)

[codecov]

Codecov Report

Attention: Patch coverage is 91.66667% with 3 lines in your changes missing coverage. Please review.

Project coverage is 91.83%. Comparing base (42f7b6a) to head (ffbac84).

Files with missing lines	Patch %	Lines
src/spatialdata/_core/spatialdata.py	89.28%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #711      +/-   ##
==========================================
- Coverage   91.85%   91.83%   -0.02%     
==========================================
  Files          45       45              
  Lines        6885     6910      +25     
==========================================
+ Hits         6324     6346      +22     
- Misses        561      564       +3     

Files with missing lines	Coverage Δ
src/spatialdata/_core/concatenate.py	91.80% <100.00%> (+0.20%)	⬆️
src/spatialdata/_core/operations/rasterize.py	90.45% <100.00%> (ø)
src/spatialdata/_core/operations/transform.py	90.82% <100.00%> (ø)
src/spatialdata/_core/query/spatial_query.py	95.46% <100.00%> (ø)
src/spatialdata/_io/io_zarr.py	88.37% <ø> (ø)
src/spatialdata/_core/spatialdata.py	90.77% <89.28%> (-0.11%)	⬇️

[LucaMarconato]

Thanks for the PR.

• before merging we need to update the format version; we probably should add a format for the SpatialData container; something asked also by several users (we already have a format for the single elements, which would be independent from the format of the container).

[quentinblampey]

Hi @LucaMarconato, have you started working on your last comment? If not, do you want me to have a look (although I'm not exactly sure to understand what you want to do)?

[quentinblampey]

I noticed we are missing a feature: after we save a SpatialData object, if we add a new attr, there is currently no way to save it on disk. Something like sdata.write_element for the attrs

[Marius1311]

Just a random note on this: I agree that having SpatialData - level attributes would be super helpful. Beyond that, I think it would be great to be able to annotate coordinate systems - these often correspond to samples, conditions, time-points etc. I can of course annotate all elements within a coordinate system through tables, but I think it would be more direct to somehow directly provide metadata for an entire coordinate system.

[quentinblampey]

I also noticed that we want to pass the attrs inside certain functions, e.g. when performing a query (the attrs should be kept). I made a commit for this

The only concern is when we concatenate multiple SpatialData objects, how should we merge the duplicate keys (if any)?

NB: I updated the first post with a check-list

[LucaMarconato]

@quentinblampey thanks for the update. I haven't updated the format yet, we can work on it this week at the hackathon. Regarding saving to disk, I suggest to extend the write_metadata() method. Finally, regarding .attrs, we could proceed as AnnData does for .uns when calling ad.concat().

[timtreis]

Extremely interested in this, thanks @quentinblampey !!