Are devs interested in adding spatial support (Spatial4j)?

["David Smiley @MITRE.org" <DS...@mitre.org>]

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
-- 
View this message in context: http://old.nabble.com/Are-devs-interested-in-adding-spatial-support-%28Spatial4j%29--tp33448923p33448923.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.

Re: Are devs interested in adding spatial support (Spatial4j)?

["David Smiley @MITRE.org" <DS...@mitre.org>]

Thanks for responding Rick.

As much as Spatial4j helps out, I agree there is a fair amount of work left
to spatial-enable a database system, especially if you want to go beyond
more basic point indexing.  (This would be even more true if all you had was
JTS, by the way).  And I don't think there's much Spatial4j can do beyond
what it does because the actual performant indexing is inherent to each
database system.  It's possible the PrefixTree approach I implemented for
Lucene might be generalized to other systems but I don't really know Derby's
low-level internals.  Thanks for the DERBY-3670 reference; I'm now
"watch"-ing it.

~ David


Rick Hillegas-3 wrote:
> 
> 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
> 
> 

-- 
View this message in context: http://old.nabble.com/Are-devs-interested-in-adding-spatial-support-%28Spatial4j%29--tp33448923p33451609.html
Sent from the Apache Derby Developers mailing list archive at Nabble.com.

Re: Are devs interested in adding spatial support (Spatial4j)?

[Rick Hillegas <ri...@oracle.com>]

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