Added subset API; fix behavior with zero-len table

[LucaMarconato]

I added an API for subsetting a SpatialData object given a list of elements. This function is similar to pp.get_elements() from spatialdata-plot, with one of the major differences that it doesn't filter by coordinate system like pp.get_elements().

Also, I have noticed that when various APIs that use the argument filter_table=True where returning a SpatialData object with a table with len 0, instead of None. This was confusing because from the __repr__ of SpatialData it seems that there was no table.

I modified the behavior by setting the table to None, but maybe we should allow for tables of zero len and modify the __repr__ to print such tables. WDYT @giovp @melonora?

---

@timtreis @Sonja-Stockhaus ideally we would have only one function upstream (see #289 and scverse/spatialdata-plot#138). Can you please comment on the first issue by listing what would be needed to have all the functions you need from spatialdata-plot upstream? Thanks

[LucaMarconato]

Ah, fails on 3.9, gonna fix that.

[codecov]

Codecov Report

Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (9470a61) 91.60% compared to head (7fc751e) 91.61%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #426   +/-   ##
=======================================
  Coverage   91.60%   91.61%           
=======================================
  Files          37       37           
  Lines        5017     5033   +16     
=======================================
+ Hits         4596     4611   +15     
- Misses        421      422    +1     

Files	Coverage Δ
src/spatialdata/_core/spatialdata.py	92.89% <100.00%> (+0.13%)	⬆️
src/spatialdata/_core/query/spatial_query.py	91.84% <83.33%> (-0.17%)	⬇️

[giovp]

that looks great @LucaMarconato ! But what about having sdata[["image1","label1"]] instead of sdata.subset(...)? or even extending the query method and basically having an interface similar to the pd.query?

[aeisenbarth]

Nice!

I have just written a function (using get_elements) with more granularity that additionally filters table names and keys. So maybe it's worth to exchange before adding this new API.

Developer's use case

I want to provide input to a unit test for a function which adds some sort of data to SpatialData (image, table obs/var name/column). The input is derived as a subset from a fully processed SpatialData with the to-be-added data excluded.

(For example if I want to check whether the function really sets X values, I must provide it with a SpatialData that does not have these X values. Also, I filter elements and corresponding regions in the table independently, that means a labels element may be present, but its region has no entries in the table.)

def filter_spatialdata(
    sdata: SpatialData,
    elements: Optional[Iterable[str]] = tuple(),
    regions: Optional[Iterable[str]] = tuple(),
    obs_keys: Optional[Iterable[str]] = tuple(),
    var_keys: Optional[Iterable[str]] = tuple(),
    var_names: Optional[Iterable[str]] = tuple(),
    # I haven't implemented obsm and others.
):
    ...

I believe this is too advanced for a public API (I only need it for testing). As an API, it would need to cover all AnnData keys which increases the complexity and potential for bugs, for something most users are not going to use.

Data analyst's use case

I imagine for a data analyst's use-case, the interest is more in filtering spatial regions, but keeping all annotations associated with these regions does no harm.
If there are more table columns than needed, one would just not use them, or would there be a need to remove them? Anyone has more experience?

[LucaMarconato]

Thanks @aeisenbarth, sounds very useful for development purposes indeed. I suggest to move the conversation on this to the context of this issues: #289 and scverse/spatialdata-plot#138. In fact, when moving out pp.get_elements() from spatialdata-plot, we could also include your functionality (and you could maybe contribute directly to that PR).

Thanks @giovp for the review. I agree that we could put more order in the query interface and this function could be part of it (together with the one from spatialdata-plot and the one from Andreas, after a unification). Nevertheless, I propose to do this in the context of this already open issue #225, so here I prefer to merge the PR to add the new functionality.