On 3/5/12 10:13 PM, David Smiley @MITRE.org wrote:
Hi.

I'm David Smiley, a recent committer to the Apache Lucene project.  I do a
lot of Lucene/Solr development implementing [geo]spatial search.  Ryan
McKinley (another committer) and I created a generic spatial ASL-licensed
library out of a portion of our work called Spatial4j ( http://spatial4j.com
forwards to a Github project).  I think Spatial4j should be of particular
interest to ASF projects that wish to add spatial support to their projects.
Why?  Because it *optionally* supports JTS -- the defacto spatial library in
Java.  Anybody whose done spatial work in Java probably knows this.  But
unfortunately, JTS and many other spatial libraries are LGPL licensed which
is problematic for ASF projects.  Spatial4j is ASL licensed but is not an
ASF project. You certainly don't need JTS to use lots of useful features in
Spatial4j.  Here are the main features:
* Shape objects: Point, Rectangle, Circle (i.e. point-radius)
* Calculate relation to another shape: within, contains, disjoint,
intersects
* Geospatial&  Spatial orientation
* Great-circle distance calculations (Law of Cosines, Haversine, Vincenty)
and other math
* Serialize and deserialize shapes to strings in a dialect of WKT -- the
standard on spatial interoperability
* An optional JTS extension adding support for more shapes and WKT, notably
polygons
Most of the code is well tested and it has been developed/improved over the
course of the past year or so.

I'm writing this both to announce it and get a sense of interest amongst
developers here.  I intend to do the same for some other ASF projects.
Integrating Spatial4j into Derby at least at basic level is conceptually
straight-forward.  Assuming latitudes and longitudes are indexed in Derby,
Spatial4j can assist in telling you what the bounding lat-lon rectangle is
of a user input point-radius.  That bounding box would be a first-pass
filter against your indexes.  Spatial4j will then tell you which indexed
points intersect with the query shape.  There are far more sophisticated
approaches that can be taken using PrefixTrees/Tries and an encoding like
Geohashes, as is taken for Lucene's new spatial module.

~ David Smiley
Thanks for this useful package, David. Probably it could be used as-is today by simple applications which just need to store spatial objects in columns and ask limited questions about their relationships. The Derby CREATE TYPE and CREATE FUNCTION commands may be used to hook your package into a Derby database. Indexing, of course, is another tricky bit. Lots of people have expressed interest in Derby RTrees, but the implementation would be a fair amount of work. I have added a pointer to this email thread to the relevant Derby JIRA issue: https://issues.apache.org/jira/browse/DERBY-3670

Thanks,
-Rick

Reply via email to