Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[spatial4j-dev] ANNOUNCE: Move to LocationTech
The move of Spatial4j into the LocationTech/Eclipse foundation is finally happening.

1. This mailing list (@spatial4j.com) will be decommissioned.
There is a new/different mailing list: spatial4j-dev@xxxxxxxxxxxxxxxx  Unfortunately, I couldn’t arrange for the transfer of subscribers or history because of Terms of Service and privacy policy issues, so *you must subscribe*: https://locationtech.org/mailman/listinfo/spatial4j-dev

2. The GitHub project will be moved from the /spatial4j owner to the /locationtech owner.  All issues & branches should survive.  The branches will be bulk renamed with an “-old” suffix (or similar).  There will be a new master branch with no history based on the “initial contribution”.

3. There is no change to the copyright or license.  That’s right, it will remain copyrighted to the Apache Software Foundation, and it will still have the Apache Software License v2.  The source headers will likely stay the same.  This was allowed for convenience and in recognizing ASF’s good stewardship of IP.

4. The java package structure is changing from “com.spatial4j.core” to “org.locationtech.spatial4j”.

You can see the “initial contribution” branch here: https://github.com/spatial4j/spatial4j/tree/LocationTech-Contribution

Because the package needs to be renamed, this is an excellent time to reconsider the Java package structure.  As it is, I removed the “core” part.  Some other thoughts on this:
* Chris Male wants to move the GeohashUtils out of “.io” into top-level:
https://github.com/spatial4j/spatial4j/issues/16
I’m good either way I guess; it’s debatable.  I put it in “io” because it has to do with an encoding.
* The “exception” subpackage could have its sole exception moved out to op level.
* I don’t really like the “shape” & “shape.impl” distinction because some things don’t really fit the pattern, which is then awkward. Maybe *that*’s the problem instead of the package?  For example ShapeCollection — it’s a concrete class without an interface.  Maybe there should be an interface.  Same could be said for BufferedLine & BufferedLineString.  I dunno; maybe easiest to dump them all into “shape”, except for JTS dependent ones.
* JTS dependent classes:  Should JTS dependent classes stay in “jts” sub-packages or should they those “jts” packages get removed since, after all, those classes start with “Jts” any way?

Also, I’m thinking the first release will be based on the LocationTech move will be 1.0.  I don’t think it will be “soon” but I think that should be the next one.  I’d like to get to some API refactorings in the 1.0 release, particularly around DistanceCalculator.

There may still be a 0.4.2 or 0.5

~ David Smiley
Freelance Apache Lucene/Solr Search Consultant/Developer

Back to the top