代码拉取完成，页面将自动刷新
This is by far the most efficient geo-filter because its calculation is very
simple. You provide it with the top, bottom, left, and right
coordinates of a rectangle, and all it does is compare the longitude with the
left and right coordinates, and the latitude with the top and bottom
coordinates:
GET /attractions/restaurant/_search
{
"query": {
"filtered": {
"filter": {
"geo_bounding_box": {
"location": { (1)
"top_left": {
"lat": 40.8,
"lon": -74.0
},
"bottom_right": {
"lat": 40.7,
"lon": -73.0
}
}
}
}
}
}
}
These coordinates can also be specified as bottom_left and top_right.
The geo_bounding_box is the one geo-filter that doesn’t require all
geo-points to be loaded into memory. Because all it has to do is check
whether the lat and lon values fall within the specified ranges, it can
use the inverted index to do a glorified range filter.
To use this optimization, the geo_point field must be mapped to
index the lat and lon values separately:
PUT /attractions
{
"mappings": {
"restaurant": {
"properties": {
"name": {
"type": "string"
},
"location": {
"type": "geo_point",
"lat_lon": true (1)
}
}
}
}
}
The location.lat and location.lon fields will be indexed separately.
These fields can be used for searching, but their values cannot be retrieved.
Now, when we run our query, we have to tell Elasticsearch to use the indexed
lat and lon values:
GET /attractions/restaurant/_search
{
"query": {
"filtered": {
"filter": {
"geo_bounding_box": {
"type": "indexed", (1)
"location": {
"top_left": {
"lat": 40.8,
"lon": -74.0
},
"bottom_right": {
"lat": 40.7,
"lon": -73.0
}
}
}
}
}
}
}
Setting the type parameter to indexed (instead of the default
memory) tells Elasticsearch to use the inverted index for this filter.
|
Caution
|
While a geo_point field can contain multiple geo-points, the
lat_lon optimization can be used only on fields that contain a single
geo-point.
|
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
马建仓 AI 助手