|
| 1 | +[[point]] |
| 2 | +[role="xpack"] |
| 3 | +[testenv="basic"] |
| 4 | +=== Point datatype |
| 5 | +++++ |
| 6 | +<titleabbrev>Point</titleabbrev> |
| 7 | +++++ |
| 8 | + |
| 9 | +The `point` datatype facilitates the indexing of and searching |
| 10 | +arbitrary `x, y` pairs that fall in a 2-dimensional planar |
| 11 | +coordinate system. |
| 12 | + |
| 13 | +You can query documents using this type using |
| 14 | +<<query-dsl-shape-query,shape Query>>. |
| 15 | + |
| 16 | +There are four ways that a point may be specified, as demonstrated below: |
| 17 | + |
| 18 | +[source,console] |
| 19 | +-------------------------------------------------- |
| 20 | +PUT my_index |
| 21 | +{ |
| 22 | + "mappings": { |
| 23 | + "properties": { |
| 24 | + "location": { |
| 25 | + "type": "point" |
| 26 | + } |
| 27 | + } |
| 28 | + } |
| 29 | +} |
| 30 | +
|
| 31 | +PUT my_index/_doc/1 |
| 32 | +{ |
| 33 | + "text": "Point as an object", |
| 34 | + "location": { <1> |
| 35 | + "x": 41.12, |
| 36 | + "y": -71.34 |
| 37 | + } |
| 38 | +} |
| 39 | +
|
| 40 | +PUT my_index/_doc/2 |
| 41 | +{ |
| 42 | + "text": "Point as a string", |
| 43 | + "location": "41.12,-71.34" <2> |
| 44 | +} |
| 45 | +
|
| 46 | +
|
| 47 | +PUT my_index/_doc/4 |
| 48 | +{ |
| 49 | + "text": "Point as an array", |
| 50 | + "location": [41.12, -71.34] <3> |
| 51 | +} |
| 52 | +
|
| 53 | +PUT my_index/_doc/5 |
| 54 | +{ |
| 55 | + "text": "Point as a WKT POINT primitive", |
| 56 | + "location" : "POINT (41.12 -71.34)" <4> |
| 57 | +} |
| 58 | +
|
| 59 | +-------------------------------------------------- |
| 60 | + |
| 61 | +<1> Point expressed as an object, with `x` and `y` keys. |
| 62 | +<2> Point expressed as a string with the format: `"x,y"`. |
| 63 | +<4> Point expressed as an array with the format: [ `x`, `y`] |
| 64 | +<5> Point expressed as a http://docs.opengeospatial.org/is/12-063r5/12-063r5.html[Well-Known Text] |
| 65 | +POINT with the format: `"POINT(x y)"` |
| 66 | + |
| 67 | +The coordinates provided to the indexer are single precision floating point values so |
| 68 | +the field guarantees the same accuracy provided by the java virtual machine (typically |
| 69 | +`1E-38`). |
| 70 | + |
| 71 | +[[geo-point-params]] |
| 72 | +==== Parameters for `geo_point` fields |
| 73 | + |
| 74 | +The following parameters are accepted by `point` fields: |
| 75 | + |
| 76 | +[horizontal] |
| 77 | + |
| 78 | +<<ignore-malformed,`ignore_malformed`>>:: |
| 79 | + |
| 80 | + If `true`, malformed points are ignored. If `false` (default), |
| 81 | + malformed points throw an exception and reject the whole document. |
| 82 | + |
| 83 | +`ignore_z_value`:: |
| 84 | + |
| 85 | + If `true` (default) three dimension points will be accepted (stored in source) |
| 86 | + but only x and y values will be indexed; the third dimension is |
| 87 | + ignored. If `false`, points containing any more than x and y |
| 88 | + (two dimensions) values throw an exception and reject the whole document. |
| 89 | + |
| 90 | +<<null-value,`null_value`>>:: |
| 91 | + |
| 92 | + Accepts an point value which is substituted for any explicit `null` values. |
| 93 | + Defaults to `null`, which means the field is treated as missing. |
| 94 | + |
| 95 | +==== Sorting and Retrieving index Shapes |
| 96 | + |
| 97 | +It is currently not possible to sort shapes or retrieve their fields |
| 98 | +directly. The `point` value is only retrievable through the `_source` |
| 99 | +field. |
0 commit comments