Skip to content

geo-shape-doc-values centroid calculation should handle polygons as lines/points and lines as points #52303

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
talevy opened this issue Feb 13, 2020 · 4 comments
Labels
:Analytics/Geo Indexing, search aggregations of geo points and shapes >bug Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo)

Comments

@talevy
Copy link
Contributor

talevy commented Feb 13, 2020

  • Polygons with no area should not be treated as polygons — they should be treated as lines.
  • Lines with no length should not be treated as lines — they should be treated as points.

possible solution A

This can be achieved by updating the DimensionalShapeType of the geometry for such geometries. The downside of this is that then we would love information about what type of geometry the field value was.

possible solution B

The other option is to keep the original DimensionalShapeType, and instead have a place-holder weight that is close to 0 for such geometries.

relates to #50834

@talevy talevy added >bug :Analytics/Geo Indexing, search aggregations of geo points and shapes labels Feb 13, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-analytics-geo (:Analytics/Geo)

@talevy
Copy link
Contributor Author

talevy commented Feb 13, 2020

@nknize and @iverase, do you have a preference for how this issue is to be solved? Currently such values return NaN for longitude and latitude. At the time, I had tests for this and thought it was OK, but now I realize such geometries are very much expected in the wild.

@iverase
Copy link
Contributor

iverase commented Feb 13, 2020

My opinion here is those geometries are degenerated and they should be treated as the final shape. So if a polygon becomes a line, the DimensionalShapeType should be change accordingly. I think it is more important the current geometry than the original geometry type.

talevy added a commit to talevy/elasticsearch that referenced this issue Feb 19, 2020
This commit modifies the centroid-calculator/dimensional-shape-type
to properly support the instances of polygons that have no area
and lines that have no length. Beforehand N/A were returned for the
centroid values, but it is best to downcast the shape type to
the appropriate type.

Closes elastic#52303.
talevy added a commit that referenced this issue Feb 24, 2020
This commit modifies the centroid-calculator/dimensional-shape-type
to properly support the instances of polygons that have no area
and lines that have no length. Beforehand N/A were returned for the
centroid values, but it is best to downcast the shape type to
the appropriate type.

Closes #52303
talevy added a commit that referenced this issue Feb 24, 2020
This commit modifies the centroid-calculator/dimensional-shape-type
to properly support the instances of polygons that have no area
and lines that have no length. Beforehand N/A were returned for the
centroid values, but it is best to downcast the shape type to
the appropriate type.

Closes #52303
@rjernst rjernst added the Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo) label May 4, 2020
@talevy
Copy link
Contributor Author

talevy commented May 7, 2020

this was closed in #52500

@talevy talevy closed this as completed May 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Analytics/Geo Indexing, search aggregations of geo points and shapes >bug Team:Analytics Meta label for analytical engine team (ESQL/Aggs/Geo)
Projects
None yet
Development

No branches or pull requests

4 participants