Description
Intro
The bug that I'll describe is a consequence of the current coordinate systems implementation and will disappear when it will be refactored. The bug needs to be fixed upstream, but has a consequence in spaitaldata-plot. Nothing to do now, I report it so that we can check that things work when the transformation refactoring is implemented.
To reproduce one can run the last cell of the densenet
example notebook.
Description
The function sdata.filter_by_coordinate_system()
returns elements that are present in a coordinate system but it doesn't remove eventual transformations to other coordinate systems. This can't be done with the current design.
A consequence in spatialdata plot is a bug in the following scenario (this is what happens in the densenet
notebook):
- I want to make a plot with 4 subplots, I'll do passing
pl.show(ax=axes[i])
- Each subplot will have an image element and a shapes element
- I want to plot only the
aligned
coordinate system. The image is mapped toaligned
, the shapes is mapped toaligned
andglobal
.
Now, since the global
is not removed by sdata.filter_by_coordinate_system()
(it can't, otherwise it compromises the original object), this leads to spatialdata-plot try to span extra axes, to fit the elements in global
, leading to an error.
Solution
Since I will remove the actual transformations from the spatial elements, by placing them instead in sdata
, the new sdata
object returned by sdata.filter_by_coordinate_system()
can just drop the alignment to global
without the need to modify the original objects.