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
Hi, I noticed that in the r-tree implementation where in file "rtree.go", you only do the slicing at the root level, the other levels use just one slice whose length is the size of entire current subdataset (i.e. don't slice).
May i ask why you are doing this?
From what I have observed, if the slicing strategy is used in every height of recursion, it is possible to generate better leaf MBRs (their length and width are closer rather than one being much larger than the other).
The text was updated successfully, but these errors were encountered:
Good question! Unfortunately I do not remember. My intention was to follow the algorithm as outlined in the linked papers, so if slicing at every height is implemented there, then probably this was just an oversight. I'd be happy to evaluate a pull request that changes this though, particularly if there's some benchmarking that shows it outperforms the existing implementation.
Hi, I noticed that in the r-tree implementation where in file "rtree.go", you only do the slicing at the root level, the other levels use just one slice whose length is the size of entire current subdataset (i.e. don't slice).
May i ask why you are doing this?
From what I have observed, if the slicing strategy is used in every height of recursion, it is possible to generate better leaf MBRs (their length and width are closer rather than one being much larger than the other).
The text was updated successfully, but these errors were encountered: