前言
计算搜索中两点之间的距离有很多用例。 如果你正在处理地理数据，那么无论你从事何种业务，这都必然会出现。 然后，在对这些点进行排序时，你可能需要考虑距离，因为……好吧，为什么不呢？
建立我们的例子
对于这个例子，假设我们是一家食品配送初创公司。 也许是美团 或点评之类的东西。我们有一个移动应用程序，用户可以在其中输入他们的搜索词（即 “Chinese food”）。 然后，我们的应用程序会按照在我们的数据库中找到的随机顺序列出所有包含该术语的餐馆。
我们可能将每个场所的经纬度都保存在数据库中。如果不是，那么我们可能会计算每个场所的 geohash 并保存它。
然而，要开始充分利用 ES 的地理查询，我们应该将这些值转换为 geopoints。
使用 geopoint 字段
方便的是，Elasticsearch 允许你以你碰巧保存的任何格式上传地理点：纬度/经度对象、geohashes、字符串、字符串数组、WKT POINT 基元等。 看一看：
1. // Geopoint as an object with 'lat' and 'lon' keys
2. "location": {
3. "lat": 41.12,
4. "lon": -71.34
5. }
7. // Geopoint as an array
8. "location": [ -71.34, 41.12 ] # [ long, lat ]
10. // Geopoint as a string
11. "location": "41.12,-71.34"
13. // Geopoint as a geohash
14. "location": "drm3btev3e86"
16. // Geopoint as an object using GeoJSON format
17. "location": {
18. "type": "Point",
19. "coordinates": [-71.34, 41.12] # [ long, lat ]
20. }
22. // Geopoint as a WKT POINT primitive
23. "location" : "POINT (-71.34 41.12)"
这里有几点需要注意：
首先，location 是一个任意名称，我们可以随意命名我们的地理点字段。
其次，我们需要在上传任何文件之前声明 location 字段的类型。 这是因为，除非我们明确告诉 Elasticsearch “41.12,-71.34” 是一个地理点，否则它会将其解释为文本。 同样，它会将 [-71.34, 41.12] 视为一个数字数组。
从 geopoint 文档中，让我指出两个非常重要的注释：
注意：一个点可以表示为一个 geohash。 Geohashes 是交错的纬度和经度位的 base32 编码字符串。 geohash 中的每个字符都会增加额外的 5 位精度。 所以 hash 值越长，它就越精确。 为了索引目的，geohashes 被翻译成纬度-经度对。 在此过程中仅使用前 12 个字符，因此在 geohash 中指定超过 12 个字符不会提高精度。 12 个字符提供 60 位，应该可以将可能的错误减少到小于 2cm。
有关 geohash 的更多描述，请阅读我之前的文章 “Elasticsearch：理解 Elastic Maps 中的 geohash 及其聚合”。
重要：以数组或字符串表示的地理点请注意，字符串地理点按纬度、经度排序，而数组 geopoints、GeoJSON 和 WKT 则按相反顺序排序：经度、纬度。
这是有历史原因的。 地理学家传统上将纬度写在经度之前，而最近为地理数据指定的格式（如 GeoJSON 和 Well-Known Text）将经度排序在纬度之前（东在北之前），以便与 x 在 y 之前排序的数学惯例相匹配。
每个字段都有一个类型（或 mapping），这很重要，因为每种类型的数据都需要以特定的方式存储，以便快速搜索。 Elasticsearch 可以在你上传新文档时动态生成映射，但有时需要显式声明它们。
对于我们的示例，让我们创建一个名为 establishments 的简单索引。
1. PUT establishments
2. {
3. "mappings": {
4. "properties": {
5. "name": {
6. "type": "text"
7. },
8. "location": {
9. "type": "geo_point"
10. }
11. }
12. }
13. }
请注意，我们在上面显示指明 location 字段为 geo_point 类型。如果我们不这么做，那么当我们写入文档时，location 字段会被自动映射为 text 类型的字段。这显然不是我们所需要的。
接下来，让我们创建一下 sample 文档，虽然是假设的一些位置点。我们使用如下的命令来写入 8 个文档：
1. POST _bulk
2. { "create" : { "_index" : "establishments", "_id" : "1" } }
3. { "name" : "Establishment 1", "location": {"lat": 40.7367026, "lon": -73.8028177}}
4. { "create" : { "_index" : "establishments", "_id" : "2" } }
5. { "name" : "Establishment 2", "location": {"lat": 40.7417101, "lon": -73.8083109}}
6. { "create" : { "_index" : "establishments", "_id" : "3" } }
7. { "name" : "Establishment 3", "location": {"lat": 40.7361652, "lon": -73.7904442}}
8. { "create" : { "_index" : "establishments", "_id" : "4" } }
9. { "name" : "Establishment 4", "location": {"lat": 40.7503261, "lon": -73.7791284}}
10. { "create" : { "_index" : "establishments", "_id" : "5" } }
11. { "name" : "Establishment 5", "location": {"lat": 40.7457094, "lon": -73.792518}}
12. { "create" : { "_index" : "establishments", "_id" : "6" } }
13. { "name" : "Establishment 6", "location": {"lat": 40.7393039, "lon": -73.8151344}}
14. { "create" : { "_index" : "establishments", "_id" : "7" } }
15. { "name" : "Establishment 7", "location": {"lat": 40.7464897, "lon": -73.8032898}}
16. { "create" : { "_index" : "establishments", "_id" : "8" } }
17. { "name" : "Establishment 8", "location": {"lat": 40.7440512, "lon": -73.7823042}}
这是我们的纽约皇后区地图，其中包含我们的八家场所（蓝色）和我们假设的客户（橙色）：
建立最大距离
我们的首要任务是在客户和我们将从查询中返回的场所之间建立最大距离。 换句话说，我们应该只搜索客户一定半径范围内的场所。 我将把检索客户坐标的次要任务留给你，但我们肯定需要它们。
实际上有一个简单的 geo_distance 查询：
1. GET establishments/_search?filter_path=**.hits
2. {
3. "query": {
4. "bool": {
5. "must": {
6. "geo_distance": {
7. "distance": "1km", // radius or max_distance
8. "location": { // our geopoint field name
9. "lat": 40.74049, // client.lat
10. "lon": -73.80549 // client.lon
11. }
12. }
13. }
14. }
15. }
16. }
我们可以使用各种单位来确定半径：英里、码、英尺、英寸、米、公里、厘米、毫米，甚至海里。 我们还可以用各种方式格式化我们的位置对象，就像我们第一次创建文档时所做的那样。
这是我们查询的结果：
1. {
2. "hits": {
3. "hits": [
4. {
5. "_index": "establishments",
6. "_id": "1",
7. "_score": 1,
8. "_source": {
9. "name": "Establishment 1",
10. "location": {
11. "lat": 40.7367026,
12. "lon": -73.8028177
13. }
14. }
15. },
16. {
17. "_index": "establishments",
18. "_id": "2",
19. "_score": 1,
20. "_source": {
21. "name": "Establishment 2",
22. "location": {
23. "lat": 40.7417101,
24. "lon": -73.8083109
25. }
26. }
27. },
28. {
29. "_index": "establishments",
30. "_id": "6",
31. "_score": 1,
32. "_source": {
33. "name": "Establishment 6",
34. "location": {
35. "lat": 40.7393039,
36. "lon": -73.8151344
37. }
38. }
39. },
40. {
41. "_index": "establishments",
42. "_id": "7",
43. "_score": 1,
44. "_source": {
45. "name": "Establishment 7",
46. "location": {
47. "lat": 40.7464897,
48. "lon": -73.8032898
49. }
50. }
51. }
52. ]
53. }
54. }
上面显示 1，2，6, 7 文档被搜索到，因为它们离客户在 1km 之内。
按距离对结果排序
但是，如果你仔细查看我们上面的地图，你会注意到 Establishment 2 实际上离客户最近，因此我们的结果没有按距离排序。 默认情况下，Elasticsearch 按相关性分数对结果进行排序，相关性分数位于每个文档的 _score 字段中。
但是，你会注意到在上面的查询中，返回的所有场所都具有相同的相关性分数。 当每个文档都同样 “相关” 时，它们的顺序大多是随机的。 但是……为什么分数相同？
这是因为 geo_distance 查询是一种是或否类型的事情。 该场所要么在半径范围内，要么不在半径范围内。 所有四个场所都在半径内 “相等”，因此它们都具有相同的分数。
验证这一点的一种方法是在我们运行查询时使用 explain: true 参数：
1. GET establishments/_search
2. {
3. "explain": true,
4. "query": {
5. "bool": {
6. "must": {
7. "geo_distance": {
8. "distance": "1km",
9. "location": {
10. "lat": 40.74049,
11. "lon": -73.80549
12. }
13. }
14. }
15. }
16. }
17. }
上述命令返回的结果为：
1. {
2. "took": 8,
3. "timed_out": false,
4. "_shards": {
5. "total": 1,
6. "successful": 1,
7. "skipped": 0,
8. "failed": 0
9. },
10. "hits": {
11. "total": {
12. "value": 4,
13. "relation": "eq"
14. },
15. "max_score": 1,
16. "hits": [
17. {
18. "_shard": "[establishments][0]",
19. "_node": "tZLy82KRTaiCdpsbkEYnuA",
20. "_index": "establishments",
21. "_id": "1",
22. "_score": 1,
23. "_source": {
24. "name": "Establishment 1",
25. "location": {
26. "lat": 40.7367026,
27. "lon": -73.8028177
28. }
29. },
30. "_explanation": {
31. "value": 1,
32. "description": "location:INTERSECTS:geometries([CIRCLE([40.74048997834325,-73.80549000576138] radius = 1000.0 meters)])",
33. "details": []
34. }
35. },
36. {
37. "_shard": "[establishments][0]",
38. "_node": "tZLy82KRTaiCdpsbkEYnuA",
39. "_index": "establishments",
40. "_id": "2",
41. "_score": 1,
42. "_source": {
43. "name": "Establishment 2",
44. "location": {
45. "lat": 40.7417101,
46. "lon": -73.8083109
47. }
48. },
49. "_explanation": {
50. "value": 1,
51. "description": "location:INTERSECTS:geometries([CIRCLE([40.74048997834325,-73.80549000576138] radius = 1000.0 meters)])",
52. "details": []
53. }
54. },
55. {
56. "_shard": "[establishments][0]",
57. "_node": "tZLy82KRTaiCdpsbkEYnuA",
58. "_index": "establishments",
59. "_id": "6",
60. "_score": 1,
61. "_source": {
62. "name": "Establishment 6",
63. "location": {
64. "lat": 40.7393039,
65. "lon": -73.8151344
66. }
67. },
68. "_explanation": {
69. "value": 1,
70. "description": "location:INTERSECTS:geometries([CIRCLE([40.74048997834325,-73.80549000576138] radius = 1000.0 meters)])",
71. "details": []
72. }
73. },
74. {
75. "_shard": "[establishments][0]",
76. "_node": "tZLy82KRTaiCdpsbkEYnuA",
77. "_index": "establishments",
78. "_id": "7",
79. "_score": 1,
80. "_source": {
81. "name": "Establishment 7",
82. "location": {
83. "lat": 40.7464897,
84. "lon": -73.8032898
85. }
86. },
87. "_explanation": {
88. "value": 1,
89. "description": "location:INTERSECTS:geometries([CIRCLE([40.74048997834325,-73.80549000576138] radius = 1000.0 meters)])",
90. "details": []
91. }
92. }
93. ]
94. }
95. }
explain 参数附加到每个文档，说明该文档的分数是如何计算的。 对于上面的查询，请注意每个文档都有相同的解释，因此得分相同。
选项 1：如果你需要距离来影响分数
然而，许多 Elasticsearch 查询都经过精心构造，以便第一个结果与用户最相关。 这可能意味着优先考虑名称和描述中包含确切关键字的场所，或最新的场所，或评级最高或评论最多的场所。
在我们的案例中，我们希望优先考虑离客户最近的地方。 这就是 distance_feature 查询的用途：
1. GET establishments/_search?filter_path=**.hits
2. {
3. "query": {
4. "bool": {
5. "must": {
6. "geo_distance": {
7. "distance": "1km", // radius or max_distance
8. "location": { // our geopoint field name
9. "lat": 40.74049, // client.lat
10. "lon": -73.80549 // client.lon
11. }
12. }
13. },
14. "should": {
15. "distance_feature": {
16. "field": "location", // our geopoint field name
17. "pivot": "1km", // radius or max_distance
18. "origin": {
19. "lat": 40.74049, // client.lat
20. "lon": -73.80549 // client.long
21. }
22. }
23. }
24. }
25. }
26. }
这些是我们得到的结果，现在顺序不同（2、1、7、6）。 请注意，相关性分数不再相同。
1. {
2. "hits": {
3. "hits": [
4. {
5. "_index": "establishments",
6. "_id": "2",
7. "_score": 1.7851406,
8. "_source": {
9. "name": "Establishment 2",
10. "location": {
11. "lat": 40.7417101,
12. "lon": -73.8083109
13. }
14. }
15. },
16. {
17. "_index": "establishments",
18. "_id": "1",
19. "_score": 1.6767981,
20. "_source": {
21. "name": "Establishment 1",
22. "location": {
23. "lat": 40.7367026,
24. "lon": -73.8028177
25. }
26. }
27. },
28. {
29. "_index": "establishments",
30. "_id": "7",
31. "_score": 1.5908757,
32. "_source": {
33. "name": "Establishment 7",
34. "location": {
35. "lat": 40.7464897,
36. "lon": -73.8032898
37. }
38. }
39. },
40. {
41. "_index": "establishments",
42. "_id": "6",
43. "_score": 1.548491,
44. "_source": {
45. "name": "Establishment 6",
46. "location": {
47. "lat": 40.7393039,
48. "lon": -73.8151344
49. }
50. }
51. }
52. ]
53. }
54. }
在查询中添加一个 explain: true 参数，看看我们第一个结果的解释字段。 现在有两个单独计算的查询（该场所是否在客户端 1 公里半径范围内？以及该场所离客户端有多近？），文档的最终分数 (1.7851406) 是每个查询返回的分数之和 ( 1 0.78514063）。
distance_feature 计算比 geo_distance 计算稍微复杂一点，但它仍然很容易理解：
1. {
2. "hits": {
3. "hits": [
4. {
5. "_shard": "[establishments][0]",
6. "_node": "tZLy82KRTaiCdpsbkEYnuA",
7. "_index": "establishments",
8. "_id": "2",
9. "_score": 1.7851406,
10. "_source": {
11. "name": "Establishment 2",
12. "location": {
13. "lat": 40.7417101,
14. "lon": -73.8083109
15. }
16. },
17. "_explanation": {
18. "value": 1.7851406,
19. "description": "sum of:",
20. "details": [
21. {
22. "value": 1,
23. "description": "location:INTERSECTS:geometries([CIRCLE([40.74048997834325,-73.80549000576138] radius = 1000.0 meters)])",
24. "details": []
25. },
26. {
27. "value": 0.78514063,
28. "description": "Distance score, computed as weight * pivotDistance / (pivotDistance abs(distance)) from:",
29. "details": [
30. {
31. "value": 1,
32. "description": "weight",
33. "details": []
34. },
35. {
36. "value": 1000,
37. "description": "pivotDistance",
38. "details": []
39. },
40. {
41. "value": 40.74049,
42. "description": "originLat",
43. "details": []
44. },
45. {
46. "value": -73.80549,
47. "description": "originLon",
48. "details": []
49. },
50. {
51. "value": 40.74171009007841,
52. "description": "current lat",
53. "details": []
54. },
55. {
56. "value": -73.80831093527377,
57. "description": "current lon",
58. "details": []
59. },
60. {
61. "value": 273.6571662222462,
62. "description": "distance",
63. "details": []
64. }
65. ]
66. }
67. ]
68. }
69. },
70. {
71. "_shard": "[establishments][0]",
72. "_node": "tZLy82KRTaiCdpsbkEYnuA",
73. "_index": "establishments",
74. "_id": "1",
75. "_score": 1.6767981,
76. "_source": {
77. "name": "Establishment 1",
78. "location": {
79. "lat": 40.7367026,
80. "lon": -73.8028177
81. }
82. },
83. "_explanation": {
84. "value": 1.6767981,
85. "description": "sum of:",
86. "details": [
87. {
88. "value": 1,
89. "description": "location:INTERSECTS:geometries([CIRCLE([40.74048997834325,-73.80549000576138] radius = 1000.0 meters)])",
90. "details": []
91. },
92. {
93. "value": 0.67679805,
94. "description": "Distance score, computed as weight * pivotDistance / (pivotDistance abs(distance)) from:",
95. "details": [
96. {
97. "value": 1,
98. "description": "weight",
99. "details": []
100. },
101. {
102. "value": 1000,
103. "description": "pivotDistance",
104. "details": []
105. },
106. {
107. "value": 40.74049,
108. "description": "originLat",
109. "details": []
110. },
111. {
112. "value": -73.80549,
113. "description": "originLon",
114. "details": []
115. },
116. {
117. "value": 40.73670257348567,
118. "description": "current lat",
119. "details": []
120. },
121. {
122. "value": -73.80281777121127,
123. "description": "current lon",
124. "details": []
125. },
126. {
127. "value": 477.5456174201007,
128. "description": "distance",
129. "details": []
130. }
131. ]
132. }
133. ]
134. }
135. },
136. {
137. "_shard": "[establishments][0]",
138. "_node": "tZLy82KRTaiCdpsbkEYnuA",
139. "_index": "establishments",
140. "_id": "7",
141. "_score": 1.5908757,
142. "_source": {
143. "name": "Establishment 7",
144. "location": {
145. "lat": 40.7464897,
146. "lon": -73.8032898
147. }
148. },
149. "_explanation": {
150. "value": 1.5908757,
151. "description": "sum of:",
152. "details": [
153. {
154. "value": 1,
155. "description": "location:INTERSECTS:geometries([CIRCLE([40.74048997834325,-73.80549000576138] radius = 1000.0 meters)])",
156. "details": []
157. },
158. {
159. "value": 0.59087574,
160. "description": "Distance score, computed as weight * pivotDistance / (pivotDistance abs(distance)) from:",
161. "details": [
162. {
163. "value": 1,
164. "description": "weight",
165. "details": []
166. },
167. {
168. "value": 1000,
169. "description": "pivotDistance",
170. "details": []
171. },
172. {
173. "value": 40.74049,
174. "description": "originLat",
175. "details": []
176. },
177. {
178. "value": -73.80549,
179. "description": "originLon",
180. "details": []
181. },
182. {
183. "value": 40.746489660814404,
184. "description": "current lat",
185. "details": []
186. },
187. {
188. "value": -73.80328983999789,
189. "description": "current lon",
190. "details": []
191. },
192. {
193. "value": 692.403259865101,
194. "description": "distance",
195. "details": []
196. }
197. ]
198. }
199. ]
200. }
201. },
202. {
203. "_shard": "[establishments][0]",
204. "_node": "tZLy82KRTaiCdpsbkEYnuA",
205. "_index": "establishments",
206. "_id": "6",
207. "_score": 1.548491,
208. "_source": {
209. "name": "Establishment 6",
210. "location": {
211. "lat": 40.7393039,
212. "lon": -73.8151344
213. }
214. },
215. "_explanation": {
216. "value": 1.548491,
217. "description": "sum of:",
218. "details": [
219. {
220. "value": 1,
221. "description": "location:INTERSECTS:geometries([CIRCLE([40.74048997834325,-73.80549000576138] radius = 1000.0 meters)])",
222. "details": []
223. },
224. {
225. "value": 0.548491,
226. "description": "Distance score, computed as weight * pivotDistance / (pivotDistance abs(distance)) from:",
227. "details": [
228. {
229. "value": 1,
230. "description": "weight",
231. "details": []
232. },
233. {
234. "value": 1000,
235. "description": "pivotDistance",
236. "details": []
237. },
238. {
239. "value": 40.74049,
240. "description": "originLat",
241. "details": []
242. },
243. {
244. "value": -73.80549,
245. "description": "originLon",
246. "details": []
247. },
248. {
249. "value": 40.73930389713496,
250. "description": "current lat",
251. "details": []
252. },
253. {
254. "value": -73.81513447500765,
255. "description": "current lon",
256. "details": []
257. },
258. {
259. "value": 823.1840356327418,
260. "description": "distance",
261. "details": []
262. }
263. ]
264. }
265. ]
266. }
267. }
268. ]
269. }
270. }
在上面的分数说明中，你会为每个场所找到一个距离对象。 但这是获取两点之间距离的一种非常迂回的方式。 我不推荐它有几个原因：
- 每次调整查询时，explanation 字段的内容都会发生变化，这使得从那里检索距离的操作非常不稳定。
- explanation 字段存储了除距离之外的许多信息，因此你将耗尽资源并将不必要的数据返回给客户端。
- 从语义上讲，这不是解释字段的用途。 它是一个调试工具，而不是一个查询。
还有其他几种方法可以做到这一点。
选项 2：如果你需要实际距离
我们可以使用脚本在运行时生成新的 distance 字段。 公平警告：脚本查询通常比内置查询更昂贵，但如有必要，可以对其进行优化。 如果可以，尽量避免过早优化； Elasticsearch 确实快得惊人。
1. GET establishments/_search?filter_path=**.hits
2. {
3. "script_fields" : {
4. "distance" : { // name of field you're generating
5. "script" : {
6. // value of the field you're generating
7. "source": "doc['location'].arcDistance(params.lat,params.lon)",
8. "params": {
9. "lat": 40.74049, // client.lat
10. "lon": -73.80549 // client.lon
11. }
12. }
13. }
14. },
15. "query": {
16. "bool": {
17. "must": {
18. "geo_distance": {
19. "distance": "1km", // radius
20. "location": {
21. "lat": 40.74049, // client.lat
22. "lon": -73.80549 // client.lon
23. }
24. }
25. },
26. "should": {
27. "distance_feature": {
28. "field": "location",
29. "pivot": "1km", // radius
30. "origin": {
31. "lat": 40.74049, // client.lat
32. "lon": -73.80549 // client.lon
33. }
34. }
35. }
36. }
37. }
38. }
arcDistance 函数内置于 Elasticsearch 并返回以米为单位的距离。 我们的结果现在告诉我们每个场所离客户有多远：
1. {
2. "hits": {
3. "hits": [
4. {
5. "_index": "establishments",
6. "_id": "2",
7. "_score": 1.7851406,
8. "fields": {
9. "distance": [
10. 273.6571662222462
11. ]
12. }
13. },
14. {
15. "_index": "establishments",
16. "_id": "1",
17. "_score": 1.6767981,
18. "fields": {
19. "distance": [
20. 477.5456174201007
21. ]
22. }
23. },
24. {
25. "_index": "establishments",
26. "_id": "7",
27. "_score": 1.5908757,
28. "fields": {
29. "distance": [
30. 692.403259865101
31. ]
32. }
33. },
34. {
35. "_index": "establishments",
36. "_id": "6",
37. "_score": 1.548491,
38. "fields": {
39. "distance": [
40. 823.1840356327418
41. ]
42. }
43. }
44. ]
45. }
46. }
选项 3：如果你需要距离而不是分数
对于分数不重要的情况，还有第三种选择。 sort 查询将按照所宣传的那样进行，并按照给定的标准对结果进行排序。 在我们的例子中，这个标准可以是客户和场所之间的距离。
1. GET establishments/_search?filter_path=**.hits
2. {
3. "query": {
4. "bool": {
5. "must": {
6. "geo_distance": {
7. "distance": "1km",
8. "location": {
9. "lat": 40.74049,
10. "lon": -73.80549
11. }
12. }
13. }
14. }
15. },
16. "sort" : [
17. {
18. "_geo_distance" : {
19. "location" : {
20. "lat" : 40.74049,
21. "lon" : -73.80549
22. },
23. "order" : "asc",
24. "unit" : "m",
25. "mode" : "min"
26. }
27. }
28. ]
29. }
这些是结果。 请注意，顺序与上面的查询 (2, 1, 7, 6) 相同，但每个文档的相关性分数现在为空。 另一方面，因为我们没有使用脚本，这个搜索可能会比上面的搜索更快。
1. {
2. "hits": {
3. "hits": [
4. {
5. "_index": "establishments",
6. "_id": "2",
7. "_score": null,
8. "_source": {
9. "name": "Establishment 2",
10. "location": {
11. "lat": 40.7417101,
12. "lon": -73.8083109
13. }
14. },
15. "sort": [
16. 273.6571662222462
17. ]
18. },
19. {
20. "_index": "establishments",
21. "_id": "1",
22. "_score": null,
23. "_source": {
24. "name": "Establishment 1",
25. "location": {
26. "lat": 40.7367026,
27. "lon": -73.8028177
28. }
29. },
30. "sort": [
31. 477.5456174201007
32. ]
33. },
34. {
35. "_index": "establishments",
36. "_id": "7",
37. "_score": null,
38. "_source": {
39. "name": "Establishment 7",
40. "location": {
41. "lat": 40.7464897,
42. "lon": -73.8032898
43. }
44. },
45. "sort": [
46. 692.403259865101
47. ]
48. },
49. {
50. "_index": "establishments",
51. "_id": "6",
52. "_score": null,
53. "_source": {
54. "name": "Establishment 6",
55. "location": {
56. "lat": 40.7393039,
57. "lon": -73.8151344
58. }
59. },
60. "sort": [
61. 823.1840356327418
62. ]
63. }
64. ]
65. }
66. }
就是这样！ 感谢阅读，如果你对如何在 Elasticsearch 中按距离计算和排序有任何其他想法，请告诉我。
本文出至：学新通技术网
赏
本站名称：
学新通技术网
版权声明：本站部分内容来自互联网，仅供学习及演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系，请提供相关证据及您的身份证明，我们将在收到邮件后48小时内删除。
联系方式：luke.wu@swvq.com
标签：
