ESQL: Documentation for support for geo_point and point #103207
Conversation
craigtaverner
added
>docs
|
Documentation preview: |
elasticsearchmachine
added
Team:Docs
|
Pinging @elastic/es-analytics-geo (Team:Analytics) |
|
Pinging @elastic/es-docs (Team:Docs) |
|
Pinging @elastic/es-ql (Team:QL) |
|
Pinging @elastic/elasticsearch-esql (:Query Languages/ES|QL) |
craigtaverner
changed the title
| |=== | ||
|
|
||
| If the input parameter is of numeric type `long`, its value will be interpreted as | ||
| the Lucene encoded value, with `x` encoded in the high four bytes, |
There was a problem hiding this comment.
We have to make sure we want to expose this. And, presuming we do, probably good to link to something here.
There was a problem hiding this comment.
This capability is very useful internally and for testing, but it is not clear to me that it does need to be exposed. It will become even more useful when we have both source and doc-values versions of the block data, each with specific purposes. For now, we could either remove it from the docs, or leave it there for now while the system is still in tech-preview, or keep it if in the end we want to expose it permanently.
There was a problem hiding this comment.
I think this is an implementation detail and it does not need to be exposed?
There was a problem hiding this comment.
I don't think we should accept longs anyway
| row long = 5009771769843126025 | ||
| | eval pt = to_cartesianpoint(long); | ||
| | eval pt = to_cartesianpoint(long) |
There was a problem hiding this comment.
It'd be so nice if we could hex encode here. Oh well.
There was a problem hiding this comment.
A hex literal? That sounds nice! It is a language feature though, so not in scope for this PR.
| include::{esql-specs}/spatial.csv-spec[tag=to_geopoint-str-result] | ||
| |=== | ||
|
|
||
| If the input parameter is of numeric type `long`, its value will be interpreted as |
There was a problem hiding this comment.
Same here, we should not accept longs
| Boolean *true* will be converted to long *1*, *false* to *0*. | ||
| ==== Spatial points | ||
|
|
||
| If the input parameter is a spatial point (`geo_point` or `point`), |
There was a problem hiding this comment.
This again an implementation detail? do we need to expose it?
There was a problem hiding this comment.
Reading the docs makes me uncomfortable as we are leaking too many implementation details to the user:
-
Our internal long representations of points should no be leaked to the user. This gives as the change to change it if we want to do so.
-
Spatial point is not a elasticsearch concept but something introduce to handle internally geo and cartesian points. I don't think it should be leaked to the user API.
Would it be possible to hide those things to the user?
|
I think it is wrong that we can apply |
* Start working on geo_point and point docs for ESQL * Added to_cartesianpoint and includes * Sub-headings for easier reading * Improve sub-headings * Hide to_long and support for longs in to_geopoint and to_cartesianpoint
* ESQL: Documentation for support for geo_point and point (#103207) * Start working on geo_point and point docs for ESQL * Added to_cartesianpoint and includes * Sub-headings for easier reading * Improve sub-headings * Hide to_long and support for longs in to_geopoint and to_cartesianpoint * Fix missing links in geo_point docs for ESQL
In #102177 we added support for
geo_pointand cartesianpointto ES|QL. This PR adds the docs for that.