lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
Date Sat, 25 Feb 2012 19:19:49 GMT


David Smiley commented on LUCENE-3795:

Ryan and I chatted about this issue more and I didn't take consolidation steps yet.  I'm pretty
neutral, by the way -- I see both sides.

Another option occurred to me and I'm excited about the prospects because I think it's a good
balance.  To be clear, spatial-base has nothing to do with Lucene.  It largely consists of
shape interfaces with implementations, has some distance calculators like Haversine and other
spatial calculations, and can (or at least should) parse and emit some dialect of WKT -- a
popular standard, extended where needed to represent shapes that aren't in WKT such as a circle.
 There's a good deal of testing too.  It is certainly useful in its own right just as other
spatial libraries are.  To defend its existence when there are other spatial libraries, I'll
point out a few things that make this more desirable than other 3rd party libraries:
* ASL licensed; required for acceptence by the Lucene PMC
* Geospatial orientation, not just 2D.  FYI JTS is purely 2D.
* Has shapes not found in other libraries like a point-distance (circle) shape.  It's inexplicable
to me why this isn't elsewhere.  And this shape isn't just some POJO for a point & radius,
there is sophisticated math for the various relations (e.g. disjoint, contains, etc.) of rectangle-circle
* Performance oriented -- it was developed concurrent with lucene spatial search algorithms
and I try to keep this in mind.

So how about spatial-base remains in the LSP project off-Lucene.  LSP and this component will
both probably receive a name change and possible re-hosting on Github.  LSP (or whatever its
eventual name is) will always need to exist any way because there are integration scenarios
involving LGPL libraries that the Lucene PMC is uncomfortable with, and there is a nifty demo
webapp too.  The spatial-extras module could probably be merged with spatial-base, making
testing easier and it's one less jar.

If spatial-base becomes a 3rd party library required by a single Lucene spatial module, then
that brings a simplicity to the code organization insofar as there is just one spatial module,
not 2.  It also means that the spatial module will be entirely focused on the intersection
of Lucene & spatial, and not have other code unrelated to Lucene.  When deployed, it would
mean 2 jars, the spatial-base.jar (or whatever its renamed to) and lucene-spatial.jar.  FYI
Solr, at least for the moment, would only need the base one, not lucene-spatial.

The down side is that both spatial-base and lucene-spatial are in-progress and are largely
developed together, and so separating them to live on independent projects will bring about
some extra burden in syncing them from time to time.  This is reminiscent of the Lucene &
Solr projects before they were merged.  To mitigate this, our spatial team (me, Ryan, Chris)
can initially focus on making changes to the public API of spatial-base to the point we like
it even more and are less likely to change it.
> Replace spatial contrib module with LSP's spatial-lucene module
> ---------------------------------------------------------------
>                 Key: LUCENE-3795
>                 URL:
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: modules/spatial
>            Reporter: David Smiley
>            Assignee: David Smiley
>             Fix For: 4.0
> I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module
within Lucene Spatial Playground (LSP).  LSP has been in development for approximately 1 year
by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready.  LSP is here:
 and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/.
> I'll add more comments to prevent the issue description from being too long.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message