Add support for "unmapped_type" and "missing" options for _geo_distance sorting

[coderbarncb]

Describe the feature: Support "unmapped_type" and "missing" options for _geo_distance sorting

Currently it is not possible to add said keywords to a _geo_distance search, internally only the FieldSortBuilder seems to support this.

Normally one can use the "unmapped_type" and "missing" options for sorting on fields which might not be present in all documents / indexes (e.g. when searching via an index alias).

However, the feature is NOT supported in the GeoDistanceSortBuilder, hence a search will not return any results for documents which do not have a geo_point field to sort on.

---

ON A SIDENOTE (my $0.2)

In general I do think that the sorting behaviour is not implemented correctly.
Why?
Searching and sorting are two different things. Documents which are found, but do not match the given sorting criteria should simply be returned at the "bottom" of the (sorted) list.

Elasticsearch however, REMOVES them from the search results. IMO this is simply wrong.

Hence either the relevant keywords should be supported by said SortBuilder OR the implementation must be "corrected" :-)

Cheerio!

[danielmitterdorfer]

@nknize could you please have a look at this one? In the docs we state:

geo distance sorting does not support configurable missing values: the distance will always be considered equal to Infinity when a document does not have values for the field that is used for distance computation.

So I would assume that missing values in geo_point fields are already taken care of or is there something missing from the docs?

[imotov]

I looked at it for a bit, and I am not sure I understand the utility of missing for geopoints. In the current implementation, the missing is essentially set in such a way that the points with missing value appear to infinitely far, so it is essentially equivalent to "missing": "_last" assuming ascending order or _first in case of descending. I am having a hard time imagining a use case where we would need to put points without location ahead of points with a location. I can see how we might want to add this for the sake of consistency though.

I can see the value of adding an equivalent of unmapped_type. There is indeed no way to search both an indexed with mapped geo_point field and an index without such field and sort them by geo distance. I am a bit divided in how to implement it though. The geo distance sort order is implemented slightly differently from all other sort orders. When we sort by a keyword field we write something like:

 {"author" : {"order" : "asc"}}

So adding "unmapped_type" : "keyword" makes perfect sense since we if the field author is missing, we need to know what type this field is supposed to have. In case of geo distance we have:

{  "_geo_distance" : { "pin" : [-70, 40],  "order" : "asc" } }

So we already know that pin is supposed to be a geopoint field, and asking about unmapped_type feels a bit silly in this case. Should we handle it by adding some boolean flag instead? Something like this perhaps?

{  "_geo_distance" : { "pin" : [-70, 40],  "order" : "asc", "ignore_unmapped" : true } }