OpenSearch/docs/reference/query-dsl/geo-distance-query.asciidoc

227 lines
5.1 KiB
Plaintext
Raw Normal View History

[[query-dsl-geo-distance-query]]
=== Geo Distance Query
Filters documents that include only hits that exists within a specific
distance from a geo point. Assuming the following mapping and indexed
document:
[source,js]
--------------------------------------------------
Update the default for include_type_name to false. (#37285) * Default include_type_name to false for get and put mappings. * Default include_type_name to false for get field mappings. * Add a constant for the default include_type_name value. * Default include_type_name to false for get and put index templates. * Default include_type_name to false for create index. * Update create index calls in REST documentation to use include_type_name=true. * Some minor clean-ups around the get index API. * In REST tests, use include_type_name=true by default for index creation. * Make sure to use 'expression == false'. * Clarify the different IndexTemplateMetaData toXContent methods. * Fix FullClusterRestartIT#testSnapshotRestore. * Fix the ml_anomalies_default_mappings test. * Fix GetFieldMappingsResponseTests and GetIndexTemplateResponseTests. We make sure to specify include_type_name=true during xContent parsing, so we continue to test the legacy typed responses. XContent generation for the typeless responses is currently only covered by REST tests, but we will be adding unit test coverage for these as we implement each typeless API in the Java HLRC. This commit also refactors GetMappingsResponse to follow the same appraoch as the other mappings-related responses, where we read include_type_name out of the xContent params, instead of creating a second toXContent method. This gives better consistency in the response parsing code. * Fix more REST tests. * Improve some wording in the create index documentation. * Add a note about types removal in the create index docs. * Fix SmokeTestMonitoringWithSecurityIT#testHTTPExporterWithSSL. * Make sure to mention include_type_name in the REST docs for affected APIs. * Make sure to use 'expression == false' in FullClusterRestartIT. * Mention include_type_name in the REST templates docs.
2019-01-14 16:08:01 -05:00
PUT /my_locations?include_type_name=true
{
"mappings": {
"_doc": {
"properties": {
"pin": {
"properties": {
"location": {
"type": "geo_point"
}
}
}
}
}
}
}
PUT /my_locations/_doc/1
{
"pin" : {
"location" : {
"lat" : 40.12,
"lon" : -71.34
}
}
}
--------------------------------------------------
// CONSOLE
// TESTSETUP
Then the following simple query can be executed with a `geo_distance`
filter:
[source,js]
--------------------------------------------------
GET /my_locations/_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
},
"filter" : {
"geo_distance" : {
"distance" : "200km",
"pin.location" : {
"lat" : 40,
"lon" : -70
}
}
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Accepted Formats
In much the same way the `geo_point` type can accept different
representations of the geo point, the filter can accept it as well:
[float]
===== Lat Lon As Properties
[source,js]
--------------------------------------------------
GET /my_locations/_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
},
"filter" : {
"geo_distance" : {
"distance" : "12km",
"pin.location" : {
"lat" : 40,
"lon" : -70
}
}
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
===== Lat Lon As Array
Format in `[lon, lat]`, note, the order of lon/lat here in order to
conform with http://geojson.org/[GeoJSON].
[source,js]
--------------------------------------------------
GET /my_locations/_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
},
"filter" : {
"geo_distance" : {
"distance" : "12km",
"pin.location" : [-70, 40]
}
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
===== Lat Lon As String
Format in `lat,lon`.
[source,js]
--------------------------------------------------
GET /my_locations/_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
},
"filter" : {
"geo_distance" : {
"distance" : "12km",
"pin.location" : "40,-70"
}
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
===== Geohash
[source,js]
--------------------------------------------------
GET /my_locations/_search
{
"query": {
"bool" : {
"must" : {
"match_all" : {}
},
"filter" : {
"geo_distance" : {
"distance" : "12km",
"pin.location" : "drm3btev3e86"
}
}
}
}
}
--------------------------------------------------
// CONSOLE
[float]
==== Options
The following are options allowed on the filter:
[horizontal]
`distance`::
The radius of the circle centred on the specified location. Points which
fall into this circle are considered to be matches. The `distance` can be
specified in various units. See <<distance-units>>.
`distance_type`::
How to compute the distance. Can either be `arc` (default), or `plane` (faster, but inaccurate on long distances and close to the poles).
`_name`::
Optional name field to identify the query
`validation_method`::
Set to `IGNORE_MALFORMED` to accept geo points with invalid latitude or
longitude, set to `COERCE` to additionally try and infer correct
coordinates (default is `STRICT`).
[float]
==== geo_point Type
The filter *requires* the `geo_point` type to be set on the relevant
field.
[float]
==== Multi Location Per Document
The `geo_distance` filter can work with multiple locations / points per
document. Once a single location / point matches the filter, the
document will be included in the filter.
[float]
==== Ignore Unmapped
When set to `true` the `ignore_unmapped` option will ignore an unmapped field
and will not match any documents for this query. This can be useful when
querying multiple indexes which might have different mappings. When set to
`false` (the default value) the query will throw an exception if the field
is not mapped.