Thanks for the help David, makes sense. I found a workaround, creating much
smaller rectangles and updating them more often.Glad to have this
functionality, thanks again!Eric.
> Date: Fri, 12 Oct 2012 21:06:52 -0700
> From: dsmi...@mitre.org
> To: solr-user@lucene.apache.org
> Subject: Re: Issue using SpatialRecursivePrefixTreeFieldType
>
> Hi again Eric,
> I could see this unusual use-case of Lucene/Solr spatial really stressing
> it out. When you say that you "create a rectangle", I figure you mean at
> indexing time -- I'm pretty confident searches are going to be quick in
> nearly any scenario. At indexing time, yes, it'll basically overlay your
> big rectangle on a stack of matrixes (i.e. grids) of different sizes. In
> the middle of your rectangle, there are going to be large indexed rectangles
> that efficiently cover a lot of space, but there are going to be more and
> more and more smaller rectangles towards the edge of your rectangle at
> increasing precision. For your case here, I wouldn't be surprised if it
> wanted to generate hundreds of thousands of grid cells which isn't going to
> scale at all. "Normally" (in a geospatial context) distErrPct is non-zero
> and so your shape is approximated -- it will only generate smaller and
> smaller grid cells at the edges up until a threshold, relative the the
> overall size of the shape. Approximating geospatial areas is normal since
> say a polygon is not going to truly be infinitely precise as the digits you
> give the coordinates. But for you... well I don't know if your use case
> allows the rectangle edges to be approximated but even if you said that'd be
> fine, solr.SpatialRecursivePrefixTreeFieldType will use the same
> approximation measure for both dimensions, meaning the max-y of 11 will
> probably be pushed off into the tens or hundreds of thousands due to the
> max-x being 5 million.
> So... I can think of how to solve this if I had lots of time to work on it
> but I don't. What I'm about to write is mostly for me if I look back on
> this. What I'd do is use solr.SpatialRecursivePrefixTreeFieldType with a
> default approximating distErrPct such that this field acts as a fast
> approximating filter. But then I'd need something to weed out the
> false-positive hits and that would be a job for a different spatial
> strategy. Over here: https://github.com/ryantxu/spatial-solr-sandbox in
> "LSE" there is a JtsGeometryStrategy which will do perfectly accurate
> spatial matching, but it's not really "indexed" (it isn't fast at all).
> That one is a bit experimental now but I think it works ( I didn't write it
> or use it, Ryan McKinley did ) or it at least should with minor
> modification. Simply using both strategies together isn't enough, since it
> won't be fast enough if your query shapes are big. I think the technologies
> in both of these could be combined such that only the approximating final
> leaves of the prefix tree are then passed to the JTS strategy, as opposed to
> all matching shapes in the middle of the query shape which are known to
> match with confidence.
>
> ~ David
>
>
>
> -----
> Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Solr-4-0-Join-performance-tp3998827p4013521.html
> Sent from the Solr - User mailing list archive at Nabble.com.
