Today I attended a monthly LocationTech PMC meeting. I asked what’s next for Spatial4j to leave incubation and it appears it’s actually in our hands; not Eclipse. Andrea Ross said, basically, that we should change the java package structure and other such things making it clear this is LocationTech and then we do a release that is submitted/nominated to be the first official release. I’m kind of beside myself that this could be true; I really thought the ball wasn’t in our court, and now it is. I’ll look into it some more.
So we just had a release… yet we need to do a release to be the first official release. I’m torn between just doing a release for the sake of releasing to be out of incubation, versus trying to really move the API along first. But the latter requires time and I’m inclined to get incubation behind us (Andrea and the PMC are excited about this; Spatial4j looks to be the first out of incubation) even if it means a release that’s sort of pointless from a technical perspective — it’s not like I’d go updating consumers (namely Lucene-spatial) just for the benefit of a package change. I’d wait for the next release that has actual features.
BTW Some things that come to mind to change-up the API a bit:
* Introduce a ShapeBuilder abstraction supplied by the SpatialContext that is used by the ShapeReader’s. Critically it would have polygon construction methods. Initially it’d just have a JTS implementation and a basic one. Point, circle, and rectangle factory methods could stay on the context for convenience. The SpatialContext impl might then become a bit more generic.
* Add a Geo3D impl of this ShapeBuilder — a new optional dependency alongside the choice of JTS. Take Geo3dShape from lucene-spatial and it’s tests.
* ShapeCollection could be typed, taking a Class instance for the type. This would support better round-tripping.
~ David
