Sean, The JTeam code looks like it is based on an older version of the Local Lucene code. The Lucene code appears to do a bit of sanity checking that is not currently done in the JTeam code.
The problem also seems to happen more often with positive lat/long values (as noted by Mauricio). I ran the same test on two sets of data, one searching progressively outward from a point in the US and from one in Russia. The Russia test showed the inconsistent results while the U.S. didn't. Mike D. On Wed, Mar 31, 2010 at 4:57 PM, Mccleese, Sean W (388A) <sean.w.mccle...@jpl.nasa.gov> wrote: > Michael, > > This was a problem I encountered as well, sometime late summer last year. My > memory is a bit hazy on the details, but as far as I remember the problem > centered around the tier level being set incorrectly. Additionally, I think > there's a JUnit test (perhaps CartesianShapeFilterTest?) that would indicate > the source of the problem but large sections of the test are > invalidated/commented out for the spatial change(s). > > Again, I haven't touched this code in several months but that's my > recollection on the issue. Either way, it's certainly not an isolated > problem, though my test datasets were also sparse and geographically distant. > > -Sean > > ------ Forwarded Message > From: Michael <solrco...@gmail.com> > Reply-To: <solr-user@lucene.apache.org> > Date: Wed, 31 Mar 2010 13:33:39 -0700 > To: <solr-user@lucene.apache.org> > Subject: Re: Spatial / Local Solr radius > > Mauricio, > > I hooked up the spatial solr plugin to the Eclipse debugger and > narrowed the problem down to CartesianShapeFilter.getBoxShape(). The > algorithm used in the method can produce values of startX that are > greater than endX depending on the tier level returned by > CartesianTierPlotter.bestFit(). In this case, the "for" loop is > skipped altogether and the method returns a CartesianShape object with > an empty boxIds list. > > I notice the problem when I have small, geographically sparse datasets. > > I'm going to shoot the jteam an email regarding this. > > Michael D. > > > On Tue, Mar 30, 2010 at 5:10 PM, Mauricio Scheffer > <mauricioschef...@gmail.com> wrote: >> Hi Michael >> >> I exchanged a few mails with jteam, ultimately I realized my longitudes' >> signs were inverted so I was mapping to China instead of U.S. Still a bug, >> but inverting those longitudes "fixed" the problem in my case since I'm not >> running world-wide searches. >> Before that I ran a test to determine what radii failed for a grid of 3x3 >> lat/long with radius between 10 and 2500, if you're interested I can send >> you the results to compare. >> Also I'm running RC3, I see RC4 is out but haven't tried it. >> It would be interesting to see if this happens with the new spatial >> functions in trunk. >> >> -- >> Mauricio >> >> >> On Tue, Mar 30, 2010 at 4:00 PM, Michael <solrco...@gmail.com> wrote: >> >>> Mauricio, >>> >>> I was wondering whether you had heard anything back from jteam >>> regarding this issue. I have also noticed it and was wondering why It >>> was happening. >>> >>> One thing I noticed is that this problem only appears for "sparse" >>> datasets as compared to "dense" ones. For example, I have two datasets >>> I've been testing with - one with 56 U.S. cities (the "sparse" set) >>> and one with over 197000 towns and cities (the "dense" set). The dense >>> set exhibited no problems with consistency searching at various radii, >>> but the sparse set exhibited the same issues you experienced. >>> >>> Michael D. >>> >>> On Mon, Dec 28, 2009 at 7:39 PM, Mauricio Scheffer >>> <mauricioschef...@gmail.com> wrote: >>> > It's jteam's plugin ( http://www.jteam.nl/news/spatialsolr ) which AFAIK >>> is >>> > just the latest patch for SOLR-773 packaged as a stand-alone plugin. >>> > >>> > I'll try to contact jteam directly. >>> > >>> > Thanks >>> > Mauricio >>> > >>> > On Mon, Dec 28, 2009 at 8:02 PM, Grant Ingersoll <gsing...@apache.org >>> >wrote: >>> > >>> >> >>> >> On Dec 28, 2009, at 11:47 AM, Mauricio Scheffer wrote: >>> >> >>> >> > q={!spatial lat=43.705 long=116.3635 radius=100}*:* >>> >> >>> >> What's QParser is the "spatial" plugin? I don't know of any such QParser >>> in >>> >> Solr. Is this a third party tool? If so, I'd suggest asking on that >>> list. >>> >> >>> >> > >>> >> > with no other parameters. >>> >> > When changing the radius to 250 I get no results. >>> >> > >>> >> > In my config I have startTier = 9 and endTier = 17 (default values) >>> >> > >>> >> > >>> >> > On Mon, Dec 28, 2009 at 1:24 PM, Grant Ingersoll <gsi...@gmail.com> >>> >> wrote: >>> >> > >>> >> >> What do your queries look like? >>> >> >> >>> >> >> On Dec 28, 2009, at 9:30 AM, Mauricio Scheffer wrote: >>> >> >> >>> >> >>> Hi everyone, >>> >> >>> I'm getting inconsistent behavior from Spatial Solr when searching >>> with >>> >> >>> different radii. For the same lat/long I get: >>> >> >>> >>> >> >>> radius=1 -> 1 result >>> >> >>> radius=10 -> 0 result >>> >> >>> radius=25 -> 2 results >>> >> >>> radius=100 -> 2 results >>> >> >>> radius=250 -> 0 results >>> >> >>> >>> >> >>> I don't understand why radius=10 and 250 return no results. Is this >>> a >>> >> >> known >>> >> >>> bug? I'm using the default configuration as specified in the PDF. >>> >> >>> BTW I also tried LocalSolr with the same results. >>> >> >>> >>> >> >>> Thanks >>> >> >>> Mauricio >>> >> >> >>> >> >> >>> >> >>> >> -------------------------- >>> >> Grant Ingersoll >>> >> http://www.lucidimagination.com/ >>> >> >>> >> Search the Lucene ecosystem using Solr/Lucene: >>> >> http://www.lucidimagination.com/search >>> >> >>> >> >>> > >>> >> > > > ------ End of Forwarded Message > >
