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 [luc...@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. <dsmi...@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 [gsing...@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-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
