Normalise polygons only when necessary #84229
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
iverase
added
>enhancement
:Analytics/Geo
elasticmachine
added
the
Team:Analytics
Collaborator
|
Pinging @elastic/es-analytics-geo (Team:Analytics) |
Collaborator
|
Hi @iverase, I've created a changelog YAML for you. |
Contributor
Author
|
@elasticmachine update branch |
...java/org/elasticsearch/xpack/spatial/index/mapper/GeoShapeWithDocValuesFieldMapperTests.java
Outdated
Show resolved
Hide resolved
Collaborator
|
Hi @iverase, I've updated the changelog YAML for you. |
craigtaverner
approved these changes
Mar 7, 2022
Contributor
craigtaverner
left a comment
craigtaverner
left a comment
There was a problem hiding this comment.
I think this looks like an improvement for the error checking, but am worried about performance. Do we have regular benchmarks running that would catch a regression?
| return Collections.emptyList(); | ||
| } | ||
| geometry = GeometryNormalizer.apply(orientation, geometry); | ||
| if (GeometryNormalizer.needsNormalize(orientation, geometry)) { |
Contributor
There was a problem hiding this comment.
Looking at the code, needsNormalize does quite an extensive check, so I presume this adds some performance cost?
Contributor
Author
There was a problem hiding this comment.
needsNormalize should run several times faster than the normalisation.
| @Override | ||
| public Void visit(Polygon polygon) { | ||
| addFields(LatLonShape.createIndexableFields(name, GeoShapeUtils.toLucenePolygon(polygon))); | ||
| addFields(LatLonShape.createIndexableFields(name, GeoShapeUtils.toLucenePolygon(polygon), true)); |
Contributor
There was a problem hiding this comment.
The additional checks in the tesselator also add some performance cost.
Contributor
Author
There was a problem hiding this comment.
Yes, the hope is that the overhead of checking for intersection in the tessellator is compensated with skipping the normalisation step.
Contributor
Author
|
We don't have a rally track for geo_shape that runs daily but we are working on it: elastic/rally-tracks#238 Just run indexing manually and all-in-all it seems the effect in performance is very small, cumulative time just increased by ~1.75%. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 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.
With the upgrade to Lucene 9.1, the Tessellator supports validity checks of the polygons and it will return a nice message to the user. That allows calling the normaliser only when necessary as the checks it was doing to the polygon are covered by the Tessellator.
In general this change of strategy should result in better error messages back to the user when a polygon is invalid.
closes #35349