Skip to content
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

Fix for ArithmeticException[/ by zero] when parsing a polygon #8475

Merged
merged 4 commits into from Nov 19, 2014

Conversation

nknize
Copy link
Contributor

@nknize nknize commented Nov 13, 2014

While this commit is primariy a fix for issue/8433 it adds more rigor to ShapeBuilder for parsing against the GeoJSON specification. Specifically, this adds LinearRing and LineString validity checks as defined in http://geojson.org/geojson-spec.html to ensure valid polygons are specified. The benefit of this fix is to provide a gate check at parse time to avoid any further processing if an invalid GeoJSON is provided. More parse checks like these will be necessary going forward to ensure full compliance with the GeoJSON specification.

Closes #8433

… with one pair of coordinates

While this commit is primariy a fix for issue/8433 it adds more rigor to ShapeBuilder for parsing against the GeoJSON specification. Specifically, this adds LinearRing and LineString validity checks as defined in http://geojson.org/geojson-spec.html to ensure valid polygons are specified. The benefit of this fix is to provide a gate check at parse time to avoid any further processing if an invalid GeoJSON is provided.  More parse checks like these will be necessary going forward to ensure full compliance with the GeoJSON specification.

Closes elastic#8433
@nknize nknize added :Analytics/Geo Indexing, search aggregations of geo points and shapes >bug review labels Nov 13, 2014
* "coordinates" member must be an array of two or more positions
* LineStringBuilder should throw a graceful exception if < 2 coordinates/points are provided
*/
if (coordinates.children.size() < 2) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This statement and the message below don't seem to correlate. Should we not also check if coordinates.children.size() == 0 here? Also from the linked spec it looks like 0 points would not be valid anyway?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct. There's a discrepancy between JTS and GeoJSON. JTS treats 0 points as a valid linear ring/linestring where GeoJSON does not. If we're going to conform to GeoJSON (which I think is the right approach - but open for thoughts) then I should insert the check for 0 points.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, should not insert the check for 0 points. The current check would be valid per the GeoJSON spec - I'll change the exception message.

@colings86
Copy link
Contributor

@nknize I left a few comments. I think it's looking pretty good though

@colings86 colings86 assigned nknize and unassigned colings86 Nov 14, 2014
@colings86 colings86 removed the review label Nov 14, 2014
ShapeBuilder.parse(parser);
Assert.fail("process completed successfully when parse exception expected");
} catch (Exception e) {
assert(e instanceof ElasticsearchParseException): "expected ElasticsearchParse exception but found " + e.getClass().getName();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could possibly use assertThat(e, org.hamcrest.Matchers.isA(ElasticsearchParseException)); here instead but I don't have a strong opinion about this either way.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Main thing here is that the test fails rather than errors on this line

@colings86
Copy link
Contributor

@nknize left a couple of minor comments but I think its almost ready

@nknize nknize removed the review label Nov 14, 2014
@nknize nknize assigned colings86 and unassigned nknize Nov 14, 2014
@nknize nknize added the review label Nov 14, 2014
@colings86
Copy link
Contributor

LGTM

@nknize nknize assigned clintongormley and unassigned colings86 Nov 17, 2014
@nknize nknize merged commit 0067a0c into elastic:master Nov 19, 2014
@s1monw
Copy link
Contributor

s1monw commented Nov 21, 2014

@nknize @colings86 I think this should be ported to the 1.3 branch too and have a 1.3.6 label?

@nknize nknize added the v1.3.6 label Nov 24, 2014
@nknize
Copy link
Contributor Author

nknize commented Nov 24, 2014

pushed to branch 1.3 and added 1.3.6 tag & label

@clintongormley clintongormley changed the title [GEO] Fix for ArithmeticException[/ by zero] when parsing a polygon Geo: Fix for ArithmeticException[/ by zero] when parsing a polygon Nov 25, 2014
@clintongormley clintongormley changed the title Geo: Fix for ArithmeticException[/ by zero] when parsing a polygon Fix for ArithmeticException[/ by zero] when parsing a polygon Jun 7, 2015
@nknize nknize deleted the fix/8433 branch May 27, 2016 16:22
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 v1.3.6 v1.4.1 v1.5.0 v2.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"ArithmeticException[/ by zero]" when parsing a "polygon" "geo_shape" query with one pair of coordinates
4 participants