How to insert large polar polygons in elasticsearch? - elasticsearch

Question

When inserting a large polygon near the south pole:
"polygon":{
"type":"polygon",
"coordinates":[
[
[
-134.97410583496094,
-61.81480026245117
],
[
-130.1757049560547,
-63.236000061035156
],
[
-125.17160034179688,
-64.40799713134766
],
[
-152.0446014404297,
-75.72830200195312
],
[
143.52340698242188,
-77.68319702148438
],
[
147.41830444335938,
-75.44519805908203
],
[
150.2816925048828,
-73.01909637451172
],
[
-162.17909240722656,
-71.5260009765625
],
[
-134.97410583496094,
-61.81480026245117
]
]
]
},
, the following error is returned.
{
"error" : "RemoteTransportException[[ISAAC][inet[/x.x.x.x:9300]][indices:data/write/index]]; nested: MapperParsingException[failed to parse [polygon]]; nested: InvalidShapeException[Self- intersection at or near point (-142.29442281263474, -71.62101996804898, NaN)]; ",
"status" : 400
}
The mapping of the type is:
curl -XPUT http://localhost:9200/files/_mapping/polar -d '
{
"polar" : {
"properties" : {
"startTimeRange" : { "type" : "date"},
"endTimeRange" : { "type" : "date"},
"productShortName" : {
"type": "string",
"index" : "not_analyzed"
},
"polygon" : {
"type" : "geo_shape",
"tree" : "quadtree",
"precision" : "1000m"
}
}
}
}
'
The intended shape is essential a rectangle crossing the dateline (anti-meridian).
It looks like the shape is being interpreted as a self-intersecting
polygon crossing the meridian (0 - Longitude).
What is the best way to represent the intended shape in elasticsearch?

Answer 1

Dateline and Pole Crossing is a known issue. Dateline crossing was fixed in ES 1.4.3 but the pole crossing patch will be released in a future version. For now (and this can be a serious PITA for ambiguous polygon's) you'll have to unwrap the Polygon into a MultiPolygon yourself (presumably at the application layer).
Here's an example using your data.
The original self-crossing poly (as seen at the following gist: https://gist.github.com/nknize/ea0e103a22bddae13dfb)
{
"type" : "Polygon",
"coordinates":[[
[
-134.97410583496094,
-61.81480026245117
],
[
-130.1757049560547,
-63.236000061035156
],
[
-125.17160034179688,
-64.40799713134766
],
[
-152.0446014404297,
-75.72830200195312
],
[
143.52340698242188,
-77.68319702148438
],
[
147.41830444335938,
-75.44519805908203
],
[
150.2816925048828,
-73.01909637451172
],
[
-162.17909240722656,
-71.5260009765625
],
[
-134.97410583496094,
-61.81480026245117
]
]]
}
Corrected version using polar "unwrapping" (seen at the following gist: https://gist.github.com/nknize/8e87ee88d3915498507e)
{
"type" : "MultiPolygon",
"coordinates":[[[
[
-180.0,
-72.092693931
],
[
-162.17909240722656,
-71.5260009765625
],
[
-134.97410583496094,
-61.81480026245117
],
[
-130.1757049560547,
-63.236000061035156
],
[
-125.17160034179688,
-64.40799713134766
],
[
-152.0446014404297,
-75.72830200195312
],
[ -173.3707512019,
-90.0
],
[
-180.0,
-90.0
],
[
-180.0,
-72.092693931
]
]],
[[
[
173.3707512019,
-90.0
],
[
143.52340698242188,
-77.68319702148438
],
[
147.41830444335938,
-75.44519805908203
],
[
150.2816925048828,
-73.01909637451172
],
[
180.0,
-72.092693931
],
[
180.0,
-90.0
],
[
173.3707512019,
-90.0
]
]]
]
}
Note that the above "corrected" MultiPolygon is a rough calculation (with floating point error) used just for this example.
Not an ideal answer, but I hope it helps!