Support geo label position through REST vector tiles API#86458
Support geo label position through REST vector tiles API#86458craigtaverner merged 6 commits intoelastic:masterfrom
Conversation
|
Hi @craigtaverner, I've created a changelog YAML for you. |
cd3df0f to
f93565b
Compare
|
Hi @craigtaverner, I've created a changelog YAML for you. |
2f65f05 to
0c6c2b1
Compare
|
Pinging @elastic/es-analytics-geo (Team:Analytics) |
|
Pinging @elastic/clients-team (Team:Clients) |
And added more tests for aggs layer label features
153ac85 to
6354bd7
Compare
iverase
left a comment
There was a problem hiding this comment.
I think we need to add a yaml test here: https://github.com/elastic/elasticsearch/blob/9a60aa8b64209740616266c2607b4600d90f3b6b/x-pack/plugin/src/yamlRestTest/resources/rest-api-spec/test/vector-tile/10_basic.yml
apart from that I tried locally and it is looking great!
|
In addition, can we update the description of the PR because it is used to generate the release notes? |
| featureBuilder.mergeFrom(labelPosFeature); | ||
| VectorTileUtils.addPropertyToFeature(featureBuilder, layerProps, ID_TAG, searchHit.getId()); | ||
| VectorTileUtils.addPropertyToFeature(featureBuilder, layerProps, LABEL_POSITION_TAG, true); | ||
| hitsLayerBuilder.addFeatures(featureBuilder); |
There was a problem hiding this comment.
I think we agreed that we should add all the tags that we added to the feature that is not a tag. That brings the question to what happens if the user has defined an attribute with the same name as the label?
There was a problem hiding this comment.
I think both concerns are considered in 9fa8c00
| VectorTileUtils.addPropertyToFeature(featureBuilder, layerProps, KEY_TAG, bucketKey); | ||
| VectorTileUtils.addPropertyToFeature(featureBuilder, layerProps, LABEL_POSITION_TAG, true); | ||
| aggLayerBuilder.addFeatures(featureBuilder); | ||
| } |
There was a problem hiding this comment.
I think we agreed that we should add all the tags that we added to the feature that is not a tag. That brings the question to what happens if the user has defined an attribute with the same name as the label?
There was a problem hiding this comment.
I think both concerns are considered in 9fa8c00
* Use _mvt_ prefix for all internal tags * Remove runtime field from original feature * Copy all original tags to label position geometries * Same with aggs (copy to label position)
| * `LineString` features will likewise provide a roughly central point selected | ||
| from the <<geoshape-indexing-approach,triangle-tree>>. | ||
| * The aggregation results will provide one central point for each aggregation bucket. | ||
|
|
There was a problem hiding this comment.
Use + instead of empty line so statement below is indented under with_labels option
There was a problem hiding this comment.
I will add that the label features inherit all the attributes from its corresponding original feature.
There was a problem hiding this comment.
I had tried that before, but it indented too much (made it part of the last bullet point). However, now I tried again, this time with an extra newline before the + and voila! It indented the right amount!
There was a problem hiding this comment.
I fixed both your suggestions in 1c69a4a
There is a need to provide sensibly calculated label positions for polygons and lines in Kibana maps (as requested in #86044). A very convenient way to satisfy this need is through a runtime field that the rest API can make use of when labels are requested. This has the advantage of providing painless access to the label position as well.
Building onto #86154, this PR adds support for the REST API to provide label positions to MVT queries, both for the HITS layer and the AGGS layer. To enable this feature, set
with_labelstotrueas a query parameter to the vector tile search query.Closes #86044