Clean up Extent logic in Geo Tree readers #42968
Merged
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
- min and max values of coordinates were difficult to track, this fixes that by introducing a new Extent object - Instead of re-wrapping ByteRef into a StreamInput, a stream input is made once - a new getExtent() method is introduced for use by aggregations like geo_bounds - re-use bounding-box containment checks
talevy
added
the
:Analytics/Geo
|
Pinging @elastic/es-analytics-geo |
imotov
reviewed
Jun 7, 2019
server/src/main/java/org/elasticsearch/common/geo/EdgeTreeReader.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/common/geo/EdgeTreeReader.java
Outdated
Show resolved
Hide resolved
server/src/main/java/org/elasticsearch/common/geo/EdgeTreeReader.java
Outdated
Show resolved
Hide resolved
|
|
||
| public EdgeTreeReader(StreamInput input) throws IOException { | ||
| int treeBytesSize = input.readVInt(); | ||
| this.bytesRef = input.readBytesRef(treeBytesSize); | ||
| this.input = new ByteBufferStreamInput(ByteBuffer.wrap(bytesRef.bytes, bytesRef.offset, bytesRef.length)); |
There was a problem hiding this comment.
Now that you merged #42910 that just doesn't look right. Perhaps we can brainstorm a bit on how to improve that.
imotov
approved these changes
Jun 10, 2019
| public boolean containedInOrCrosses(int minLon, int minLat, int maxLon, int maxLat) throws IOException { | ||
| ByteBufferStreamInput input = new ByteBufferStreamInput( | ||
| ByteBuffer.wrap(bytesRef.bytes, bytesRef.offset, bytesRef.length)); | ||
| public Extent getExtent() throws IOException { |
There was a problem hiding this comment.
This method is no longer needed, right?
There was a problem hiding this comment.
so, this method is to be used by aggregations like geo_bounds in the future, so I figured I would throw it in here while I'm at it. happy to remove and only add when used
There was a problem hiding this comment.
In this case we should probably add a test for it and replace reading individual components with invoking `Extent(StreamInput).
talevy
added a commit
that referenced
this pull request
Sep 20, 2019
- min and max values of coordinates were difficult to track, this fixes that by introducing a new Extent object - Instead of re-wrapping ByteRef into a StreamInput, a stream input is made once - a new getExtent() method is introduced for use by aggregations like geo_bounds - re-use bounding-box containment checks
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.
track, this fixes that by introducing a new Extent
object
input is made once
geo_bounds
Extent object may come in handy for actual logic in the future. if/when the time comes, it
would make sense to up-lift the class into its own file.