lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: Lucene spatial for grid clusters
Date Thu, 06 Nov 2014 14:17:54 GMT
>From an API standpoint, I envision you would supply a rectangular region of
interest and some means of specifying the resolution.  It could be the
so-called “grid level” in lucene spatial (1 is biggest most coarsest,
larger numbers yield progressively smaller cells), or it might be expressed
in terms of the minimum number of cells you want.  The response would
include the *actual* rectangular region of the grid that minimally encloses
the region you asked for.  And it would include the width and height of the
cells at this resolution, and the grid level (a #).  Of course it would
include the 2D grid of numbers.  On the Solr side, I’m thinking of
optionally returning a PNG, but I’m not sure if that will turn out to be a
good idea or not.

The implementation will re-use a lot of code already in Lucene-spatial.  In
particular, it will *not* be necessary to write any low-level TermsEnum
iteration code because it can
re-use AbstractVisitingPrefixTreeFilter.VisitorTemplate.  I am in fact
dog-fooding that now because I’m currently working on date-rage faceting of
a DateRangePrefixTree (it’s in trunk).  This is a single-dimensional
heatmap capability.  I’ll tell attendees of my talk about this at
Lucene/Solr Revolution next Friday in DC.

~ David Smiley
Freelance Apache Lucene/Solr Search Consultant/Developer

On Thu, Nov 6, 2014 at 8:44 AM, Shahak Nagiel <> wrote:

> Thanks, David.  In the meantime, care to share any thoughts about your
> planned implementation?
>   On Thursday, November 6, 2014 8:11 AM, "" <
>> wrote:
> FYI I plan to implement this in Lucene-spatial & Solr in January.
> ~ David Smiley
> Freelance Apache Lucene/Solr Search Consultant/Developer
> On Wed, Nov 5, 2014 at 10:52 PM, Shahak Nagiel <>
> wrote:
> I need a way to perform a spatial aggregation query against a potentially
> large document store in order to display summary clusters on a map.  The
> query would slice the current map extents (e.g. -180,-90,180,90) into a
> number of X and Y bins (e.g. 20 x 16) and, for each, seek a summary count,
> so that a heat map or series of clusters could be rendered for the grids.
> Given Lucene's native usage of prefix trees/geohashes, this seems to be a
> good fit.  As a user pans and zooms the map, new map extents would apply,
> so this would need to support dynamic grids.  However, snapping
> results/bins to existing geohashes (of the appropriate depth/level) would
> be fine, assuming that lines up with how the indexes are structured.
> Naively, I could just issue a series of spatial queries, one for each
> grid, and get the count.  But I wonder if there's a better way...
> Has anyone encountered this use case?  Any suggestions on the best/most
> efficient way to achieve?
> Thanks!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message