Geo_polygon not handling polygons that cross the date line properly?

Elastic Stack Elasticsearch
1

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

{ "mappings": { "docs": { "properties": { "p": { "type": "geo_point" } } }
} }

Upload a document:

PUT /geo/docs/1

{ "p": { "lat": 40, "lon": 179 } }

Search with a polygon that's a box around the uploaded point and that
crosses the date line:

POST /geo/docs/_search

{
"filter": { "geo_polygon": { "p": { "points": [
{ "lat": 42, "lon": 178 },
{ "lat": 39, "lon": 178 },
{ "lat": 39, "lon": -179 },
{ "lat": 42, "lon": -179 },
{ "lat": 42, "lon": 178 }
] } } }
}

ES returns 0 results. If I use a polygon that stays to the west of the date
line I do get results:

{
"filter": { "geo_polygon": { "p": { "points": [
{ "lat": 42, "lon": 178 },
{ "lat": 39, "lon": 178 },
{ "lat": 39, "lon": 179.5 },
{ "lat": 42, "lon": 179.5 },
{ "lat": 42, "lon": 178 }
] } } }
}

Also, if I use a bounding box query with the same coordinates as the
initial polygon, it does work:

{
"filter": { "geo_bounding_box": { "p":
{ "top_left": { "lat": 42, "lon": 178 },
"bottom_right": { "lat": 39, "lon": -179 }
}
} }
}

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?

Thanks
-pablo

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/598de712-4e0c-405d-9575-52216bbb8692%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

2

Hey there,

please file a github issue for this one, to make sure it does not get lost
(havent checked the details, but looks like a valid bug from my birds eye
view). Thanks a lot!

--Alex

On Mon, Apr 28, 2014 at 7:41 PM, Pablo Castro pablomc@gmail.com wrote:

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

{ "mappings": { "docs": { "properties": { "p": { "type": "geo_point" } } }
} }

Upload a document:

PUT /geo/docs/1

{ "p": { "lat": 40, "lon": 179 } }

Search with a polygon that's a box around the uploaded point and that
crosses the date line:

POST /geo/docs/_search

{
"filter": { "geo_polygon": { "p": { "points": [
{ "lat": 42, "lon": 178 },
{ "lat": 39, "lon": 178 },
{ "lat": 39, "lon": -179 },
{ "lat": 42, "lon": -179 },
{ "lat": 42, "lon": 178 }
] } } }
}

ES returns 0 results. If I use a polygon that stays to the west of the
date line I do get results:

{
"filter": { "geo_polygon": { "p": { "points": [
{ "lat": 42, "lon": 178 },
{ "lat": 39, "lon": 178 },
{ "lat": 39, "lon": 179.5 },
{ "lat": 42, "lon": 179.5 },
{ "lat": 42, "lon": 178 }
] } } }
}

Also, if I use a bounding box query with the same coordinates as the
initial polygon, it does work:

{
"filter": { "geo_bounding_box": { "p":
{ "top_left": { "lat": 42, "lon": 178 },
"bottom_right": { "lat": 39, "lon": -179 }
}
} }
}

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?

Thanks
-pablo

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/598de712-4e0c-405d-9575-52216bbb8692%40googlegroups.comhttps://groups.google.com/d/msgid/elasticsearch/598de712-4e0c-405d-9575-52216bbb8692%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAGCwEM-DEw%2BzEySk5JsN23pSshtg2Oo8fGHgWcMVYc3SS_4UZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

3

Thanks for taking a look. Filed here:

Two more things that don't seem to work, but I'm not sure there was an
expectation that they would:

  1. For polygons the direction (whether points are listed clockwise or
    counter-clockwise) matters, since that's how you can tell what part is the
    inside of the polygon. Skimming through the code surrounding
    pointInPolygon() I couldn't see a spot where that's factored in.

  2. Polygons or even bounding boxes (using bbox filters) don't seem to work
    when the area is around the north (and sound?) pole.

