Repository navigation
Discussion: unique names for elements, pro and cons #124
Description
I propose to enforce unique names among the elements of one SpatailData object. Here I explore the implications.
Cons:
- The user has less freedom since different types can't have the same name. Still, when merging/concatenating different
SpatialDataobjects (say 1sdata= 1 sample), one could have exactly the same name for the same element types (like all theLabelsare calledcells), so the user is already limited in this regard.
Neutral:
- The file storage can be kept as it is (because we can infer types when we read), or we can choose to make it completely flat.
Pro:
- In transformations, see discussion in the comment below this one, we can have function calls like this
points = sd.transform(sdata, element_name='cells', tgt="tgt_space")
instead of this
points = sd.transform(sdata, element_type='labels', element_name='cells', tgt="tgt_space")
- (big pro): the tables, the column "instance_key" can be a simple string like "cell_segmentation", now it needs to be "/labels/cell_segmentation" and this feels super weird.
Activity
LucaMarconato commentedon Feb 10, 2023
If we go for unique names we could implement theset_transfomation()andremove_transformation()functions with a signature likesdata.set_transformation(self, Union[str, SpatialElement], ...etc), where the string is the name of the element.EDIT: these functions have different signature now.
LucaMarconato commentedon Feb 12, 2023
Another argument in favor for unique names is that napari layers must have unique names.
LucaMarconato commentedon Mar 6, 2023
Unique names have been implemented. The function
sd.transformhasn't been modified, but if implementing this signature or not:points = sd.transform(sdata, element_name='cells', tgt="tgt_space")should be done eventually in another issue.