geo_point runtime field implementation

[iverase]

Run time field that emits geo points from lat/lon values. For example, given a mapping like:

{
    "mappings": {
        "properties": {
            "location": {
                "lat": {"type" : "double"},
                "lon" : {"type" "double"}
            }
        }
    }
}

A geo_point runtime field can be declared as:

{
    "runtime_geo_point": {
        "type" : "runtime",
         "runtime_type": "geo_point",
         "script": {
             "source" : "emit(doc['location'].lat, doc['location'].lon);"
         }
}

where the emit function takes two arguments, the first argument is the latitude and the second argument the longitude.

[elasticmachine]

Pinging @elastic/es-analytics-geo (:Analytics/Geo)

[elasticmachine]

Pinging @elastic/es-search (:Search/Search)

[iverase]

@elasticmachine run elasticsearch-ci/packaging-sample-windows

[iverase]

@elasticmachine run elasticsearch-ci/1

[nik9000]

I took a look and it looks pretty reasonable.

[nik9000]

Is this something we can move into core? It looks like something we'd have there already?

[iverase]

Thats is my plan but it seems more difficult that it looks at first sight as every time we need to map a geometry to a Lucene geometry, it seems to be slightly different. As part of that effort I opened https://issues.apache.org/jira/browse/LUCENE-9552 but I didn't have much support so far. I try to move it.

[nik9000]

Maybe it'd be better to make a new superclass that doesn't have these methods?

[iverase]

The problem is that we already have AbstractNonTextScriptFieldTypeTestCase that extends this class. Those methods are worthy running so adding a superclass you will miss that. My feeling is that we need an abstract class for every type of query and field types will implement all the ones they support?

[nik9000]

So instead of an abstract superclass for the type of field it is per query? I could see that being better, maybe. I'm ok with this as is if we plan to refactor it soon enough anyway.

[iverase]

@elasticmachine run elasticsearch-ci/packaging-sample-windows

[nik9000]

This looks entirely sensible to me.

[iverase]

Moved the PR to ready for review (although thanks Nik, you've done all the work already).

[javanna]

LGTM thanks @iverase . One meta ask is if you could update the description of the PR to include how you can define a geo point runtime field in the mappings, especially around the fact that emit in this case takes two arguments.

@nik9000 would you like to have one last look?

[nik9000]

I'm happy with it! I feel like I should find something worth changing because runtime fields are new and we don't have super established patterns, but I think this is the right things to do.