mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-13 08:25:26 +00:00
36a3b84fc9
* 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.
169 lines
4.7 KiB
Plaintext
169 lines
4.7 KiB
Plaintext
[[query-dsl-geo-shape-query]]
|
|
=== GeoShape Query
|
|
|
|
Filter documents indexed using the `geo_shape` type.
|
|
|
|
Requires the <<geo-shape,`geo_shape` Mapping>>.
|
|
|
|
The `geo_shape` query uses the same grid square representation as the
|
|
`geo_shape` mapping to find documents that have a shape that intersects
|
|
with the query shape. It will also use the same Prefix Tree configuration
|
|
as defined for the field mapping.
|
|
|
|
The query supports two ways of defining the query shape, either by
|
|
providing a whole shape definition, or by referencing the name of a shape
|
|
pre-indexed in another index. Both formats are defined below with
|
|
examples.
|
|
|
|
==== Inline Shape Definition
|
|
|
|
Similar to the `geo_shape` type, the `geo_shape` query uses
|
|
http://www.geojson.org[GeoJSON] to represent shapes.
|
|
|
|
Given the following index:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
PUT /example?include_type_name=true
|
|
{
|
|
"mappings": {
|
|
"_doc": {
|
|
"properties": {
|
|
"location": {
|
|
"type": "geo_shape"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
|
|
POST /example/_doc?refresh
|
|
{
|
|
"name": "Wind & Wetter, Berlin, Germany",
|
|
"location": {
|
|
"type": "point",
|
|
"coordinates": [13.400544, 52.530286]
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
// TESTSETUP
|
|
|
|
The following query will find the point using the Elasticsearch's
|
|
`envelope` GeoJSON extension:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
GET /example/_search
|
|
{
|
|
"query":{
|
|
"bool": {
|
|
"must": {
|
|
"match_all": {}
|
|
},
|
|
"filter": {
|
|
"geo_shape": {
|
|
"location": {
|
|
"shape": {
|
|
"type": "envelope",
|
|
"coordinates" : [[13.0, 53.0], [14.0, 52.0]]
|
|
},
|
|
"relation": "within"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
==== Pre-Indexed Shape
|
|
|
|
The Query also supports using a shape which has already been indexed in
|
|
another index. This is particularly useful for when
|
|
you have a pre-defined list of shapes which are useful to your
|
|
application and you want to reference this using a logical name (for
|
|
example 'New Zealand') rather than having to provide their coordinates
|
|
each time. In this situation it is only necessary to provide:
|
|
|
|
* `id` - The ID of the document that containing the pre-indexed shape.
|
|
* `index` - Name of the index where the pre-indexed shape is. Defaults
|
|
to 'shapes'.
|
|
* `path` - The field specified as path containing the pre-indexed shape.
|
|
Defaults to 'shape'.
|
|
* `routing` - The routing of the shape document if required.
|
|
|
|
The following is an example of using the Filter with a pre-indexed
|
|
shape:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
PUT /shapes?include_type_name=true
|
|
{
|
|
"mappings": {
|
|
"_doc": {
|
|
"properties": {
|
|
"location": {
|
|
"type": "geo_shape"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
|
|
PUT /shapes/_doc/deu
|
|
{
|
|
"location": {
|
|
"type": "envelope",
|
|
"coordinates" : [[13.0, 53.0], [14.0, 52.0]]
|
|
}
|
|
}
|
|
|
|
GET /example/_search
|
|
{
|
|
"query": {
|
|
"bool": {
|
|
"filter": {
|
|
"geo_shape": {
|
|
"location": {
|
|
"indexed_shape": {
|
|
"index": "shapes",
|
|
"id": "deu",
|
|
"path": "location"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// CONSOLE
|
|
|
|
==== Spatial Relations
|
|
|
|
The <<spatial-strategy, geo_shape strategy>> mapping parameter determines
|
|
which spatial relation operators may be used at search time.
|
|
|
|
The following is a complete list of spatial relation operators available:
|
|
|
|
* `INTERSECTS` - (default) Return all documents whose `geo_shape` field
|
|
intersects the query geometry.
|
|
* `DISJOINT` - Return all documents whose `geo_shape` field
|
|
has nothing in common with the query geometry.
|
|
* `WITHIN` - Return all documents whose `geo_shape` field
|
|
is within the query geometry.
|
|
* `CONTAINS` - Return all documents whose `geo_shape` field
|
|
contains the query geometry. Note: this is only supported using the
|
|
`recursive` Prefix Tree Strategy deprecated[6.6]
|
|
|
|
[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.
|