[
https://issues.apache.org/jira/browse/LUCENE-6607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14604617#comment-14604617
]
Michael McCandless commented on LUCENE-6607:
--------------------------------------------
bq. Mike, why in your view is it not sufficient to mark APIs that are
particularly subject to change with @lucene.experimental ?
I think there are several compelling reasons to have large, new features in
sandbox first, regardless of whether their eventual destination is core or misc
or spatial or wherever.
First, it sends a message to users that this is very new functionality, very
subject to change, much more strongly than @lucene.experimental.
Second, we are free to make drastic changes / iterations, and to have a lower
bar that the API/abstractions are "correct". When I see discussions like
LUCENE-6578, where the standards for contributing new features to the spatial
module are too high (in my opinion), sandbox is the perfect answer: we can't
and shouldn't try get all abstractions right from the get-go.
Third, it keeps our modules/functions better separated. If geo3d were in
sandbox from the start, it would not need the external dependencies in the
spatial module (spatial4j).
Forth, for this particular case, I think it's interesting to explore
integration of BKD tree and GeoPointField with Geo3d, which are also already in
sandbox.
Net/net I think it's a big win if we move geo3d to sandbox.
> 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]
