SQL: Add ST_Z function

[imotov]

Adds support for the ST_Z function that returns the altitude of the
first point in a shape.

At the moment ST_Z functionality is quite limited since we are
not storing it in geo_point doc values and geo_shape doesn't
support doc values at the moment. So, this function cannot
be used in the query or aggregation contexts.

Relates to #29872

[elasticmachine]

Pinging @elastic/es-analytics-geo

[elasticmachine]

Pinging @elastic/es-search

[matriv]

LGTM, Should we add the limitation to the docs limitations page?

[astefan]

LGTM in general. Left two minor comments.
Also, I would have expected to see more tests for this function. Unless I'm missing something, atm there is only the one: the one used in docs.

[astefan]

Typo: two "the".

[astefan]

I would have added, instead of this short statement that seems to have the same purpose as the *Output*: double from above: Returns the altitude of the first point in the geometry as a double type number.

[astefan]

Also, you need to add the new function to the functions' index page: https://github.com/elastic/elasticsearch/blob/geosql/docs/reference/sql/functions/index.asciidoc

[astefan]

And a new test (or modify the existent one) should be added to https://github.com/elastic/elasticsearch/blob/geosql/x-pack/plugin/sql/src/test/java/org/elasticsearch/xpack/sql/planner/QueryTranslatorTests.java.

[imotov]

@astefan I didn't add any QueryTranslatorTests for ST_Z because as I mentioned in the description, it doesn't work in the query context. It generates a query, but this query has no chances of succeeding, which is wrong. This happens because we don't have doc values for shapes and altitudes and as a result we cannot access this information in a query. It is a common usability issue for all ST_* functions that I am planning to tackle next. I opened #41791 to track it. @matriv I will also describe these limitations as part of the issue, just need to find a good spot for it.

[costin]

"this function cannot be used in the query or aggregation contexts"
This can be addressed by adding a validation rule to verify that the functions appear only inside a projection and nowhere else (similar to what we do with SCORE).
Considering this is not released yet (will it be part of 7.1?), it can be addressed in a separate PR.

[costin]

Left a comment.

[imotov]

"this function cannot be used in the query or aggregation contexts"

I need to revise this statement. II think I formulated it too strongly. The function can appear in the query context, but it cannot work on fields because we don't have access to source in this contexts. For example, SELECT * FROM foo WHERE some_z > ST_Z(ST_WKTTOSQL('POINT(1 2 3)'); is is somewhat meaningless, but perfectly fine way to use it. Basically the problem is not in ST_Z, but the problem is in geoDocValue() that is generated as part all functions. This shouldn't happen for geo_shapes since they don't have doc_values yet.

Considering this is not released yet (will it be part of 7.1?), it can be addressed in a separate PR.

It's too late for 7.1 I am targeting 7.2 at the moment, I will merge PR that addresses this issue before opening a PR to merge the branch to master and 7.x.

[astefan]

LGTM