diff --git a/docs/reference/aggregations/bucket/geodistance-aggregation.asciidoc b/docs/reference/aggregations/bucket/geodistance-aggregation.asciidoc index 202ef6960538f..653fabd6a37ad 100644 --- a/docs/reference/aggregations/bucket/geodistance-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/geodistance-aggregation.asciidoc @@ -88,7 +88,7 @@ The specified field must be of type `geo_point` (which can only be set explicitl * Object format: `{ "lat" : 52.3760, "lon" : 4.894 }` - this is the safest format as it is the most explicit about the `lat` & `lon` values * String format: `"52.3760, 4.894"` - where the first number is the `lat` and the second is the `lon` -* Array format: `[4.894, 52.3760]` - which is based on the `GeoJson` standard and where the first number is the `lon` and the second one is the `lat` +* Array format: `[4.894, 52.3760]` - which is based on the GeoJSON standard where the first number is the `lon` and the second one is the `lat` By default, the distance unit is `m` (meters) but it can also accept: `mi` (miles), `in` (inches), `yd` (yards), `km` (kilometers), `cm` (centimeters), `mm` (millimeters). diff --git a/docs/reference/aggregations/metrics/geocentroid-aggregation.asciidoc b/docs/reference/aggregations/metrics/geocentroid-aggregation.asciidoc index 2658ab6683d3c..2a192fe33ed0a 100644 --- a/docs/reference/aggregations/metrics/geocentroid-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/geocentroid-aggregation.asciidoc @@ -153,7 +153,7 @@ The response for the above aggregation: [[geocentroid-aggregation-geo-shape]] ==== Geo Centroid Aggregation on `geo_shape` fields -The centroid metric for geo-shapes is more nuanced than for points. The centroid of a specific aggregation bucket +The centroid metric for geoshapes is more nuanced than for points. The centroid of a specific aggregation bucket containing shapes is the centroid of the highest-dimensionality shape type in the bucket. For example, if a bucket contains shapes comprising of polygons and lines, then the lines do not contribute to the centroid metric. Each type of shape's centroid is calculated differently. Envelopes and circles ingested via the <> are treated @@ -233,12 +233,12 @@ POST /places/_search?size=0 .Using `geo_centroid` as a sub-aggregation of `geohash_grid` ==== The <> -aggregation places documents, not individual geo-points, into buckets. If a +aggregation places documents, not individual geopoints, into buckets. If a document's `geo_point` field contains <>, the document -could be assigned to multiple buckets, even if one or more of its geo-points are +could be assigned to multiple buckets, even if one or more of its geopoints are outside the bucket boundaries. If a `geocentroid` sub-aggregation is also used, each centroid is calculated -using all geo-points in a bucket, including those outside the bucket boundaries. +using all geopoints in a bucket, including those outside the bucket boundaries. This can result in centroids outside of bucket boundaries. ==== diff --git a/docs/reference/indices/index-mgmt.asciidoc b/docs/reference/indices/index-mgmt.asciidoc index 0cda6dbe7ab09..0543da9b2a562 100644 --- a/docs/reference/indices/index-mgmt.asciidoc +++ b/docs/reference/indices/index-mgmt.asciidoc @@ -144,7 +144,7 @@ image::images/index-mgmt/management_index_component_template.png[Component templ section blank. . Define a mapping that contains an <> field named `geo` with a -child <> field named `coordinates`: +child <> field named `coordinates`: + [role="screenshot"] image::images/index-mgmt/management-index-templates-mappings.png[Mapped fields page] diff --git a/docs/reference/ingest/geo-match-enrich-policy-type-ex.asciidoc b/docs/reference/ingest/geo-match-enrich-policy-type-ex.asciidoc index 89230ff499ce6..9425b6555b6cd 100644 --- a/docs/reference/ingest/geo-match-enrich-policy-type-ex.asciidoc +++ b/docs/reference/ingest/geo-match-enrich-policy-type-ex.asciidoc @@ -82,13 +82,13 @@ pipeline. In the pipeline, add an <> that includes: * Your enrich policy. -* The `field` of incoming documents used to match the geo_shape of documents +* The `field` of incoming documents used to match the geoshape of documents from the enrich index. * The `target_field` used to store appended enrich data for incoming documents. This field contains the `match_field` and `enrich_fields` specified in your enrich policy. -* The `shape_relation`, which indicates how the processor matches geo_shapes in - incoming documents to geo_shapes in documents from the enrich index. See +* The `shape_relation`, which indicates how the processor matches geoshapes in + incoming documents to geoshapes in documents from the enrich index. See <<_spatial_relations>> for valid options and more information. [source,console] diff --git a/docs/reference/ingest/processors/enrich.asciidoc b/docs/reference/ingest/processors/enrich.asciidoc index a7cd21a408663..ba014fe5b336b 100644 --- a/docs/reference/ingest/processors/enrich.asciidoc +++ b/docs/reference/ingest/processors/enrich.asciidoc @@ -20,7 +20,7 @@ See <> section for more information about how | `ignore_missing` | no | false | If `true` and `field` does not exist, the processor quietly exits without modifying the document | `override` | no | true | If processor will update fields with pre-existing non-null-valued field. When set to `false`, such fields will not be touched. | `max_matches` | no | 1 | The maximum number of matched documents to include under the configured target field. The `target_field` will be turned into a json array if `max_matches` is higher than 1, otherwise `target_field` will become a json object. In order to avoid documents getting too large, the maximum allowed value is 128. -| `shape_relation` | no | `INTERSECTS` | A spatial relation operator used to match the <> of incoming documents to documents in the enrich index. This option is only used for `geo_match` enrich policy types. The <> mapping parameter determines which spatial relation operators are available. See <<_spatial_relations>> for operators and more information. +| `shape_relation` | no | `INTERSECTS` | A spatial relation operator used to match the <> of incoming documents to documents in the enrich index. This option is only used for `geo_match` enrich policy types. The <> mapping parameter determines which spatial relation operators are available. See <<_spatial_relations>> for operators and more information. include::common-options.asciidoc[] |====== diff --git a/docs/reference/mapping/types/geo-point.asciidoc b/docs/reference/mapping/types/geo-point.asciidoc index 352249f96413e..dd878aa595170 100644 --- a/docs/reference/mapping/types/geo-point.asciidoc +++ b/docs/reference/mapping/types/geo-point.asciidoc @@ -1,20 +1,20 @@ [[geo-point]] -=== Geo-point field type +=== Geopoint field type ++++ -Geo-point +Geopoint ++++ Fields of type `geo_point` accept latitude-longitude pairs, which can be used: -* to find geo-points within a <>, +* to find geopoints within a <>, within a certain <> of a central point, - or within a <> or within a <>. + or within a <> or within a <>. * to aggregate documents <> or by <> from a central point. * to integrate distance into a document's <>. * to <> documents by distance. -There are five ways that a geo-point may be specified, as demonstrated below: +There are five ways that a geopoint may be specified, as demonstrated below: [source,console] -------------------------------------------------- @@ -31,7 +31,7 @@ PUT my-index-000001 PUT my-index-000001/_doc/1 { - "text": "Geo-point as an object", + "text": "Geopoint as an object", "location": { <1> "lat": 41.12, "lon": -71.34 @@ -40,25 +40,25 @@ PUT my-index-000001/_doc/1 PUT my-index-000001/_doc/2 { - "text": "Geo-point as a string", + "text": "Geopoint as a string", "location": "41.12,-71.34" <2> } PUT my-index-000001/_doc/3 { - "text": "Geo-point as a geohash", + "text": "Geopoint as a geohash", "location": "drm3btev3e86" <3> } PUT my-index-000001/_doc/4 { - "text": "Geo-point as an array", + "text": "Geopoint as an array", "location": [ -71.34, 41.12 ] <4> } PUT my-index-000001/_doc/5 { - "text": "Geo-point as a WKT POINT primitive", + "text": "Geopoint as a WKT POINT primitive", "location" : "POINT (-71.34 41.12)" <5> } @@ -81,20 +81,20 @@ GET my-index-000001/_search } -------------------------------------------------- -<1> Geo-point expressed as an object, with `lat` and `lon` keys. -<2> Geo-point expressed as a string with the format: `"lat,lon"`. -<3> Geo-point expressed as a geohash. -<4> Geo-point expressed as an array with the format: [ `lon`, `lat`] -<5> Geo-point expressed as a https://docs.opengeospatial.org/is/12-063r5/12-063r5.html[Well-Known Text] +<1> Geopoint expressed as an object, with `lat` and `lon` keys. +<2> Geopoint expressed as a string with the format: `"lat,lon"`. +<3> Geopoint expressed as a geohash. +<4> Geopoint expressed as an array with the format: [ `lon`, `lat`] +<5> Geopoint expressed as a https://docs.opengeospatial.org/is/12-063r5/12-063r5.html[Well-Known Text] POINT with the format: `"POINT(lon lat)"` -<6> A geo-bounding box query which finds all geo-points that fall inside the box. +<6> A geo-bounding box query which finds all geopoints that fall inside the box. [IMPORTANT] -.Geo-points expressed as an array or string +.Geopoints expressed as an array or string ================================================== -Please note that string geo-points are ordered as `lat,lon`, while array -geo-points are ordered as the reverse: `lon,lat`. +Please note that string geopoints are ordered as `lat,lon`, while array +geopoints are ordered as the reverse: `lon,lat`. Originally, `lat,lon` was used for both array and string, but the array format was changed early on to conform to the format used by GeoJSON. @@ -121,9 +121,9 @@ The following parameters are accepted by `geo_point` fields: <>:: - If `true`, malformed geo-points are ignored. If `false` (default), - malformed geo-points throw an exception and reject the whole document. - A geo-point is considered malformed if its latitude is outside the range + If `true`, malformed geopoints are ignored. If `false` (default), + malformed geopoints throw an exception and reject the whole document. + A geopoint is considered malformed if its latitude is outside the range -90 <= latitude <= 90, or if its longitude is outside the range -180 <= longitude <= 180. Note that this cannot be set if the `script` parameter is used. @@ -131,7 +131,7 @@ The following parameters are accepted by `geo_point` fields: If `true` (default) three dimension points will be accepted (stored in source) but only latitude and longitude values will be indexed; the third dimension is - ignored. If `false`, geo-points containing any more than latitude and longitude + ignored. If `false`, geopoints containing any more than latitude and longitude (two dimensions) values throw an exception and reject the whole document. Note that this cannot be set if the `script` parameter is used. @@ -165,9 +165,9 @@ The following parameters are accepted by `geo_point` fields: <>, and should emit points as a pair of (lat, lon) double values. -==== Using geo-points in scripts +==== Using geopoints in scripts -When accessing the value of a geo-point in a script, the value is returned as +When accessing the value of a geopoint in a script, the value is returned as a `GeoPoint` object, which allows access to the `.lat` and `.lon` values respectively: diff --git a/docs/reference/mapping/types/geo-shape.asciidoc b/docs/reference/mapping/types/geo-shape.asciidoc index 6f829b802f167..55de63f7ab28a 100644 --- a/docs/reference/mapping/types/geo-shape.asciidoc +++ b/docs/reference/mapping/types/geo-shape.asciidoc @@ -1,7 +1,7 @@ [[geo-shape]] -=== Geo-shape field type +=== Geoshape field type ++++ -Geo-shape +Geoshape ++++ The `geo_shape` data type facilitates the indexing of and searching @@ -10,14 +10,14 @@ used when either the data being indexed or the queries being executed contain shapes other than just points. You can query documents using this type using -<>. +a <>. [[geo-shape-mapping-options]] [discrete] ==== Mapping Options -The geo_shape mapping maps geo_json geometry objects to the geo_shape -type. To enable it, users must explicitly map fields to the geo_shape +The `geo_shape` mapping maps GeoJSON geometry objects to the `geo_shape` +type. To enable it, users must explicitly map fields to the `geo_shape` type. [cols="<,<,<",options="header",] @@ -122,7 +122,7 @@ entire document. |`ignore_z_value` |If `true` (default) three dimension points will be accepted (stored in source) but only latitude and longitude values will be indexed; the third dimension is ignored. If `false`, -geo-points containing any more than latitude and longitude (two dimensions) values throw an exception +geopoints containing any more than latitude and longitude (two dimensions) values throw an exception and reject the whole document. | `true` @@ -462,8 +462,8 @@ POST /example/_doc -------------------------------------------------- // TEST[catch:/mapper_parsing_exception/] -An `orientation` parameter can be defined when setting the geo_shape mapping (see <>). This will define vertex -order for the coordinate list on the mapped geo_shape field. It can also be overridden on each document. The following is an example for +An `orientation` parameter can be defined when setting the `geo_shape` mapping (see <>). This will define vertex +order for the coordinate list on the mapped `geo_shape` field. It can also be overridden on each document. The following is an example for overriding the orientation on a document: [source,console] @@ -484,7 +484,7 @@ POST /example/_doc [[geo-multipoint]] ===== http://geojson.org/geojson-spec.html#id5[MultiPoint] -The following is an example of a list of geojson points: +The following is an example of a list of GeoJSON points: [source,console] -------------------------------------------------- @@ -513,7 +513,7 @@ POST /example/_doc [[geo-multilinestring]] ===== http://geojson.org/geojson-spec.html#id6[MultiLineString] -The following is an example of a list of geojson linestrings: +The following is an example of a list of GeoJSON linestrings: [source,console] -------------------------------------------------- @@ -544,7 +544,7 @@ POST /example/_doc [[geo-multipolygon]] ===== http://geojson.org/geojson-spec.html#id7[MultiPolygon] -The following is an example of a list of geojson polygons (second polygon contains a hole): +The following is an example of a list of GeoJSON polygons (second polygon contains a hole): [source,console] -------------------------------------------------- @@ -575,7 +575,7 @@ POST /example/_doc [[geo-geometry_collection]] ===== http://geojson.org/geojson-spec.html#geometrycollection[Geometry Collection] -The following is an example of a collection of geojson geometry objects: +The following is an example of a collection of GeoJSON geometry objects: [source,console] -------------------------------------------------- @@ -693,5 +693,5 @@ the units of the `radius` will default to `METERS`. Due to the complex input structure and index representation of shapes, it is not currently possible to sort shapes or retrieve their fields -directly. The geo_shape value is only retrievable through the `_source` +directly. The `geo_shape` value is only retrievable through the `_source` field. diff --git a/docs/reference/mapping/types/shape.asciidoc b/docs/reference/mapping/types/shape.asciidoc index a2236ffc8b38f..0251c11e0d3d5 100644 --- a/docs/reference/mapping/types/shape.asciidoc +++ b/docs/reference/mapping/types/shape.asciidoc @@ -18,7 +18,7 @@ You can query documents using this type using [discrete] ==== Mapping Options -Like the <> field type, the `shape` field mapping maps +Like the <> field type, the `shape` field mapping maps http://geojson.org[GeoJSON] or https://docs.opengeospatial.org/is/12-063r5/12-063r5.html[Well-Known Text] (WKT) geometry objects to the shape type. To enable it, users must explicitly map fields to the shape type. @@ -34,8 +34,8 @@ different ways. 1. Right-hand rule: `right`, `ccw`, `counterclockwise`, 2. Left-hand rule: `left`, `cw`, `clockwise`. The default orientation (`counterclockwise`) complies with the OGC standard which defines outer ring vertices in counterclockwise order with inner ring(s) vertices (holes) -in clockwise order. Setting this parameter in the geo_shape mapping explicitly -sets vertex order for the coordinate list of a geo_shape field but can be +in clockwise order. Setting this parameter in the `geo_shape` mapping explicitly +sets vertex order for the coordinate list of a `geo_shape` field but can be overridden in each individual GeoJSON or WKT document. | `ccw` @@ -46,7 +46,7 @@ entire document. |`ignore_z_value` |If `true` (default) three dimension points will be accepted (stored in source) but only latitude and longitude values will be indexed; the third dimension is ignored. If `false`, -geo-points containing any more than latitude and longitude (two dimensions) values throw an exception +geopoints containing any more than latitude and longitude (two dimensions) values throw an exception and reject the whole document. | `true` @@ -279,7 +279,7 @@ POST /example/_doc [[multipoint]] ===== http://geojson.org/geojson-spec.html#id5[MultiPoint] -The following is an example of a list of geojson points: +The following is an example of a list of GeoJSON points: [source,console] -------------------------------------------------- @@ -308,7 +308,7 @@ POST /example/_doc [[multilinestring]] ===== http://geojson.org/geojson-spec.html#id6[MultiLineString] -The following is an example of a list of geojson linestrings: +The following is an example of a list of GeoJSON linestrings: [source,console] -------------------------------------------------- @@ -339,7 +339,7 @@ POST /example/_doc [[multipolygon]] ===== http://geojson.org/geojson-spec.html#id7[MultiPolygon] -The following is an example of a list of geojson polygons (second polygon contains a hole): +The following is an example of a list of GeoJSON polygons (second polygon contains a hole): [source,console] -------------------------------------------------- @@ -370,7 +370,7 @@ POST /example/_doc [[geometry_collection]] ===== http://geojson.org/geojson-spec.html#geometrycollection[Geometry Collection] -The following is an example of a collection of geojson geometry objects: +The following is an example of a collection of GeoJSON geometry objects: [source,console] -------------------------------------------------- diff --git a/docs/reference/ml/anomaly-detection/functions/ml-geo-functions.asciidoc b/docs/reference/ml/anomaly-detection/functions/ml-geo-functions.asciidoc index 68ab3261fc953..fdf5353a77a7f 100644 --- a/docs/reference/ml/anomaly-detection/functions/ml-geo-functions.asciidoc +++ b/docs/reference/ml/anomaly-detection/functions/ml-geo-functions.asciidoc @@ -71,7 +71,7 @@ For example, JSON data might contain the following transaction coordinates: // NOTCONSOLE In {es}, location data is likely to be stored in `geo_point` fields. For more -information, see {ref}/geo-point.html[Geo-point data type]. This data type is +information, see {ref}/geo-point.html[`geo_point` data type]. This data type is supported natively in {ml-features}. Specifically, {dfeed} when pulling data from a `geo_point` field, will transform the data into the appropriate `lat,lon` string format before sending to the {anomaly-job}. diff --git a/docs/reference/ml/anomaly-detection/ml-configuring-transform.asciidoc b/docs/reference/ml/anomaly-detection/ml-configuring-transform.asciidoc index 9808b98cf1d16..9d02c3d011eac 100644 --- a/docs/reference/ml/anomaly-detection/ml-configuring-transform.asciidoc +++ b/docs/reference/ml/anomaly-detection/ml-configuring-transform.asciidoc @@ -421,7 +421,7 @@ The preview {dfeed} API returns the following results, which show that [[ml-configuring-transform8]] -.Example 8: Transforming geo_point data +.Example 8: Transforming geopoint data [source,console] -------------------------------------------------- diff --git a/docs/reference/query-dsl/function-score-query.asciidoc b/docs/reference/query-dsl/function-score-query.asciidoc index e377bb74b0149..5d898f6925aa6 100644 --- a/docs/reference/query-dsl/function-score-query.asciidoc +++ b/docs/reference/query-dsl/function-score-query.asciidoc @@ -368,7 +368,7 @@ decay function is specified as -------------------------------------------------- // NOTCONSOLE <1> The `DECAY_FUNCTION` should be one of `linear`, `exp`, or `gauss`. -<2> The specified field must be a numeric, date, or geo-point field. +<2> The specified field must be a numeric, date, or geopoint field. In the above example, the field is a <> and origin can be provided in geo format. `scale` and `offset` must be given with a unit in @@ -656,7 +656,7 @@ image::https://f.cloud.github.com/assets/4320215/768165/19d8b1aa-e899-11e2-91bc- ==== Supported fields for decay functions -Only numeric, date, and geo-point fields are supported. +Only numeric, date, and geopoint fields are supported. ==== What if a field is missing? diff --git a/docs/reference/query-dsl/geo-bounding-box-query.asciidoc b/docs/reference/query-dsl/geo-bounding-box-query.asciidoc index 1134639c8597c..77a3f10bbfabe 100644 --- a/docs/reference/query-dsl/geo-bounding-box-query.asciidoc +++ b/docs/reference/query-dsl/geo-bounding-box-query.asciidoc @@ -178,7 +178,7 @@ query. [discrete] ==== Accepted Formats -In much the same way the geo_point type can accept different +In much the same way the `geo_point` type can accept different representations of the geo point, the filter can accept it as well: [discrete] diff --git a/docs/reference/query-dsl/geo-polygon-query.asciidoc b/docs/reference/query-dsl/geo-polygon-query.asciidoc index dbe9adb0e2026..723e91e3bc6fb 100644 --- a/docs/reference/query-dsl/geo-polygon-query.asciidoc +++ b/docs/reference/query-dsl/geo-polygon-query.asciidoc @@ -145,7 +145,7 @@ GET /_search // TEST[warning:Deprecated field [geo_polygon] used, replaced by [[geo_shape] query where polygons are defined in geojson or wkt]] [discrete] -==== geo_point Type +==== `geo_point` type The query *requires* the <> type to be set on the relevant field. diff --git a/docs/reference/query-dsl/geo-queries.asciidoc b/docs/reference/query-dsl/geo-queries.asciidoc index b4eb86763e702..363c0ef8a0fad 100644 --- a/docs/reference/query-dsl/geo-queries.asciidoc +++ b/docs/reference/query-dsl/geo-queries.asciidoc @@ -9,20 +9,19 @@ lines, circles, polygons, multi-polygons, etc. The queries in this group are: <> query:: -Finds documents with geo-points that fall into the specified rectangle. +Finds documents with geopoints that fall into the specified rectangle. <> query:: -Finds documents with geo-points within the specified distance of a central point. +Finds documents with geopoints within the specified distance of a central point. <> query:: -Find documents with geo-points within the specified polygon. +Find documents with geopoints within the specified polygon. <> query:: Finds documents with: -* `geo-shapes` which either intersect, are contained by, or do not intersect -with the specified geo-shape -* `geo-points` which intersect the specified -geo-shape +* Geoshapes which either intersect, are contained by, or do not intersect +with the specified geoshape +* Geopoints which intersect the specified geoshape include::geo-bounding-box-query.asciidoc[] diff --git a/docs/reference/query-dsl/geo-shape-query.asciidoc b/docs/reference/query-dsl/geo-shape-query.asciidoc index c8806187fcb8e..5e35aa753f733 100644 --- a/docs/reference/query-dsl/geo-shape-query.asciidoc +++ b/docs/reference/query-dsl/geo-shape-query.asciidoc @@ -1,13 +1,13 @@ [[query-dsl-geo-shape-query]] -=== Geo-shape query +=== Geoshape query ++++ -Geo-shape +Geoshape ++++ Filter documents indexed using the `geo_shape` or `geo_point` type. -Requires the <> or the -<>. +Requires the <> or the +<>. The `geo_shape` query uses the same grid square representation as the `geo_shape` mapping to find documents that have a shape that intersects diff --git a/docs/reference/query-dsl/special-queries.asciidoc b/docs/reference/query-dsl/special-queries.asciidoc index cad9b28cbfdbc..ca3afd94092d7 100644 --- a/docs/reference/query-dsl/special-queries.asciidoc +++ b/docs/reference/query-dsl/special-queries.asciidoc @@ -6,7 +6,7 @@ This group contains queries which do not fit into the other groups: <>:: A query that computes scores based on the dynamically computed distances -between the origin and documents' date, date_nanos and geo_point fields. +between the origin and documents' `date`, `date_nanos`, and `geo_point` fields. It is able to efficiently skip non-competitive hits. <>:: diff --git a/docs/reference/scripting/expression.asciidoc b/docs/reference/scripting/expression.asciidoc index 61301fa873b40..84c07ebecaf31 100644 --- a/docs/reference/scripting/expression.asciidoc +++ b/docs/reference/scripting/expression.asciidoc @@ -137,5 +137,5 @@ e.g. based on geolocation of the user. There are a few limitations relative to other script languages: -* Only numeric, boolean, date, and geo_point fields may be accessed +* Only numeric, `boolean`, `date`, and `geo_point` fields may be accessed * Stored fields are not available