[Maps] Add support for additional aggregations and fields for geohash & boundary layers

[alexfrancoeur]

Similar to to the Elasticsearch documents capabilities we offer to provide additional context to a tooltip, I think our users would like to add additional aggregations and fields when creating an aggregated layer. This will help provide additional context to the layer in the same tooltip.

Elasticsearch documents:

[elasticmachine]

Pinging @elastic/kibana-gis

[nreese]

@alexfrancoeur Can you clarify this request? You can already add additional metric aggregations.

It is not possible to add field values since raw documents are not getting returned.

[alexfrancoeur]

@nreese yes sorry, I didn't mean raw field values just additional aggregations of fields available. Though I could see how string field values in an array may be valuable as well.

At first, I was specifically only looking at the heatmap visualization.

Upon further investigation, the Metrics options only seems to be available for the points and grid visualizations of the geohash agg. Would it be possible to add for heatmap as well as any region layers?

Also, we may want to involve @gchaps here to provide more context around what the primary metric is and what the secondary metrics are.

[nreese]

Upon further investigation, the Metrics options only seems to be available for the points and grid visualizations of the geohash agg. Would it be possible to add for heatmap as well as any region layers?

@thomasneirynck could probably explain better but this was done on purpose because the heat map combines geohash grid counts to produce the heatmap effect. The combining of values does not make sense with other metric values and the the tooltip is not showing you one grid cell but potentially numerous grid cells.

[nreese]

I didn't mean raw field values just additional aggregations of fields available. Though I could see how string field values in an array may be valuable as well.

I like the idea of showing the results of another aggregation run against the grid cell. Like running a terms aggregation to see the top 10 terms for the cell. I think this would work better than showing raw documents values since the grid cell could represent the results of lots of documents and fetching documents would not scale.

[alexfrancoeur]

@thomasneirynck could probably explain better but this was done on purpose because the heat map combines geohash grid counts to produce the heatmap effect. The combining of values does not make sense with other metric values and the the tooltip is not showing you one grid cell but potentially numerous grid cells.

Related to the quote / response below, couldn't we add a section for "contextual metrics" or something. The heatmap would still be the primary aggregation whereas the secondary metrics would be providing context to that metric, not affecting the visualization at all. If the heatmap is truly that much different than other the grid or point views then that's fine.

I like the idea of showing the results of another aggregation run against the grid cell. Like running a terms aggregation to see the top 10 terms for the cell. I think this would work better than showing raw documents values since the grid cell could represent the results of lots of documents and fetching documents would not scale.

++ I agree, I'd love to see this and believe we have documented ER's around similar requests. Anything to provide additional context without having to add an additional layer would be beneficial to our users.

[thomasneirynck]

I think for the heatmap layer, we could provide additional metrics, but imho these should be limited to things that are countable, like "sum" or "count", because they give an idea of density of some feature in a given area (which is what heatmaps are for). When you show "averages" or "minimum" values on a heatmap, and those color-blobs start to blend, you really have no idea what you're looking at (ie. what does blending of two "minimum"-values mean???). We can do that sort of styling much better with grid-cells or bubbles, where we are not "blending" values, but just discretely style a polygon or a circle.

+1 on additional aggregations on cells.

[thomasneirynck]

consider embedding visualizations/saved-searches. this would capture most use-cases

e.g. data-table with query, saved-search, ...

[alexfrancoeur]

++ agreed, but we do have ER's around this for our existing visualizations so I'd like to keep this open. I definitely see the value here, that is also a large reason why @nreese enhanced tilemap plugin is so popular. Additional context.

[nreese]

@alexfrancoeur Can this be closed with #57875?

[nreese]

Closed with #57875.