generalize encoding/decoding of coordinates to helper classes #46154
+368
−190
Conversation
This file contains 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
talevy
added
the
:Analytics/Geo
|
Pinging @elastic/es-analytics-geo |
|
run elasticsearch-ci/2 |
|
run elasticsearch-ci/2 I believe the failure here is related to #46195. |
imotov
approved these changes
Aug 30, 2019
| BoundingBox(Extent extent) { | ||
| this.top = GeoEncodingUtils.decodeLatitude(extent.top); | ||
| this.bottom = GeoEncodingUtils.decodeLatitude(extent.bottom); | ||
| BoundingBox(Extent extent, CoordinateEncoder coordinateEncoder) { |
There was a problem hiding this comment.
I wonder if it would simplify things if we "taught" extent how to decode itself, by passing it as a constrictor parameter into Extent?
There was a problem hiding this comment.
that is a good point! I will explore this when it is being used more in intersection queries in CellIdSource
talevy
added a commit
that referenced
this pull request
Sep 20, 2019
It is important that the GeometryTreeReader/Writers support different encodings more naturally. As of now, there is a need for GeoEncodingUtil encoding/decoding and XYEncodingUtil encoding/decoding. This PR achieves three goals - abstract the encoding of double-valued x/y coordinates to the int-values that are used when serializing - make the GeometryTree structures re-usable between shape and geo_shape types - have the tree structures take in the raw coordinate values so that more accurate centroid calculations can be done at index-time for the geo-centroid aggregation This PR leaves one open question / leak in the model - the Extent that is queried and returned by these tree structures is still in the encoded form. The reason this is left out of the PR is because Extent is an object that is repetitively used in recursive checks of bounds, and re-encoding the coordinates every time can be costly. - The idea is that the aggregations that rely on intersects queries will convert the BoundingBox structures to Extent objects. This would be done in the future by aggregations like geo*grid. This PR also leaves out an implementation of ShapeCoordinateEncoder that would be used by the shape field-type. This can be added in the future.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
It is important that the GeometryTreeReader/Writers support different encodings more naturally. As of now, there is a need for GeoEncodingUtil encoding/decoding and XYEncodingUtil encoding/decoding.
This PR achieves three goals
This PR leaves one open question / leak in the model
This PR also leaves out an implementation of ShapeCoordinateEncoder that would be used by the shape field-type. This can be added in the future.