lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] [Commented] (LUCENE-6607) Move geo3d to Lucene's sandbox module
Date Sun, 28 Jun 2015 10:17:04 GMT


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:
>             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

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

View raw message