[
https://issues.apache.org/jira/browse/LUCENE-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14284369#comment-14284369
]
Nicholas Knize edited comment on LUCENE-6191 at 1/20/15 8:39 PM:
-----------------------------------------------------------------
bq. Unless I'm misunderstanding you, what you say is one in the same with
documenting the resolution of grid cells of the SPT you choose
Spatial resolution is part of the equation. I was referring to the percent
error of the facet results. With overlapping polys, for example. At level _n_
the boundaries of polys _A:F_ intersect a grid cell but are contained within
polys _G:J_. At level _n_ the facet count returns 4 (for _G:J_) but at level
_n+1_ returns 10 (for _A:J_) - a 60% error at level _n_. It might be nice to
include percent error as a part of the results. If the heatmap is converted to
a thematic intensity map those grid cells will underestimate ground truth. By
including percent error (or even the residuals) RMS could be computed and
provided at the varying zoom levels.
"98% of statistics is made up" :)
was (Author: nknize):
.bq Unless I'm misunderstanding you, what you say is one in the same with
documenting the resolution of grid cells of the SPT you choose
Spatial resolution is part of the equation. I was referring to the percent
error of the facet results. With overlapping polys, for example. At level _n_
the boundaries of polys _A:F_ intersect a grid cell but are contained within
polys _G:J_. At level _n_ the facet count returns 4 (for _G:J_) but at level
_n+1_ returns 10 (for _A:J_) - a 60% error at level _n_. It might be nice to
include percent error as a part of the results. If the heatmap is converted to
a thematic intensity map those grid cells will underestimate ground truth. By
including percent error (or even the residuals) RMS could be computed and
provided at the varying zoom levels.
"98% of statistics is made up" :)
> 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]
