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
geo_polygon not handling polygons that cross the date line properly #5968
Comments
This is actually working as expected. Your first query will resolve as shown in the following GeoJSON gist which will not contain your document: To create the desired results you specified you would need to split the polygon in to two polygons, one to the left of the date line and the other to the right. This can be done with the following query:
The bounding box is a little different since by specifying which coordinate is top_left and which is top_right you are fixing the box to overlap the date line. |
For me, I'd expect the line segment between two points to lie in the same direction as the great circle arc. Splitting an arbitrary query into sub-polygons isn't entirely straightforward, because it could intersect longitude 180 multiple times. I have a rough draft of a commit that fixes this issue by shifting the polygon in GeoPolygonFilter (and all points passed in to pointInPolygon) so that it lies completely on one side of longitude 180. It is low-overhead and has basically no effect on the normal case. The only constraint is that the polygon can't span more than 360 degrees in longitude. Does this sound reasonable, and is it worth submitting a PR? |
@colings86 could this be solved with a |
It does not. This is the infamous "ambiguous polygon" problem that occurs when treating a spherical coordinate system as a cartesian plane. I opened a discussion and feature branch to address this in #8672 tldr: GeoJSON doesn't specify order, but OGC does. Feature fix: Default behavior = For GeoJSON poly's specified in OGC order (shell: ccw, holes: cw) ES Ring logic will correctly transform and split polys across the dateline (e.g., see https://gist.github.com/nknize/d122b243dc63dcba8474). For GeoJSON poly's provided in the opposite order original behavior will occur (e.g., @colings86 example https://gist.github.com/anonymous/82b50b74a7b6d170bfc6). Additionally, I like @clintongormley suggestion of adding an optional left/right parameter. Its an easy fix letting user's clearly specify intent. |
This is now addressed in PR #8762 |
Optional left/right parameter added in PR #8978 |
Merged in edd33c0 |
I tried @pablocastro's example on trunk, and unfortunately the issue is still there. There might've been some confusion -- the original example refers to the geo_polygon filter, whereas @nknize's fix is for the polygon geo_shape type. Should I create a new ticket for the geo_polygon filter, or should we re-open this one? |
Good catch @jtibshirani! We'll go ahead and reopen this ticket since its a separate issue. |
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
PR elastic#8672 addresses ambiguous polygons - those that either cross the dateline or span the map - by complying with the OGC standard right-hand rule. Since ```GeoPolygonFilter``` is self contained logic, the fix in elastic#8672 did not address the issue for the ```GeoPolygonFilter```. This was identified in issue elastic#5968 This fixes the ambiguous polygon issue in ```GeoPolygonFilter``` by moving the dateline crossing code from ```ShapeBuilder``` to ```GeoUtils``` and reusing the logic inside the ```pointInPolygon``` method. Unit tests are added to ensure support for coordinates specified in either standard lat/lon or great-circle coordinate systems. closes elastic#5968 closes elastic#9304
The search hits of really huge polygon (elasticsearch 1.4.3) {
"query": {
"filtered": {
"filter": {
"geo_shape": {
"location": {
"shape": {
"type": "Polygon",
"coordinates": [
[
[
-70.4873046875,
79.9818262344106
],
[
-70.4873046875,
-28.07230647927298
],
[
-103.3583984375,
-28.07230647927298
],
[
-103.3583984375,
79.9818262344106
],
[
-70.4873046875,
79.9818262344106
]
]
],
"orientation": "ccw"
}
}
}
}
}
}
} doesn't include any points inside that polygon even with orientation option. |
Its related. For now, if you have an ambiguous poly that crosses the pole you'll need to manually split it into 2 separate explicit polys and put inside a A separate issue is related to the distance_error_pct parameter. If not specified, larger filters will have reduced accuracy. Though this seems unrelated to your GeoJSON |
PR elastic#8672 addresses ambiguous polygons - those that either cross the dateline or span the map - by complying with the OGC standard right-hand rule. Since ```GeoPolygonFilter``` is self contained logic, the fix in elastic#8672 did not address the issue for the ```GeoPolygonFilter```. This was identified in issue elastic#5968 This fixes the ambiguous polygon issue in ```GeoPolygonFilter``` by moving the dateline crossing code from ```ShapeBuilder``` to ```GeoUtils``` and reusing the logic inside the ```pointInPolygon``` method. Unit tests are added to ensure support for coordinates specified in either standard lat/lon or great-circle coordinate systems. closes elastic#5968 closes elastic#9304
relates to #26286 |
closing in favor of #26286 since its an old issue |
Using Elasticsearch 1.1.1. I'm seeing geo_polygon behave oddly when the input polygon cross the date line. From a quick look at GeoPolygonFilter.GeoPolygonDocSet.pointInPolygon it doesn't seem that this is explicitly handled.
The reproduce this create an index/mapping as:
POST /geo
Upload a document:
PUT /geo/docs/1
Search with a polygon that's a box around the uploaded point and that crosses the date line:
POST /geo/docs/_search
ES returns 0 results. If I use a polygon that stays to the west of the date line I do get results:
Also, if I use a bounding box query with the same coordinates as the initial polygon, it does work:
It seems that this code needs to either split the check into east and west checks or normalize the input values. Am I missing something?
The text was updated successfully, but these errors were encountered: