-
Notifications
You must be signed in to change notification settings - Fork 25.3k
Add runtime field of type geo_shape #100492
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Pinging @elastic/es-analytics-geo (Team:Analytics) |
Hi @iverase, I've created a changelog YAML for you. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly LGTM, but I have a question about concurrency that I think we need to address before merge.
...main/java/org/elasticsearch/xpack/spatial/index/mapper/GeoShapeWithDocValuesFieldMapper.java
Outdated
Show resolved
Hide resolved
...main/java/org/elasticsearch/xpack/spatial/search/runtime/GeoShapeScriptFieldExistsQuery.java
Outdated
Show resolved
Hide resolved
...in/java/org/elasticsearch/xpack/spatial/search/runtime/GeoShapeScriptFieldGeoShapeQuery.java
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
@elasticmachine update branch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice feature. I was worried about how most tests just used points, but I see the yaml tests do a much better job of covering other types. I did have a number of comments that could be considered, and also noticed that there exists documentation for using geo_point_field
in painless, but did not see anything for geometry_field
. Should that be added to a separate PR?
context.lookup(), | ||
OnScriptError.FAIL | ||
); | ||
GeometryFieldScript geoPointFieldScript = leafFactory.newInstance(leafReaderContext); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
variable name is from previous block
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, updated.
@@ -259,6 +259,50 @@ public void testGeoPointFieldExecutionContext() throws IOException { | |||
assertEquals("Point", points.get(1).get("type")); | |||
} | |||
|
|||
@SuppressWarnings("unchecked") | |||
public void testGeoShapeFieldExecutionContext() throws IOException { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test seems to be a copy of the geo_point test, with just the field context name changed. Is this because we cannot test actual shapes in server, so just verify that the new script context can handle points? Should we refactor this to a private method with a single parameter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I improved the test, thanks!
) { | ||
@Override | ||
public void execute() { | ||
emitFromObject("POINT(0 0)"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there perhaps value in testing something more than a point, perhaps a two point linestring?
geoFormatterFactory, | ||
meta.get() | ||
); | ||
if (script.get() == null) { | ||
return new GeoShapeWithDocValuesFieldMapper( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed these two versions of the constructor, but when looking up the constructor stack, I see they do ultimately end up at the same place, so I wonder if it is not cleaner to have a single constructor with just null for the script parts when missing? This would reduce code in several classes that have multiple constructors just for scripts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The base class expect a different constructor to be used. This might be a nice follow up but not for this PR as it touches other mappings like geo_point.
@@ -339,6 +393,21 @@ public GeoShapeWithDocValuesFieldMapper( | |||
this.indexer = indexer; | |||
} | |||
|
|||
protected GeoShapeWithDocValuesFieldMapper( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as above that we could remove these extra constructors, I think.
import static java.util.Collections.emptyMap; | ||
import static org.hamcrest.Matchers.equalTo; | ||
|
||
public class GeoShapeScriptFieldTypeTests extends AbstractNonTextScriptFieldTypeTestCase { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All these tests seem to test only points. I wonder if there is value in testing something a little more complex, perhaps at least a two point linestring?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed to run with a LINESTRING
search: | ||
index: geometries | ||
body: | ||
aggs: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fact that max-lat==max-lon==6 and min-lat==min-lon==-1 makes it harder to test for the possibility that x/y get swapped. When I looked through the assertions below at first I thought there was a x/y swapping error, before I realized my mistake. These results are correct for the original data provided.
This PR adds the possibility to create runtime fields of type geo-shape. In order to create them, user s can define an emit function that takes either a geojson object or a WKT string that internally creates a geo_shape object. For example from a geo_shape doc value, we can generate the WKT representing the bounding box of the shape like (in yaml):
closes #61299