You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Coordinates in .obsm['spatial'] in Tables getting out of sync after transformations. #123
In the design doc we mention the possibility to store the centroids for labels and the centroids for graphs in the associated table, storing them with the intrinsic coordinate system. These coordinates could get out of sync after applying some transformations (for instance a cropping). We could take care of them and update them when we apply a transformation.
agree, I think the cropping and subsetting that is done at the spatialdata level should handle that. If the element is cropped outside spatialdata then I don't think we can give much guarantee
I believe the best is to have a new points layer, for instance the one returned from the new get_centroids() API. In this way there is no problem of getting out-of-sync because points are supported by the coordinate systems mechanism.
We should remove the references to obsm['spatial'] in the design doc.
Activity
giovp commentedon Feb 2, 2023
agree, I think the cropping and subsetting that is done at the spatialdata level should handle that. If the element is cropped outside spatialdata then I don't think we can give much guarantee
LucaMarconato commentedon Feb 22, 2024
I believe the best is to have a new points layer, for instance the one returned from the new
get_centroids()API. In this way there is no problem of getting out-of-sync because points are supported by the coordinate systems mechanism.We should remove the references to
obsm['spatial']in the design doc.LucaMarconato commentedon Mar 18, 2024
Updating the design doc now (removing
obsm['spatial']) and closing this.docs: clarify how coordinates stored in tables are treated (#1274)