>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 http://www.linkedin.com/in/davidwsmiley On Thu, Nov 6, 2014 at 8:44 AM, Shahak Nagiel <snag...@yahoo.com> wrote: > Thanks, David. In the meantime, care to share any thoughts about your > planned implementation? > > > On Thursday, November 6, 2014 8:11 AM, "david.w.smi...@gmail.com" < > david.w.smi...@gmail.com> wrote: > > > FYI I plan to implement this in Lucene-spatial & Solr in January. > > ~ David Smiley > Freelance Apache Lucene/Solr Search Consultant/Developer > http://www.linkedin.com/in/davidwsmiley > > On Wed, Nov 5, 2014 at 10:52 PM, Shahak Nagiel <snag...@yahoo.com.invalid> > 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! > > > > >
