Just a small piece of feedback on your note Bill. I don't need more help in knowing the best way to support multi-value sort. I've figured out an approach I feel confident in (and it's 1/3 coded)... were it not for my new baby (and the 2nd edition of my book for sure!) you'd be using it right now. It frustrates me very much that I haven't had sufficient time yet. I'm shooting for Friday April 1st at the absolute latest now. It's not going to have any fancy tie-in with the filtering yet; I'll leave that for a future patch.
~ David ________________________________________ From: William Bell [[email protected]] Sent: Sunday, March 27, 2011 12:19 AM To: [email protected] Cc: Chris Male; [email protected] Subject: Re: [jira] [Commented] (SOLR-2155) Geospatial search using geohash prefixes Maybe I am too close to this issue and not looking at global implications like you are.... SOLR-2155 seems fairly close to "good to go". There are a couple open issues that David Smiley has been asking for input on. I would recommend we answer those questions, and commit it. Then we can look at modules, etc. If a rewrite was on the works, a committer should have said something a LONG time ago. Like back in October or something. Are we talking redesign or refactoring? I think core spatial things should remain in Lucene. Even though Spatial support in 3.1 is basic it is stable, and VERY fast. We ran regression tests and the performance was 10-100x faster than the plugin solution of Solr Spatial from Patrick. Whatever fancy support for polygons, etc we support it needs to be even faster than what we have with 3.1. What I like about this patch more than anything is the support for multiple-lat longs per document. I have several clients who need this feature. For example, one doctor with multiple offices. It would be nice if a committer would work with David Smiley to get this done. 1. We would like to know if the pole issue can be solved and how. 2. We would like to know the best way to support the multi lat long (without the copy happening) and get the values from multigeodist(). I have pushed up a good example, and I would like someone to please comment and maybe even show me some code to do that. There has been some discussions on this issue - my solution uses VS and it is fast. There might be faster and more simple ways to handle the N number of points. On another note, it is frustrating when David and I put in some time on this, and it sits out there with us "begging" for a committer to assist, and then when Grant starts discussions, it is summarility discarded with a new design without any input from the original contributors? Is this how we want to do things here? We should have Grant or Yonik work with David to get this patch done, Then we can discuss Spatial V2 and the design of it. Bill On Sat, Mar 26, 2011 at 7:19 PM, Chris Male <[email protected]> wrote: > > > On Sun, Mar 27, 2011 at 7:30 AM, Yonik Seeley <[email protected]> > wrote: >> >> On Sat, Mar 26, 2011 at 2:17 PM, Ryan McKinley <[email protected]> wrote: >> >>> >> >>> No, the question is: what justification is there for adding spatial >> >>> support to solr-only, leaving lucene with a broken contrib module, >> >>> versus adding it where it belongs and exposing it to solr? >> >> >> >> There need not be any linkage to lucene to improve a Solr feature. >> >> If you disagree, we should vote to clarify - this is too important >> >> (and too much of a negative for Solr). >> >> >> > >> > I don't think there is *requirement* to move the core spatial stuff to >> > lucene, but I think there is huge benefit to both communities if >> > things have as few dependencies as possible. To be frank, the spatial >> > support in solr is pretty hairy -- it works for some use cases, but is >> > not extendable and quite basic. Calling it 'distance' seems more >> > appropriate then 'spatial' >> >> >> Having something basic that works (and has a clean enough high level >> HTTP interface) was clearly a win for Solr users. >> >> Of course a more fully featured spatial module would be a win for >> everyone, but that's ignoring the more generic issue at hand here: >> a patch that improves Solr's spatial >> should not be blocked on the grounds that it does not improve Lucene's >> spatial enough. > > I don't think we need to see it that way, we want to improve both Solr and > Lucene's spatial support, not block either. As you say, having a module is > a win for everyone, Solr and Lucene alike, so it seems obvious that we > should go down that path and the code in SOLR-2155 would make a great first > addition. > >> >> Likewise, the ridiculous notion that "Queries don't belong in Solr" >> needs to be put to rest. > > Issues in and around this seem to be coming up a lot these days (I'm > thinking FunctionQuerys too). Sounds like something that really does need > to be openly discussed. > >> >> -Yonik >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Chris Male | Software Developer | JTeam BV.| www.jteam.nl > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
