[
https://issues.apache.org/jira/browse/LUCENE-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216522#comment-13216522
]
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 intersection.
* 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: https://issues.apache.org/jira/browse/LUCENE-3795
> 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:
> http://code.google.com/p/lucene-spatial-playground/ 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
