[jira] [Commented] (SOLR-7005) facet.heatmap for spatial heatmap faceting on RPT

["David Smiley (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-7005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283948#comment-14283948 ] 

David Smiley commented on SOLR-7005:
------------------------------------

I really don't wan't to weigh down SimpleFacets any more than it is... so I will go the route that interval faceting did and put the code in a separate class and only put a modicum of hooks into FacetComponent and SimpleFacets.  As I write this, my working code in-progress is actually a separate SearchComponent that follows FacetComponent; it extends SimpleFacets to use some of its capability.  But it seems that if I'm going to use the facet namespace, I ought to hook in directly to FacetComponent; plus users need not register a separate component.  As always, I welcome input from other devs.

p.s. preliminary perf #'s are super promising.  Real numbers will be forthcoming later.  I envision real-time time-series heatmap movies being generated and displayed in the browser with thousands of cells of resolution per-frame.  

> facet.heatmap for spatial heatmap faceting on RPT
> -------------------------------------------------
>
>                 Key: SOLR-7005
>                 URL: https://issues.apache.org/jira/browse/SOLR-7005
>             Project: Solr
>          Issue Type: New Feature
>          Components: spatial
>            Reporter: David Smiley
>            Assignee: David Smiley
>             Fix For: 5.1
>
>
> This is a new feature that uses the new spatial Heatmap / 2D PrefixTree cell counter in Lucene spatial LUCENE-6191.  This is a form of faceting, and as-such I think it should live in the "facet" parameter namespace.  Here's what the parameters are:
> * facet=true
> * facet.heatmap=fieldname
> * facet.heatmap.bbox=\["-180 -90" TO "180 90"]
> * facet.heatmap.gridLevel=6
> * facet.heatmap.distErrPct=0.10
> Like other faceting features, the fieldName can have local-params to exclude filter queries or specify an output key.
> The bbox is optional; you get the whole world or you can specify a box or actually any shape that WKT supports (you get the bounding box of whatever you put).
> Ultimately, this feature needs to know the grid level, which together with the input shape will yield a certain number of cells.  You can specify gridLevel exactly, or don't and instead provide distErrPct which is computed like it is for the RPT field type as seen in the schema.  0.10 yielded ~4k cells but it'll vary.  There's also a facet.heatmap.maxCells safety net defaulting to 100k.  Exceed this and you get an error.
> The output is (JSON):
> {noformat}
> {gridLevel=6,columns=64,rows=64,minX=-180.0,maxX=180.0,minY=-90.0,maxY=90.0,counts=[[0, 0, 2, 1, ....],[1, 1, 3, 2, ...],...]}
> {noformat}
> counts is null if all would be 0.  Perhaps individual row arrays should likewise be null... I welcome feedback.
> I'm toying with an output format option in which you can specify a base-64'ed grayscale PNG.
> Obviously this should support sharded / distributed environments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org