The RTree module now contains the R*Tree variant also.
[https://github.com/StefanSalewski/RTree](https://github.com/StefanSalewski/RTree)
I guess the number of potential users of this module is very small -- I will
add a nimble install script in the next days and maybe even add it to the
nimble
I have just shipped the first working release:
[https://github.com/StefanSalewski/RTree](https://github.com/StefanSalewski/RTree)
The R*Tree variant, bulk-loading and nearest-neighbour-search may follow later.
Currently I favour to let the shape of the code as it is.
One question arise: Would it make sense to rewrite code like this
[https://github.com/StefanSalewski/RTree/blob/master/rtree.nim#L305](https://github.com/StefanSalewski/RTree/blob/master/rtree.nim#L305)
for j in 1 ..< n.numEn
Yes, maybe I will try object variants. But they also have some disadvantages:
Size is always determinated by largest variant, and additional space is
consumed by discriminator. To get clean, simple code I would have to make each
array element an object variant, with a common member bounding box.
Use object variants, they're exactly for cases like that --- the number of
variants is fixed.
In the last days I wrote a first draft following the Guttman paper.
While the algorithm is very simple and well explained in the paper, there are
two points which makes the implementation not that easy: 1. We want a fully
generic RTree (dimension, data type for location, data type for contained
As far as I know there is none.
I'm interested in a pure Nim implementation of R-tree and closely related
[Kd-tree](https://en.wikipedia.org/wiki/K-d_tree) for geospatial algorithms
(clustering especially).
I've added your suggestion to the "[Are we scientists
yet](https://github.com/nim-lang/
[https://en.wikipedia.org/wiki/R-tree](https://en.wikipedia.org/wiki/R-tree)
I assume not yet.
For Ruby I used my custom bindings to boost library for this. But as the RTree
algorithm is not too complex, a native Nim implementation may be preferable
over a Nim Boost-Rtree wrapper.
I guess we w
