Ryan and I chatted about this issue more and I didn't take consolidation steps yet. I'm pretty neutral, by the way – I see both sides.
Another option occurred to me and I'm excited about the prospects because I think it's a good balance. To be clear, spatial-base has nothing to do with Lucene. It largely consists of shape interfaces with implementations, has some distance calculators like Haversine and other spatial calculations, and can (or at least should) parse and emit some dialect of WKT – a popular standard, extended where needed to represent shapes that aren't in WKT such as a circle. There's a good deal of testing too. It is certainly useful in its own right just as other spatial libraries are. To defend its existence when there are other spatial libraries, I'll point out a few things that make this more desirable than other 3rd party libraries:
- ASL licensed; required for acceptence by the Lucene PMC
- Geospatial orientation, not just 2D. FYI JTS is purely 2D.
- Has shapes not found in other libraries like a point-distance (circle) shape. It's inexplicable to me why this isn't elsewhere. And this shape isn't just some POJO for a point & radius, there is sophisticated math for the various relations (e.g. disjoint, contains, etc.) of rectangle-circle intersection.
- Performance oriented – it was developed concurrent with lucene spatial search algorithms and I try to keep this in mind.
So how about spatial-base remains in the LSP project off-Lucene. LSP and this component will both probably receive a name change and possible re-hosting on Github. LSP (or whatever its eventual name is) will always need to exist any way because there are integration scenarios involving LGPL libraries that the Lucene PMC is uncomfortable with, and there is a nifty demo webapp too. The spatial-extras module could probably be merged with spatial-base, making testing easier and it's one less jar.
If spatial-base becomes a 3rd party library required by a single Lucene spatial module, then that brings a simplicity to the code organization insofar as there is just one spatial module, not 2. It also means that the spatial module will be entirely focused on the intersection of Lucene & spatial, and not have other code unrelated to Lucene. When deployed, it would mean 2 jars, the spatial-base.jar (or whatever its renamed to) and lucene-spatial.jar. FYI Solr, at least for the moment, would only need the base one, not lucene-spatial.
The down side is that both spatial-base and lucene-spatial are in-progress and are largely developed together, and so separating them to live on independent projects will bring about some extra burden in syncing them from time to time. This is reminiscent of the Lucene & Solr projects before they were merged. To mitigate this, our spatial team (me, Ryan, Chris) can initially focus on making changes to the public API of spatial-base to the point we like it even more and are less likely to change it.