Move Kibana map visualizations to geotile_grid

[alexfrancoeur]

Today, Region Maps and Coordinate Maps are utilizing the geohash_grid aggregation. In 7.0, @nyurik and the Elasticsearch team will be introducing a new aggregation that provides a much better experience when visualizing geospatial data on a map. This is called geotile_grid and the PR for it can be found here: elastic/elasticsearch#37842.

For the Maps app, we will be defaulting to the geotile_grid aggregation in 7.0 but will be using geohash_grid in 6.7. While this could be considered a breaking change, the app will still be in beta so we're less concerned about making this change.

For the map visualizations, there are a number of existing maps already created that are utilizing the geohash_grid aggregation. Making the switch in a point release could be considered a breaking change and at this point, it is not something we can squeeze into 7.0.

I'd like to propose the following approach for discussion.

1. Deprecate using geohash_grid in 7.x
2. Offer geotile_grid as an option in the aggregation dropdown when selecting the aggregations to use
3. Default to geotile_grid for new map visualizations
4. In 8.0, default to geotile_grid for all visualizations and stop supporting geohash_grid in Kibana

That all being said, I'm not sure I fully grasp the differences between the two aggregations. The buckets will be different but I'm not sure how much of an impact it will have on existing users if we were to make the switch, or how different the results will be when compared. I imagine the results returned are different enough that we can't change the aggregations in a point release. If we thinking it's minimal then it is worth having that discussion. geotile_grid is a better aggregation to use overall.

cc: @stacey-gammon @AlonaNadler

[elasticmachine]

Pinging @elastic/kibana-gis

[elasticmachine]

Pinging @elastic/kibana-app

[talevy]

You may already be aware, but I don't see this mentioned, so I thought I would share it.

The buckets will be different but I'm not sure how much of an impact it will have on existing users if we were to make the switch, or how different the results will be when compared

I don't think the impact will be too stark. Generally, there should be a rough equation for translating the previous precision value to the new aggregation's equivalent precision. This will result in roughly the same number of buckets, and visualization.

There may be a few (probably not a lot) customers with data that had previously hit close to our default 10k bucket limit, and maybe our conversion leads to slightly more than 10k buckets. These are the only scenarios where I would expect behavior to break. One fallback is to catch this, and have a retry to reduce the precision one step.

[nyurik]

Note that geotile_grid precision goes 0..29, whereas geohash_grid precision is in range of 1..12. Each geohash_grid precision level equals exactly to 2.5 zoom levels of geotile_grid, so every other geohash precision falls right in-between the integer zoom.

In geohash_grid, an increase in precision by 1 is equivalent to one base-32 digit. E.g. precision=2 breaks the world into 32^2 = 1024 buckets. For geotile_grid, each precision equates to one base-4 digit, so precision=5 produces the same 4^5 = 1024 buckets. Thus, geohash_grid p=2 has the same number of buckets as geotile_grid p=5. The next equivalent match is geohash p=4 vs geotile p=10, etc.

Odd geohash precisions have no corresponding integer zoom number. Also note that this meant zooming with geohash was more "jerky" - it would only get new result every 2.5 zoom levels, not on every zoom.

[thomasneirynck]

to add to @nyurik's comment:

This is the mapping used by Kibana from geotile_grid (zoomlevel) -> geohash_precision

https://github.com/elastic/kibana/blob/6.7/x-pack/plugins/maps/public/shared/layers/sources/es_geo_grid_source/zoom_to_precision.js

It's based on a heuristic so that the geohash-cell is never smaller than 16 pixels for any given zoom-level. It assumes a 256x256px world-size at level 0.

It's indeed possible that we just have more requests during panning and zooming when using geo_tiles. But it results in a more consistent and smoother experience without weird visual artifacts of the aspect ratio of cells constantly switching. It is worth the trade-off.

[thomasneirynck]

I'll close this, as it's unlikely we'll make this mod to the coordinate map visualizations, as Kibana Maps is approaching feature parity.