Repository navigation
Get name of given element #423
Description
SpatialData elements not always keep the name within the element (at least in spatialdata==0.0.15). The element type has a name attribute, but it is None (at least for non-backed SpatialData). However, the name can be useful.
Use case: Passing individual elements to custom functions
def fn(elem1, elem2):
...
# Create a plot
# or a warning / validation error for the user.
fn(sdata["element_name1"], sdata["element_name1"])- I would have to output a generic name
element {i}which is not human-readable and does not pin-point the user to what is wrong without looking into the source code. - Or I change the function interface to include additional arguments
elem1_name. - Or I pass the whole SpatialData to the function
fn(sdata, elem1_name, elem2_name)
Use case: Identify the name of an element under which it is registered in a SpatialData object
Given an element, is it already contained in a SpatialData object, and what is the name?
I understand the reasons why to keep names only as keys and avoid inconsistencies (name attribute mismatching its key; same element added in memory under two keys). This would cause significant complexity.
- I saw that there is a method
contains_elementthat does a boolean check. But knowing that the queried element is contained, an API user still doesn't know the name, and may be tempted to do a naive==comparison against each element (which does a prohibitively slow deep comparison). contains_elementseems to have a bug that it returns False if an element is contained more than once. Since it is contained, it should be True.- A new method could be added that returns the name if contained. To me personally, if not contained, it seems more practical to return None because a conditional check on the result is simpler than wrapping with try/except. In the case of an element contained more than once , it may raise an error since there is no unambiguous single name to return (?).
Maybe_locate_spatial_elementcould be made public? If its API is stable and it is desirable to return the element type as well. On the other side, the user would likely know the element type, so it could also be a method on the elements container? (sdata.images.name_of(elem))
Activity
MobiTobi commentedon Jan 8, 2024
aeisenbarth commentedon Jan 8, 2024
I mean for any SpatialElement (implemented by SpatialImage, MultiscaleSpatialImage, DaskDataFrame, GeoDataFrame), whether it is contained in the images, labels, points, or shapes of a SpatialData instance.
LucaMarconato commentedon Jan 9, 2024
Hi @aeisenbarth, thanks for the discussion. In early versions of the library we had names inside the elements but we decided to drop them for the reasons that you mentioned (inconsistency when assigning the objects to a new key, elements shared between two keys), and to avoid redundancy because the information of the name would have been stored twice.
Therefore, if there is a part of the code in which the name is still assigned this is probably a bug/leftover. Did you find names for backed objects?
Regarding having API to find the name in a fast way, I also think that this is a something desirable, and we can adjust the current private/public methods to provide such API 😊
aeisenbarth commentedon Jan 9, 2024
I checked and cannot reproduce my previous observation. So all seems fine.
LucaMarconato commentedon Jan 9, 2024
I have made a PR to make
_locate_spatial_element()public (I renamed it tolocate_element()). I have kept it returning both the type and name of the element because we plan to support arbitrary nested hierarchies in NGFF stores and with that the "name" of the element will be the full path, likeimage/my_image.