[
https://issues.apache.org/jira/browse/LUCENE-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated LUCENE-6191:
---------------------------------
Attachment: LUCENE-6191__Spatial_heatmap.patch
This new feature works for not just points but any shape in the grid (e.g.
polygons, lines, whatever). Remember that all non-point shapes are
approximated to the grid at indexing time. So if you ask for a detailed
heatmap on the edge of an indexed shape, the detail of that shape isn't going
to magically be more detailed than whatever it was determined to be at indexing
time.
Dateline spanning heatmaps _are_ supported.
In the patch, the code is in HeatmapFacetCounter, a static utility class with a
"Heatmap" inner class to hold the response data comprised of the column count,
row count, an int[] of counts, and the rectangular region of where this heatmap
is. And of course there's a test, one that uses randomized testing extensively.
I'm tempted to add a method to PrefixTreeStrategy calcFacets2D or calcHeatmap
or something like that which simply calls through to this class.
> Spatial 2D faceting (heatmaps)
> ------------------------------
>
> Key: LUCENE-6191
> URL: https://issues.apache.org/jira/browse/LUCENE-6191
> Project: Lucene - Core
> Issue Type: New Feature
> Components: modules/spatial
> Reporter: David Smiley
> Assignee: David Smiley
> Fix For: 5.1
>
> Attachments: LUCENE-6191__Spatial_heatmap.patch
>
>
> Lucene spatial's PrefixTree (grid) based strategies index data in a way
> highly amenable to faceting on grids cells to compute a so-called _heatmap_.
> The underlying code in this patch uses the PrefixTreeFacetCounter utility
> class which was recently refactored out of faceting for NumberRangePrefixTree
> LUCENE-5735. At a low level, the terms (== grid cells) are navigated
> per-segment, forward only with TermsEnum.seek, so it's pretty quick and
> furthermore requires no extra caches & no docvalues. Ideally you should use
> QuadPrefixTree (or Flex once it comes out) to maximize the number grid levels
> which in turn maximizes the fidelity of choices when you ask for a grid
> covering a region. Conveniently, the provided capability returns the data in
> a 2-D grid of counts, so the caller needn't know a thing about how the data
> is encoded in the prefix tree. Well almost... at this point they need to
> provide a grid level, but I'll soon provide a means of deriving the grid
> level based on a min/max cell count.
> I recommend QuadPrefixTree with geo=false so that you can provide a square
> world-bounds (360x360 degrees), which means square grid cells which are more
> desirable to display than rectangular cells.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
