[
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 is an updated patch.
* Check for null input range; swap in world-bounds.
* Add some static tests that don't use randomization (in addition to extensive
randomized one). They aren't much... but it's something.
And that's about it. I plan to commit this this weekend to trunk & 5x (which
means copying PrefixTreeFacetCounter from trunk along with this patch).
One thing i'm 50/50 on is the ordering of the heatmap counts (int[] counts).
The layout is column 1, column 2, ... etc.. Alternatively, perhaps the layout
should be row 1, row 2, row 3, .... It's arbitrary of course, and so I'm
inclined to let it be since it really doesn't matter. The the by-row layout
would feel more closely aligned with viewing one's screen and match the
orientation of some image/screen APIs that draw top->down.
> 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-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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
