Good question! It’s mainly there to allow the user to serialise their index easily via Repr.to_bin_string or Repr.to_json_string or to pretty-print the whole thing. In retrospect, I think I should hide that serialisation behind a function that Rtree controls to avoid issues if the runtime representation of say the rectangle or tree changes. I was also thinking of providing the Vg rendering if the user adds a Repr.Attribute for rendering their values but I haven’t done that yet (not all rtree things are two-dimensional).
Thanks! And yes! I’ve been thinking of turning R* into an Outreachy project for the December round but first need to scope out the feasibility.
I asked about the repr because I am quite interested in spatial data structures and liked that the package is small but has this one dependency which does not look mature. So I would have like something more standard like a JSON serialisation.
Cool! I’m very open to removing Repr should there be a desire and good reason from users (please do open an issue should you feel strongly and I can take a look at providing the features without it). The dependency cone is fairly small too, not as small as something like Yojson I think but not much bigger (and you get a compact binary encoding and pretty-printers too).
That’s probably fair, I would add that is a core library of Irmin which has been well tested and benchmarked. Repr also has continuous benchmarks too so I feel like it probably is somewhat mature :)) But as I said very happy to reconsider if it is a show stopper for you.