[
https://issues.apache.org/jira/browse/LUCENE-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283980#comment-14283980
]
Nicholas Knize commented on LUCENE-6191:
----------------------------------------
Lookin good [~dsmiley] I like this approach and the first-cut implementation.
For completeness it might be worthwhile to add some systematic unit tests with
complex shapes (i.e., dateline and/or pole crossing polys w/ multiple holes)
just to validate/verify expected behavior along coordinate system boundary
conditions and to assess the possibility for false positives/negatives (which
could be detrimental to some spatial analysis applications).
Re: the former, I have patches for correcting polygonal ambiguity that will
eventually make their way into either Spatial4J or Lucene-Spatial. The timing
will just depend on our ES feature release schedule.
> 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]
