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.
