Add support to VALUES aggregation for spatial types #122886
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
craigtaverner
added
>bug
Team:Analytics
Collaborator
|
Pinging @elastic/es-analytical-engine (Team:Analytics) |
Collaborator
|
Hi @craigtaverner, I've created a changelog YAML for you. |
craigtaverner
commented
Feb 18, 2025
| return isType(e, DataType::isSpatial, operationName, paramOrd, SPATIAL_TYPE_NAMES); | ||
| } | ||
|
|
||
| public static Expression.TypeResolution isNotSpatial(Expression e, String operationName, TypeResolutions.ParamOrdinal paramOrd) { |
Contributor
Author
There was a problem hiding this comment.
This function was never used anyway
…search into agg_values_spatial
Contributor
|
Warning It looks like this PR modifies one or more |
Contributor
|
Warning It looks like this PR modifies one or more |
We run older yaml tests, but they make assertions that are not longer valid and so we need to exclude those tests using task.skipTest
Contributor
|
Warning It looks like this PR modifies one or more |
nik9000
reviewed
Feb 20, 2025
|
|
||
| protected static void renderDocs(String name) throws IOException { | ||
| if (System.getProperty("generateDocs") == null) { | ||
| if (System.getProperty("generateDocs") == null || true) { |
Member
There was a problem hiding this comment.
Add a comment about how we're turning these off please.
craigtaverner
added
auto-backport
Contributor
Author
|
Since this disabled docs generation, I've changed the backport to 9.0 only. We can decide to backport this to an 8.x as a bug-fix if we feel that's necessary, using a new PR without any docs generation changes. For now it's 9.0 and 9.1 only. |
…search into agg_values_spatial
nik9000
approved these changes
Feb 24, 2025
…search into agg_values_spatial
Collaborator
💚 Backport successful
|
craigtaverner
added a commit
to craigtaverner/elasticsearch
that referenced
this pull request
Feb 25, 2025
The original work at elastic#106065 did not support geospatial types with this comment: > I made this work for everything but geo_point and cartesian_point because I'm not 100% sure how to integrate with those. We can grab those in a follow up. The geospatial types should be possible to collect using the VALUES aggregation with similar behavior to the `ST_COLLECT` OGC function, based on the Elasticsearch convention that treats multi-value geospatial fields as behaving similarly to any geometry collection. So this implementation is a trivial addition to the existing values types support.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Feb 25, 2025
The original work at #106065 did not support geospatial types with this comment: > I made this work for everything but geo_point and cartesian_point because I'm not 100% sure how to integrate with those. We can grab those in a follow up. The geospatial types should be possible to collect using the VALUES aggregation with similar behavior to the `ST_COLLECT` OGC function, based on the Elasticsearch convention that treats multi-value geospatial fields as behaving similarly to any geometry collection. So this implementation is a trivial addition to the existing values types support.
craigtaverner
added a commit
that referenced
this pull request
May 2, 2025
…127627) * Add support to VALUES aggregation for spatial types (#122886) The original work at #106065 did not support geospatial types with this comment: > I made this work for everything but geo_point and cartesian_point because I'm not 100% sure how to integrate with those. We can grab those in a follow up. The geospatial types should be possible to collect using the VALUES aggregation with similar behavior to the `ST_COLLECT` OGC function, based on the Elasticsearch convention that treats multi-value geospatial fields as behaving similarly to any geometry collection. So this implementation is a trivial addition to the existing values types support. * Fix docs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The original work at #106065 did not support geospatial types with this comment:
The geospatial types should be possible to collect using the VALUES aggregation with similar behavior to the
ST_COLLECTOGC function, based on the Elasticsearch convention that treats multi-value geospatial fields as behaving similarly to any geometry collection. So this implementation is a trivial addition to the existing values types support.Fixes #122413