[
https://issues.apache.org/jira/browse/LUCENE-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609731#comment-14609731
]
Karl Wright commented on LUCENE-6607:
-------------------------------------
Hi [~nknize],
We agree that this is all about dependencies, right? And we agree that, for
lucene core, there are certain criteria for dependencies. I'm, first of all,
trying to determine what those criteria are. The reason I am asking is because
I think geo3d is *not* eventually going to be integrated into lucene-core.jar.
It will remain a separate dependency somewhere, so that other people can use
just the geo functionality outside of Lucene. It will not, however, bring in
expensive and massive dependencies downstream, so I guess it satisfies the
criteria? Or maybe it doesn't?
And then I began to realize that spatial4j, which modules/spatial depends upon,
is *also* lightweight, and provides many of the same basic abilities (minus the
polygons) that you've been implementing, such as rectangles that cross date
line boundaries. It also has no massive required downstream dependencies. But
including this as a core dependency was apparently unacceptable, so I'm trying
to figure out why, precisely? Is this a legal/management issue rather than a
code issue?
Finally, I don't know whether I am correct in assuming that introducing a new
field type into lucene-core has significant benefits integration-wise over
creating a new field type in modules/spatial. If there isn't any huge benefit,
then maybe everyone's work here, including [~mikemccand]'s BKD implementation,
might just as well live in modules/spatial. Mike, please clarify...
> 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]