Let me know if you want separate issues filed for those as well.

On Monday, April 28, 2014 6:40:46 PM UTC-7, Alexander Reelsen wrote:

Hey there,

please file a github issue for this one, to make sure it does not get lost
(havent checked the details, but looks like a valid bug from my birds eye
view). Thanks a lot!

--Alex

On Mon, Apr 28, 2014 at 7:41 PM, Pablo Castro <pab...@gmail.com<javascript:>

wrote:

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

{ "mappings": { "docs": { "properties": { "p": { "type": "geo_point" } }
} } }

Upload a document:

PUT /geo/docs/1

{ "p": { "lat": 40, "lon": 179 } }

Search with a polygon that's a box around the uploaded point and that
crosses the date line:

POST /geo/docs/_search

{
"filter": { "geo_polygon": { "p": { "points": [
{ "lat": 42, "lon": 178 },
{ "lat": 39, "lon": 178 },
{ "lat": 39, "lon": -179 },
{ "lat": 42, "lon": -179 },
{ "lat": 42, "lon": 178 }
] } } }
}

ES returns 0 results. If I use a polygon that stays to the west of the
date line I do get results:

{
"filter": { "geo_polygon": { "p": { "points": [
{ "lat": 42, "lon": 178 },
{ "lat": 39, "lon": 178 },
{ "lat": 39, "lon": 179.5 },
{ "lat": 42, "lon": 179.5 },
{ "lat": 42, "lon": 178 }
] } } }
}

Also, if I use a bounding box query with the same coordinates as the
initial polygon, it does work:

{
"filter": { "geo_bounding_box": { "p":
{ "top_left": { "lat": 42, "lon": 178 },
"bottom_right": { "lat": 39, "lon": -179 }
}
} }
}

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?

Thanks
-pablo

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/598de712-4e0c-405d-9575-52216bbb8692%40googlegroups.comhttps://groups.google.com/d/msgid/elasticsearch/598de712-4e0c-405d-9575-52216bbb8692%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/7f01b6b6-8c78-4b4e-ba45-023dfdde9a75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

4

Thanks for taking a look. Filed here:

