[
https://issues.apache.org/jira/browse/LUCENE-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14606953#comment-14606953
]
David Smiley commented on LUCENE-6607:
--------------------------------------
I get the "First" reason (signals subject-to-change in a bigger way). "Second"
seems like the first. BTW I've used trunk in the past for this, which is
another alternative.
"Third" I disagree with; and I'm surprised to hear you say it keeps modules
better separated because a sandbox module (in my view) does the opposite thing
you purport it to do -- it _fragments_ them. It raises the question as to
wether to put something in sandbox vs the module it actually is related to by
subject area. Your rationale for the "fourth" shows that. _If the spatial code
stays in the spatial module, there would be no need to raise this issue!_
bq. If geo3d were in sandbox from the start, it would not need the external
dependencies in the spatial module (spatial4j).
I fundamentally believe that if we add new code to Lucene (in whatever module),
a user should be able to use that code with Lucene without developing any
glue/adapters. This simply amounted to Geo3dShape.java (quite the bare
minimum; see for yourself), which Karl provided early-on. Furthermore he & I
re-used shape testing utilities in Spatial4j that surfaced bugs -- they heavily
use a randomized-testing philosophy which I hope you can appreciate. All other
tests in Geo3D are standard static input/output unit tests. So this was very
much worthwhile. But even putting aside how worthwhile it is (which you may
contend no matter what I say), and putting aside my contention that it needed
to integrate from the start, you seem to disagree with your own claim that
Geo3d needed to go to the spatial module in order to use Spatial4j. You just
told Karl that the spatial module could depend on sandbox.
*My vote is -0* because at least one of your reasons made some sense to me, but
really I don't think our modules should be fragmented except for core. And I
have a high bar for a -1 vote too.
Separately, kind of a related aside, I'd like to state again that I don't think
it makes sense for Geo3D to be here long term. It's an awesome computational
geometry package that other projects (pick any information-retrieval / database
/ NoSQL store / anything really) could benefit greatly from. It's a gem, but a
hidden gem as long as it's here. I hope we can improve it while it has a nice
stay here, but that you could understand that one day it ought to have a home
elsewhere (yet we'd still use it), be it on it's own or a part of another
computational geometry lib.
> Move geo3d to Lucene's sandbox module
> -------------------------------------
>
> Key: LUCENE-6607
> URL: https://issues.apache.org/jira/browse/LUCENE-6607
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 5.3, Trunk
>
>
> Geo3d is a powerful low-level geo API, recording places on the earth's
> surface in the index in three dimensions (as 3 separate numbers) and offering
> fast shape intersection/distance testing at search time.
> [~daddywri] originally contributed this in LUCENE-6196, and we put it in
> spatial module, but I think a more natural place for it, for now anyway, is
> Lucene's sandbox module: it's very new, its APIs/abstractions are very much
> in flux (and the higher standards for abstractions in the spatial module
> cause disagreements: LUCENE-6578), [~daddywri] and others could iterate
> faster on changes in sandbox, etc.
> This would also un-block issues like LUCENE-6480, allowing GeoPointField and
> BKD trees to also use geo3d.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
