Adds ST_SIMPLIFY geo spatial function

[ncordon]

Adds ST_SIMPLIFY geo spatial function, which simplifies a geo-shape using the Douglas Peuker algorithm. Inspiration taken from the Postgres corresponding function

It can be tested as:

ROW geo_shape = TO_GEOSHAPE("POLYGON((0 0, 1 0.1, 2 0, 2 2, 1 1.9, 0 2, 0 0))") 
| EVAL result = st_simplify(geo_shape, 2)
| KEEP result
;

Its first argument is the geo shape to simplify, its second argument is a tolerance that must be non-negative and could be either an integer or a double.

Closes #44747

[elasticsearchmachine]

Hi @ncordon, I've created a changelog YAML for you.

[elasticsearchmachine]

Hi @ncordon, I've updated the changelog YAML for you.

[github-actions]

🔍 Preview links for changed docs

• docs/reference/query-languages/esql/kibana/docs/functions/st_simplify.md
• docs/reference/query-languages/esql/functions-operators/spatial-functions.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

[craigtaverner]

Looks great!

[craigtaverner]

I think we can fix this in a followup PR

[craigtaverner]

LGTM. I have some comments, nothing critical. A bit nervous about the change to SpatialDocValuesExtraction.java‎

[craigtaverner]

Oh, interesting. I was planning to expand the search to more than geogrid functions, but did not expect to do that so early. The goal initially was to only search for geogrid functions, but then if we do decide to use doc-values, apply that to all functions. My PR expands a lot the list of functions to apply to, but does not expand the list of functions to search. The reason for this is geogrid functions have a canonical use case of calculating the grid and using it in the BY clause of the stats command. That means this is a key feature, and a hot path. For other functions it is mostly odd edge cases that would benefit from this, but they all to support it if triggered by geogrid functions.

[craigtaverner]

All of the functions that would be affected by this decision are in tech-preview, and it could be argued that doing this for all is no more risky than doing it for grid functions only.

[craigtaverner]

With the logic I was expecting in the SpatialDocValuesExtraction class, I would have only expected to see ST_SIMPLIFY using doc-values if used together with a geogrid function. This test of course tests something else, that ST_SIMPLIFY itself can trigger the use of doc-values.

[craigtaverner]

If we wrote a test with STATS instead of SORT, then we would not need keep-location. Better still, have both tests, one with STATS and one with SORT and keep-location.

[craigtaverner]

This code does not consider the case when spatialDocValues==true, but the datatype is not a point. That would indicate a planner bug, so understand that it is not here. Having it would, however, lead to a nicer error message. The message we get otherwise is the block ClassCastException which can be a bit cryptic. On the other hand, most times I've seen that error have been when we don't have these evaluators at all.