One more thing that doesn't seem to work, but I'm not sure there was an
expectation that it would: usually the direction (whether points are listed
clockwise or counter-clockwise) matters, since that's how you can tell what
part is the inside of the polygon (at least that's how WKT does it).
Skimming through the code surrounding pointInPolygon() I couldn't see a
spot where that's factored in.

Let me know if you want a separate issue filed for that as well.

On Monday, April 28, 2014 6:40:46 PM UTC-7, Alexander Reelsen wrote:

Hey there,

please file a github issue for this one, to make sure it does not get lost
(havent checked the details, but looks like a valid bug from my birds eye
view). Thanks a lot!

--Alex

On Mon, Apr 28, 2014 at 7:41 PM, Pablo Castro <pab...@gmail.com<javascript:>

wrote:

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

{ "mappings": { "docs": { "properties": { "p": { "type": "geo_point" } }
} } }

Upload a document:

PUT /geo/docs/1

{ "p": { "lat": 40, "lon": 179 } }

Search with a polygon that's a box around the uploaded point and that
crosses the date line:

POST /geo/docs/_search

{
"filter": { "geo_polygon": { "p": { "points": [
{ "lat": 42, "lon": 178 },
{ "lat": 39, "lon": 178 },
{ "lat": 39, "lon": -179 },
{ "lat": 42, "lon": -179 },
{ "lat": 42, "lon": 178 }
] } } }
}

ES returns 0 results. If I use a polygon that stays to the west of the
date line I do get results:

{
"filter": { "geo_polygon": { "p": { "points": [
{ "lat": 42, "lon": 178 },
{ "lat": 39, "lon": 178 },
{ "lat": 39, "lon": 179.5 },
{ "lat": 42, "lon": 179.5 },
{ "lat": 42, "lon": 178 }
] } } }
}

Also, if I use a bounding box query with the same coordinates as the
initial polygon, it does work:

{
"filter": { "geo_bounding_box": { "p":
{ "top_left": { "lat": 42, "lon": 178 },
"bottom_right": { "lat": 39, "lon": -179 }
}
} }
}

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?

Thanks
-pablo

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearc...@googlegroups.com <javascript:>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/598de712-4e0c-405d-9575-52216bbb8692%40googlegroups.comhttps://groups.google.com/d/msgid/elasticsearch/598de712-4e0c-405d-9575-52216bbb8692%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/62a8c832-682d-4d8a-8631-03b539d646df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

5

Hey,

there is already another issue for polygons, where it seems to me, that we
dont calculate the starting points for polygon calculations correctly. It
is Geo: Valid complex polygons fail to parse · Issue #5773 · elastic/elasticsearch · GitHub

any input greatly appreciated, as I am by far not a geo expert.

--Alex

On Tue, Apr 29, 2014 at 7:12 AM, Pablo Castro pablomc@gmail.com wrote:

Thanks for taking a look. Filed here:
geo_polygon not handling polygons that cross the date line properly · Issue #5968 · elastic/elasticsearch · GitHub

One more thing that doesn't seem to work, but I'm not sure there was an
expectation that it would: usually the direction (whether points are listed
clockwise or counter-clockwise) matters, since that's how you can tell what
part is the inside of the polygon (at least that's how WKT does it).
Skimming through the code surrounding pointInPolygon() I couldn't see a
spot where that's factored in.

Let me know if you want a separate issue filed for that as well.

On Monday, April 28, 2014 6:40:46 PM UTC-7, Alexander Reelsen wrote:

Hey there,

please file a github issue for this one, to make sure it does not get
lost (havent checked the details, but looks like a valid bug from my birds
eye view). Thanks a lot!

--Alex

On Mon, Apr 28, 2014 at 7:41 PM, Pablo Castro pab...@gmail.com wrote:

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

{ "mappings": { "docs": { "properties": { "p": { "type": "geo_point" } }
} } }

Upload a document:

PUT /geo/docs/1

{ "p": { "lat": 40, "lon": 179 } }

Search with a polygon that's a box around the uploaded point and that
crosses the date line:

POST /geo/docs/_search

{
"filter": { "geo_polygon": { "p": { "points": [
{ "lat": 42, "lon": 178 },
{ "lat": 39, "lon": 178 },
{ "lat": 39, "lon": -179 },
{ "lat": 42, "lon": -179 },
{ "lat": 42, "lon": 178 }
] } } }
}

ES returns 0 results. If I use a polygon that stays to the west of the
date line I do get results:

{
"filter": { "geo_polygon": { "p": { "points": [
{ "lat": 42, "lon": 178 },
{ "lat": 39, "lon": 178 },
{ "lat": 39, "lon": 179.5 },
{ "lat": 42, "lon": 179.5 },
{ "lat": 42, "lon": 178 }
] } } }
}

Also, if I use a bounding box query with the same coordinates as the
initial polygon, it does work:

{
"filter": { "geo_bounding_box": { "p":
{ "top_left": { "lat": 42, "lon": 178 },
"bottom_right": { "lat": 39, "lon": -179 }
}
} }
}

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?

Thanks
-pablo

--
You received this message because you are subscribed to the Google
Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to elasticsearc...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/
msgid/elasticsearch/598de712-4e0c-405d-9575-52216bbb8692%
40googlegroups.comhttps://groups.google.com/d/msgid/elasticsearch/598de712-4e0c-405d-9575-52216bbb8692%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/62a8c832-682d-4d8a-8631-03b539d646df%40googlegroups.comhttps://groups.google.com/d/msgid/elasticsearch/62a8c832-682d-4d8a-8631-03b539d646df%40googlegroups.com?utm_medium=email&utm_source=footer
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAGCwEM8byJvkmsm0NsuL18CZYYoppt29JM5nx35KpGrhS-8y4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.