Rasterize shape during geotilegrid computation

[talevy]

This PR mainly modifies the existing GeoTileGridTiler to rasterize
the GeometryTree instead of iterating through all the tiles found in the
bounding box of the shape.

This PR also fixes a bug where containsFully was not being calculated correctly

relates #37206.

[elasticmachine]

Pinging @elastic/es-analytics-geo (:Analytics/Geo)

[iverase]

Thanks @talevy! One thing I was expecting is just one method that returns the relationship between the docValue and the Extent, something like:

Relation relate(Extent extent);

Instead you are using two methods, one for within and one for intersects, is there any technical reason for doing that?

[talevy]

I started with this route just to make sure the logic was right since conflating both intersects and within in the same method would have made things rather complicated.

two technical reasons for splitting:

• simpler code
• intersects can exit early while within requires a full tree traversal.

Main reason to join the two

• The GeoTileGridTiler#setValuesForCell code first calls within and then falls back to intersects. Combining both into a relate would make this go faster since right now there is unnecessary duplicate de-serialization and traversal.

Since the only callers of these methods are the tilers, then maybe combining makes sense. I will try it out and see how it affects performance 👍

[talevy]

One example of where it may be nice to have separate within/intersects is with the planned hexgrid aggregation where within is likely never to be asked:

example photo demonstrating how the sub-tiles are not fully within the parent tile: http://1fykyq3mdn5r21tpna3wkdyi-wpengine.netdna-ssl.com/wp-content/uploads/2018/06/image6-1.png

[iverase]

This approach will not work for hex grid as a parent cell must contain all the children cells. You can have a shape that is disjoint with the parent cell but intersects a children cell.

[talevy]

right, there is no concept of "within" in that case. I don't bring it up in the context of rasterization, but just in the context of keeping intersect and within separate.

[iverase]

I added a note where we can improve slightly things but not needed for this PR. I think this is an massive improvement so lgtm.

[iverase]

I think we can move the check of the extent here. Not needed for this PR but I think it is worthy to note.

[talevy]

I agree. consolidating to one relating method reduces the places that there is an extent check. I will follow-up