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
From what I have seen, the current RTreeNode implementation does not offer a unique (hashable, implements == correctly) key for each RTreeNode.
More specifically, I believe there are many usecases where one might need some sort of internal "access" to the node, meaning a way to add some sort of data to each one. In my case, this "data" is a tuple of values. However, since there is nothing correctly hashable in each RTreeNode, I can not find a way to create a Hashmap for ex. in order to store the data I need. The only info that is always available for each RTreeNode is the envelope, however two nodes can have the same envelope which means that this is not an appropriate key.
Adding some way to extract a (preferably hashable) unique ID for each RTreeNode would be useful in many ways, since it can allow a more "free" approach to traversal and can also allow child to parent referances instead of just parent to child.
The text was updated successfully, but these errors were encountered:
From what I have seen, the current RTreeNode implementation does not offer a unique (hashable, implements == correctly) key for each RTreeNode.
More specifically, I believe there are many usecases where one might need some sort of internal "access" to the node, meaning a way to add some sort of data to each one. In my case, this "data" is a tuple of values. However, since there is nothing correctly hashable in each RTreeNode, I can not find a way to create a Hashmap for ex. in order to store the data I need. The only info that is always available for each RTreeNode is the envelope, however two nodes can have the same envelope which means that this is not an appropriate key.
Adding some way to extract a (preferably hashable) unique ID for each RTreeNode would be useful in many ways, since it can allow a more "free" approach to traversal and can also allow child to parent referances instead of just parent to child.
The text was updated successfully, but these errors were encountered: