lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan McKinley <>
Subject Re: Lucene Spatial Future
Date Tue, 05 Apr 2011 15:39:03 GMT
On Tue, Apr 5, 2011 at 11:23 AM, Michael McCandless
<> wrote:
> Forgive my ignorance, but: are there any technical reasons for spatial
> work to be "in core"?

There is no reason it needs to be in core.

As is, it is a maven build that depends on -SNAPSHOT and everything works great.

> Or can all the spatial algos be "safely" (ie, won't lose much
> performance, if any) built "on top" of Lucene's (Solr's) APIs?  Do we
> need to open up new APIs (in which case being part of one code base,
> released together, is a strong advantage)?

Not that i can think of -- it is right now using features that will
get better when new things are added to lucene (for example the
docvalues branch) but i think that is true of any project built on top
of lucene.

My push to have a Numeric field that both solr and lucene use was
motivated by this project.  Again, not a unique problem to spatial.

Also, i recently changed some package protected constants in solr to
protected -- so that an external library could make complex solr

> For example, incremental field updates is a long needed and often
> requested feature in Lucene, but this really couldn't be
> easily/efficiently build "on top" -- it requires access to lots of
> inside details that are tracked during indexing.

Nothing like that in spatial contrib.  The closest I can think of (and
this is a long shot) I can see writing a spatial codec that writes
values to an rtree.  But even this should be able to work within
published (or SNAPSHOT) apis.

More importantly, the people who would work on the core lucene
problems vs the people who would work on the majority of spatial
problems are pretty different.

It would be nice if spatial contributions could not possibly break the
lucene build.


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

View raw message