Add multipolygon support to GeoPolygonQueryBuilder

[nknize]

LatLonPoint polygon query in Lucene 6 supports multipolygons and polygons with holes. This PR exposes this capability through the ES query DSL by adding multipolygon support to the GeoPolygonQueryBuilder parser such that the following can now be parsed:

"query" : {
  "geo_polygon" : {
    "track.location" :{
      "multipolygon": [ [ [
        [-70, 40],
        [-80, 30],
        [-90, 20]
      ] ] ]
    }
  }
}

To maintain backcompat the following is still supported:

"query" : {
  "geo_polygon" : {
    "track.location" :{
      "points": [ 
        [-70, 40],
        [-80, 30],
        [-90, 20]
      ] 
    }
  }
}

The GeoPolygonQueryBuilder now creates a Polygon object and passes it to LatLonPoint.newPolygonQuery.

NOTE:

• Performs minimal polygon validation (e.g., enforcing minimum number of points, validating coordinates).
• Dateline crossing is not supported.

TODO:

• update docs with multipolygon support

closes #20789

[mikemccand]

Thanks @nknize, I left a bunch of small comments.

It would be nice if ES would accept a standard GeoJson multipolygon: Lucene has a simple parser for this, taking String and returning Polygon[] ... I think that'd be easier for people to use than a triple-nested array of lon/lat points ... but we should do that separately.

[mikemccand]

Hmm do we also do lon then lat elsewhere in the ES APIs? This is very confusing ... Lucene standardized on lat then lon a while back!

[jpountz]

In strings, the first value is the latitude ("lat,lon"), but in arrays, the first value is the longitude as per geojson (http://geojson.org/) spec ([lon, lat]). @nknize please correct me if I am wrong.

[mikemccand]

Can you include the actual points in the exc message to aid users debugging?

[mikemccand]

Hmm, lat and lon are not used in this outer scope, only down inside the nested for loop? Can you move their declaration (the double[]) down there?

[mikemccand]

Same for shellLat and shellLon?

[mikemccand]

Maybe assert poly.size() > 0?

[mikemccand]

Can you add some context to this exception so the user knows what part of their request was wrong?

[mikemccand]

Same here.

[mikemccand]

It looks like these tests are a single polygon? Can you also test that holes are parsed & executed correctly, and more than one polygon too?

[dakrone]

@nknize is this PR still a WIP? Is there someone else that should review it?

[islamjaidul]

I am sorry to say that I cannot use this way, it shows
[parsing_exception] [geo_polygon] query does not support [multipolygon], with { line=1 & col=162 }

Elastic search version - 6.2.4
How may I use multipolygon, could you guys please tell me

[pcsanwald]

@polyfractal @nknize has this PR been supplanted by a different PR that provides the same functionality? if so, can you close please?

[polyfractal]

Quick update on this. Nick rebased the PR onto master, looks like there are some CI failures related to backwards compatibility. In general the PR is almost done but probably needs some more testing and better/more informative exception messages.

Nick doesn't have time to push this PR over the finish line right now, but we think it's still important so I'm going to mark this as a help-me issue. Would make a good first issue for someone wanting to get involved with Geo, since most of the hard work is already done :)

[nknize]

This is a good first issue for anyone interested in picking up some ES geo knowledge. The only thing missing is to add support for GeoJSON using lucene's Polygon.fromGeoJSON method. Should be pretty straightforward.. just pass the GeoJSON string to that method and it will create the Polygon[] for you.

[ioanlucut]

Hello!

What is the status of this PR?

[nathancday]

If no one is working on this in 2020, I'm gonna pick it up and try to get it finalized

[nknize]

Thank you for the offer @nathancday but there is a 99% likelihood that we will be deprecating and removing geo_polygon query in favor of the added support for geo_shape queries on geo_point field types that was added in #53774 (which supports all geometry (and multipart) types). If that's the case then this PR is no longer needed and will be closed without merge.

[iverase]

I am going to close this as it does not apply any longer.