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

GeoPolygonFilter not properly handling dateline and pole crossing #9171

Closed
wants to merge 3 commits into from

Conversation

nknize
Copy link
Contributor

@nknize nknize commented Jan 6, 2015

By default GeoPolygonFilter normalizes GeoPoints to a [-180:180] lon, [-90:90] lat coordinate boundary. This requires the GeoPolygonFilter be split into east/west, north/south regions to properly return points collection that wrap the dateline and poles. To keep queries fast, this simple fix converts the GeoPoints for both the target polygon and candidate points to a [0:360] lon, [0:180] lat coordinate range. This way the user (or the filter logic) doesn't have to split the filter in two parts.

closes #5968

By default GeoPolygonFilter normalizes GeoPoints to a [-180:180] lon, [-90:90] lat coordinate boundary. This requires the GeoPolygonFilter be split into east/west, north/south regions to properly return points collection that wrap the dateline and poles. To keep queries fast, this simple fix converts the GeoPoints for both the target polygon and candidate points to a [0:360] lon, [0:180] lat coordinate range. This way the user (or the filter logic) doesn't have to split the filter in two parts.

closes elastic#5968
@nknize nknize added :Analytics/Geo Indexing, search aggregations of geo points and shapes v2.0.0-beta1 v1.5.0 v1.4.3 >enhancement review labels Jan 6, 2015
lon += 360;
}

if (lat <0) {
Copy link
Member

Choose a reason for hiding this comment

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

nit: space between < and 0

@rjernst
Copy link
Member

rjernst commented Jan 7, 2015

LGTM. I left a couple minor thoughts.

@clintongormley
Copy link

Can we remove the normalize options and just do the right thing? I think they were added for bwc purposes, but if we don't need them anymore, then let's get rid of them.

@nknize
Copy link
Contributor Author

nknize commented Jan 14, 2015

Sounds good @clintongormley. Not only do we not need the normalize filter option, this filter also suffers from the ambiguous poly problem. There's a bit that needs to be cleaned up here, including reusing logic written in #8762. Do you want me to just go ahead and close this PR and submit a new one when its ready? Or just keep this open?

@nknize
Copy link
Contributor Author

nknize commented Jan 16, 2015

Closing in favor of #9339

@nknize nknize closed this Jan 16, 2015
@clintongormley clintongormley changed the title [GEO] GeoPolygonFilter not properly handling dateline and pole crossing Geo: GeoPolygonFilter not properly handling dateline and pole crossing Feb 10, 2015
@clintongormley clintongormley changed the title Geo: GeoPolygonFilter not properly handling dateline and pole crossing GeoPolygonFilter not properly handling dateline and pole crossing Jun 7, 2015
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 >enhancement v1.4.3 v1.5.0 v2.0.0-beta1
Projects
None yet
Development

Successfully merging this pull request may close these issues.

geo_polygon not handling polygons that cross the date line properly
3 participants