[
https://issues.apache.org/jira/browse/SOLR-7005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-7005:
-------------------------------
Description:
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.geom=\["-180 -90" TO "180 90"]
* facet.heatmap.gridLevel=6
* facet.heatmap.distErrPct=0.15
* facet.heatmap.format=ints2D | png
(Officially see FacetParams where options are documented)
Like other faceting features, the fieldName can have local-params to exclude
filter queries or specify an output key. This could be quite useful in doing
difference faceting on the same spatial data to identify relative change
against a baseline.
The {{geom}} is optional; you get the whole world or you can specify a box or
WKT.
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_ints2D=[[0,
0, 2, 1, ....],[1, 1, 3, 2, ...],...]}
{noformat}
counts_ints2D is null if all would be 0. individual row arrays should likewise
be null... I welcome feedback.
If you set the output to 'png' then you get a 4-byte per pixel/cell PNG, or
null if all counts are 0. The high byte (alpha channel) is inverted so that
counts need to exceed 2^24 before the image will start to fade out if you try
and view it.
This supports sharded / distributed queries.
was:
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.
> 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
>
> Attachments: SOLR-7005_heatmap.patch, SOLR-7005_heatmap.patch,
> SOLR-7005_heatmap.patch, SOLR-7005_heatmap.patch, heatmap_512x256.png,
> heatmap_64x32.png
>
>
> 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.geom=\["-180 -90" TO "180 90"]
> * facet.heatmap.gridLevel=6
> * facet.heatmap.distErrPct=0.15
> * facet.heatmap.format=ints2D | png
> (Officially see FacetParams where options are documented)
> Like other faceting features, the fieldName can have local-params to exclude
> filter queries or specify an output key. This could be quite useful in doing
> difference faceting on the same spatial data to identify relative change
> against a baseline.
> The {{geom}} is optional; you get the whole world or you can specify a box or
> WKT.
> 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_ints2D=[[0,
> 0, 2, 1, ....],[1, 1, 3, 2, ...],...]}
> {noformat}
> counts_ints2D is null if all would be 0. individual row arrays should
> likewise be null... I welcome feedback.
> If you set the output to 'png' then you get a 4-byte per pixel/cell PNG, or
> null if all counts are 0. The high byte (alpha channel) is inverted so that
> counts need to exceed 2^24 before the image will start to fade out if you try
> and view it.
> This supports sharded / distributed queries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
