lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Smiley, David W." <dsmi...@mitre.org>
Subject RE: Lucene Spatial Future
Date Tue, 05 Apr 2011 15:34:30 GMT
Mike: Lucene core supports what is required for efficient spatial algorithms to use it, without
requiring modification to Lucene.  So the answer to your question is "no".

~ David
________________________________________
From: Michael McCandless [lucene@mikemccandless.com]
Sent: Tuesday, April 05, 2011 11:23 AM
To: dev@lucene.apache.org
Cc: Smiley, David W.
Subject: Re: Lucene Spatial Future

Forgive my ignorance, but: are there any technical reasons for spatial
work to be "in core"?

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)?

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.

Mike

http://blog.mikemccandless.com

On Tue, Apr 5, 2011 at 11:10 AM, Smiley, David W. <dsmiley@mitre.org> wrote:
>> Alternatively, has anyone simply asked JTS if they would dual license or something
like that?  I'm happy to do that, but let's coordinate so that we aren't all bombarding the
guy.
>
> I did already.  Martin didn't respond but someone else did and the outlook is highly
unlikely (see Ryan's points about its history).  If I get news otherwise then I will respond
ASAP but consider it a long shot.
>
> Grant, since you too have an interest in spatial, you too could be a developer on lucene-spatial-playground
(I look forward to a better name).  Just because there are folks interested in spatial involved
with Lucene/Solr does not mean that the module needs to actually be in the Lucene/Solr's codebase
itself.  I think geospatial is both fairly specialized and also only desired by a fraction
of Lucene/Solr users, particularly beyond the basic essentials satisfied with a pair of trie
doubles (LatLonPoint) and a distance functionquery.  If you consider that, then why would
it be in Lucene/Solr?
>
> ~ David
> ________________________________________
> From: Grant Ingersoll [gsingers@apache.org]
> Sent: Tuesday, April 05, 2011 9:34 AM
> To: dev@lucene.apache.org
> Subject: Re: Lucene Spatial Future
>
> On Apr 3, 2011, at 3:50 PM, Ryan McKinley wrote:
>
>
> In the days of sub-projects, I would have proposed that option, but
> now I see two options:
>
> A.  Work on spatial lucene outside of apache -- perhaps osgeo or even
> just github. (would need a different name)
> B.  Allow JTS compile-time dependency in lucene, and move spatial
> contrib to a real module
>
>
> What about C:  Spatial in Lucene/Solr w/ JTS component in Apache Extras as a drop in
jar that implements the appropriate bindings?  I personally have an interest in good spatial
in L/S including more than just point search.  This solution need not require any automated
downloads/compiles, etc. and it can be noted that the support of that particular jar is handled
on Apache Extras (or Githup or wherever)
>
> Alternatively, has anyone simply asked JTS if they would dual license or something like
that?  I'm happy to do that, but let's coordinate so that we aren't all bombarding the guy.
>
> I think option A is better long term, but I feel like the kid saying
> "if I can't have my way I'll take my ball (code) and go home"  -- i
> don't want this to sound like an ultimatum, but an honest discussion
> about what has the best chance of fostering a thriving development
> community.
>
> I personally don't.  I think we have enough committers who are active on spatial that
we can sustain it once we have a good foundation in place (which we are close to) and we also
have several contributors who have been active on spatial and are likely good candidates for
being committers to work on it.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message