Bugfix to doc-values and multi-value support in spatial functions (ST_ENVELOPE, ST_XMAX, etc.)

[craigtaverner]

The optimization for doc-values extration for geo-grid functions at #138917 expanded the range of scenarios under which doc-values can be extracted, and exposed a pre-existing bug that was previous unlikely to be found, but now much more likely to be noticed. The above PR actually did fix this issue, but did not cover all possible cases. The issue was that if the original geo_point field was returned to the coordinator, it would be in a LongBlock and not understood by any coordinator level functions (since the doc-values optimization only works on data nodes). Previously this was very, very unlikely to be encountered by a user, because the doc-values optimization would only trigger with spatial aggregations, like ST_EXTENT_AGG or ST_CENTROID_AGG, which consume the original point and do not return it unless it is used in the BY clause:

FROM airports
| STATS centroid = ST_CENTROID_AGG(location) BY location

Such a query is not useful and would likely never by typed by a user. However, with the geo-grid optimization, since that is not an aggregating function, we expanded the range of cases where the doc-values extraction can occur to a much wider set, including before SORT functions. However, this makes it much easier for a user to create a failing query, for example:

FROM airports
| EVAL grid = ST_GEOHEX(location, 4)
| SORT x

The geo-grid optimization at #138917 did fix this scenario, by requiring that the original geo_point field is not returned, so the optimization would only work if the user dropped that field:

FROM airports
| EVAL grid = ST_GEOHEX(location, 4)
| DROP location
| SORT x

At first, this looks sufficient. But what was missing was the fact that other spatial functions could be included in the EVAL, and they would not be able to support the extracted doc-values.

FROM airports
| EVAL grid = ST_GEOHEX(location, 4), x = ST_X(location)
| DROP location
| SORT x

This new bug-fix makes sure that all spatial functions can be made doc-values aware, as well as work consistently with multi-valued fields. It is based on the work at #139618, but with the ST_NPOINTS and ST_SIMPLIFY features extracted, leaving only bug-fixes:

• Made ST_ENVELOPE, ST_XMAX, etc. multi-value aware
• Refactored doc-values support (so ST_ENVELOPE, ST_XMAX, etc. and all geogrid functions are similar)

This is a partial back-port of #139618, which fixed the mv and doc-values issues in main, but also added ST_NPOINTS. This is now a bug-fix only PR, with all support for ST_NPOINTS and ST_SIMPLIFY removed, so 9.3.0 only gets the bugfix and no new features.

[github-actions]

🔍 Preview links for changed docs

• docs/reference/query-languages/esql/functions-operators/spatial-functions.md
• docs/reference/query-languages/esql/kibana/docs/functions/st_x.md
• docs/reference/query-languages/esql/kibana/docs/functions/st_y.md

[github-actions]

ℹ️ Important: Docs version tagging

👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version.

We use applies_to tags to mark version-specific features and changes.

Expand for a quick overview

When to use applies_to tags:

✅ At the page level to indicate which products/deployments the content applies to (mandatory)
✅ When features change state (e.g. preview, ga) in a specific version
✅ When availability differs across deployments and environments

What NOT to do:

❌ Don't remove or replace information that applies to an older version
❌ Don't add new information that applies to a specific version without an applies_to tag
❌ Don't forget that applies_to tags can be used at the page, section, and inline level

🤔 Need help?

• Check out the cumulative docs guidelines
• Reach out in the #docs Slack channel