Support read and initialize internal structure of STRtree and Quadtree

[jiayuasu]

This PR is to change the access modifiers of tree indexes and add setter/getters.

By making these changes, external libraries such as Apache Sedona (GeoSpark) will be able to directly assemble a Quad-Tree or R-Tree index without going through the time-consuming insert and build phases.

This is particularly useful for external libraries to write their own index serializers (as in this code).

Signed-off-by: Jia Yu jiayu198910@gmail.com

[jiayuasu]

@jnh5y @dr-jts Hey Jim and Martin, could you please take a look at this PR (2/2)?

This PR is related to the JTS dependency in Sedona (GeoSpark). Jim has known this issue long time ago.

[dr-jts]

I'm not crazy about making the internals of the trees public, since that breaks encapsulation in a big way. And once those methods are public they can't be changed.

How about making them package-private? Then you can add classes to the package to do what you want to do.

What is your actual use case?

[dr-jts]

I have been thinking about separating the structure of the R-tree from the building technique, to allow for different kinds of packing (and maybe even eventually a fully dynamic R-tree). The idea is that there would be tree builder classes which all produce a common Rtree structure. This is very much a WIP, though.

[jnh5y]

@jiayuasu thanks for putting these PRs up. For the access modifiers for the tree indexes, can you link us to the Sedona code which uses it?

[jiayuasu]

@dr-jts @jnh5y Hi Martin and Jim, could you please review this PR again?

I followed your instruction and use package private in Sedona. Now everything works great! So, now I just need to make these changes in JTS and hopefully they can be accepted.

[dr-jts]

Actually it is better to use setters and getters rather than give access to the internal fields. This will allow initialization behaviour to be include (where needed). The setters and getters should be package private.

For instance, instead of exposing a AbstractSTRtree.setBuilt method, could that flag be set when setRoot is called?

[dr-jts]

Here's an even better idea: provide constructors on STRtree which accept either a root node or a list of itemBoundables. That way the setter methods are not needed, which makes for a safer implementation.

[jiayuasu]

@dr-jts Hi Martin, I have updated the PR accordingly. In particular, I added a few constructors to STRtree.

[dr-jts]

Looks good. A few unit tests would be even better...

Otherwise is this done?

[jiayuasu]

@dr-jts Just added two unit tests for the new constructors. I think the PR is done now. And I will be waiting for the release of 1.18.0 :)

[dr-jts]

Looks good.

It occurred to me that it would be reasonable to have a method STRtree.insert(List<ItemBoundables> items), which could then be used in the same way as the new constructor (and actually slightly more flexible, since it could be called multiple times). But if this PR is meeting your need then this can wait until a need arises.