Importación de datos geoespaciales usando Kibana

Los datos que usamos para los ejemplos del blog anterior se basaban en datos que usamos internamente para pruebas de integración. Para tu comodidad, lo incluimos aquí en forma de algunos archivos CSV que se pueden importar fácilmente usando Kibana. Los datos son una mezcla de aeropuertos, ciudades y límites urbanos. Puedes descargar los datos desde:

• airports.csv

  • Este contiene una fusión de tres conjuntos de datos:

    • Aeropuertos (nombres, ubicaciones y datos relacionados) de Natural Earth

    • Ubicaciones de las ciudades según SimpleMaps

    • Elevaciones de aeropuertos según la base de datos global de aeropuertos

• airport_city_boundaries.csv

  • Esto contiene una fusión de nombres de aeropuertos y ciudades mencionados anteriormente con una fuente nueva:

    • Límites de la ciudad según OpenStreetMap

Como puedes imaginar, dedicamos un tiempo a combinar estas fuentes de datos en los dos archivos anteriores, con el objetivo de poder probar las características geoespaciales de ES|QL. Puede que esto no sea exactamente lo mismo que tus necesidades específicas de datos, pero espero que esto te dé una idea de lo que es posible. En individuo, queremos demostrar algunas cosas interesantes:

• Importación de datos con campos geoespaciales junto con otros datos indexables

• Importar datos geo_point y geo_shape y usarlos juntos en consultas

• Importación de datos en dos índices que pueden unir mediante una relación espacial

• Crear una canalización de ingestión para facilitar futuras importaciones (más allá de Kibana)

• Algunos ejemplos de procesadores de ingest, como csv, convert y split

Aunque en este blog hablaremos sobre cómo trabajar con datos CSV, es importante entender que existen varias formas de agregar datos geográficos usando Kibana. Dentro de la aplicación de mapas puedes subir datos delimitados como archivos de forma CSV, GeoJSON y ESRI, y también puedes dibujar formas directamente en el mapa. Para este blog nos centraremos en importar archivos CSV desde la página principal de Kibana.

Importación de aeropuertos

El primer expediente , airports.csv, tiene algunas rarezas interesantes con las que tenemos que lidiar. En primer lugar, las columnas tienen espacios en blanco adicionales que las separan, algo que no es típico de los archivos CSV. En segundo lugar, el campo type es un campo de varios valores, que necesitamos separar en cuerpos separados. Por último, algunos campos no son cadenas y necesitan convertir al tipo correcto. Todo esto se puede hacer empleando la instalación de importación CSV de Kibana.

Empieza en la página principal de Kibana. Hay una sección llamada "Empezar agregando integraciones", que tiene un enlace llamado "Subir un archivo":

Haz clic en este enlace y serás llevado a la página "Subir archivo". Aquí puedes arrastrar y soltar el archivo airports.csv , y Kibana analizará el archivo y te mostrará una vista previa de los datos. Debería detectar automáticamente el delimitador como una coma, y la primera fila como la fila de cabecera. Sin embargo, probablemente no recortó el espacio en blanco extra entre las columnas, ni determinó los tipos de campos, suponiendo que todos los campos sean text o keyword. Tenemos que arreglar esto.

Haz clic Override settings y marca la casilla para Should trim fieldsy Apply para cerrar la configuración. Ahora necesitamos fijar los tipos de los campos. Esto está disponible en la página siguiente, así que adelante y haz clic Import.

Primero elige un nombre de índice y luego selecciona Advanced para acceder a la página de mapeo de campos e ingesta del procesador.

Aquí necesitamos hacer cambios tanto en los mapeos de campos del índice como en la canalización de ingesta para importar los datos. En primer lugar, aunque Kibana probablemente detectó automáticamente el campo scalerank como long, percibió erróneamente los campos location y city_location como keyword. Edítalos para que geo_point, y acabes con mapeos que se ven algo así como:

Aquí tienes cierta flexibilidad, pero ten en cuenta que el tipo que elijas afectará a cómo se indexa el campo y qué tipo de consultas son posibles. Por ejemplo, si dejas location tal keyword no puedes realizar ninguna consulta de búsqueda geoespacial sobre él. De manera similar, si dejas elevation tal text no puedes realizar consultas numéricas por rango.

Ahora es el momento de arreglar la pipeline de ingest. Si Kibana detectó automáticamente scalerank como long anterior, también agregó un procesador para convertir el campo en un long. Necesitamos agregar un procesador similar para el campo elevation , esta vez convirtiéndolo a double. Edita la canalización para cerciorarte de que tienes esta conversión en marcha. Antes de almacenar esto, queremos una conversión más, para dividir el campo de type en varios campos. Agregar un procesador split a la canalización, con la siguiente configuración:

La pipeline final de ingesta debería ser la siguiente:

Ten en cuenta que no agregamos un procesador de conversión para los campos location y city_location . Esto se debe a que el tipo geo_point en el mapeo de campos ya entiende el formato WKT de los datos en estos campos. El tipo geo_point puede comprender una variedad de formatos, incluyendo WKT, GeoJSON y más. Si tuviéramos, por ejemplo, dos columnas en el archivo CSV para latitude y longitude, tuvimos que agregar un procesador script o un set para combinarlas en un solo campo geo_point (por ejemplo, "set": {"field": "location", "value": "{{lat}},{{lon}}"}).

Ahora estamos listos para importar el archivo. Haz clic Import y los datos se importarán al índice con los mapeos y la pipeline de ingesta que acabamos de definir. Si hay errores al absorber los datos, Kibana los reportará aquí, así que puedes editar los datos fuente o la pipeline de ingesta y volver a intentarlo.

Fíjate que se creó una nueva canalización de ingestión. Esto puede comprobar yendo a la sección Stack Management de Kibana y seleccionando Ingest pipelines. Aquí puedes ver la canalización que acabamos de crear y editarla si es necesario. De hecho, la sección Ingest pipelines puede usar para crear y probar canalizaciones de ingest, una función muy útil si planeas hacer ingestas aún más complejas.

Si quieres explorar estos datos inmediatamente, baja a las secciones posteriores, pero si también quieres importar los límites de la ciudad, sigue leyendo.

Importación de los límites de la ciudad

El archivo de límites de la ciudad disponible en airport_city_boundaries.csv es un poco más sencillo de importar que el ejemplo anterior. Contiene un campo city_boundary que es una representación WKT del límite de la ciudad como POLYGONy un campo city_location que es una representación geo_point de la ubicación de la ciudad. Podemos importar estos datos de forma similar a los datos del aeropuerto, pero con algunas diferencias:

• Tuvimos que seleccionar la opción de anulación Has header row ya que no se detectó automáticamente

• No fue necesario recortar campos, ya que los datos ya estaban limpios de espacio en blanco extra

• No tuvimos que editar la tubería de ingesta porque todos los tipos eran de cadena o de tipos espaciales

• Sin embargo, tuvimos que editar los mapeos de campos para establecer el campo city_boundary a geo_shape y el campo city_location a geo_point

Nuestros mapeos finales de campo eran los siguientes:

Como con la importación airports.csv anterior, simplemente haz clic Import para importar los datos al índice. Los datos se importarán junto con los mapeos que editamos y la pipeline de ingesta que Kibana definió.

Explorando datos geoespaciales con herramientas de desarrollo

En Kibana es habitual explorar los datos indexados con "Descubrir". Sin embargo, si tu intención es crear tu propia app usando ES|Consultas QL, podría ser más interesante intentar acceder a la API en bruto de Elasticsearch. Kibana tiene una consola práctica para experimentar escribiendo consultas. Esto se llama la consola Dev Tools y se puede encontrar en la barra lateral de Kibana. Esta consola se comunica directamente con el clúster Elasticsearch y puede usar para ejecutar consultas, crear índices y más.

Prueba lo siguiente:

Esto debería proporcionar los siguientes resultados:

distancia

Abbrev

nombre

Ubicación

país

ciudad

elevación

273418.05776847183

JAMÓN

Hamburgo

POINT (10.005647830925 53.6320011640866)

Alemania

Norderstedt

17.0

337534.653466062

TXL

Berlin-Tegel Int'l

POINT (13.2903090925074 52.5544287044101)

Alemania

Hohen Neuendorf

38.0

483713.15032266214

OSL

Oslo Gardermoen

POINT (11.0991032762581 60.1935783171386)

Noruega

Oslo

208.0

522538.03148094116

BMA

Bromma

POINT (17.9456175406145 59.3555902065112)

Suecia

Estocolmo

15.0

522538.03148094116

ARN

Arlanda

POINT (17.9307299016916 59.6511203397372)

Suecia

Estocolmo

38.0

624274.8274399083

DUS

Düsseldorf Int'l

POINT (6.76494446612174 51.2781820420774)

Alemania

Düsseldorf

45.0

633388.6966435644

PRG

Ruzyn

POINT (14.2674849854076 50.1076511703671)

Chequia

Praga

381.0

635911.1873311149

AMS

Schiphol

PUNTO (4.76437693232812 52.3089323889822)

Países Bajos

Hoofddorp

-3.0

670864.137958866

FRA

Nt'l de Frankfurt

POINT (8.57182286907608 50.0506770895207)

Alemania

Fráncfort

111.0

683239.2529970079

WAW

Okecie Int'l

POINT (20.9727263383587 52.171026749259)

Polonia

Piaseczno

111.0

Visualización de datos geoespaciales con Kibana Maps

Kibana Maps es una herramienta poderosa para visualizar datos geoespaciales. Puede emplear para crear mapas con múltiples capas, cada capa representando un conjunto de datos diferente. Los datos pueden filtrar, agregar y estilizar de diversas maneras. En esta sección, te mostraremos cómo crear un mapa en Kibana Maps usando los datos que importamos en la sección anterior.

En el menú Kibana, navega hasta Analytics->Maps para abrir una nueva vista del mapa. Haz clic en Add Layer y selecciona Documents, eligiendo el airports de vista de datos y luego editando el estilo de capa para colorear los marcadores usando el campo elevation , para que podamos ver fácilmente la altura de cada aeropuerto.

Haz clic en 'Conservar cambios' para almacenar el mapa:

Ahora agrega una segunda capa, esta vez seleccionando la vista de datos airport_city_boundaries . Esta vez, usaremos el campo city_boundary para estilizar la capa y pondremos el color de relleno en azul claro. Esto mostrará los límites de la ciudad en el mapa. Cerciórate de reordenar las capas para que los marcadores del aeropuerto estén encima.

Unirías espaciales

ES|QL no soporta comandos JOIN, pero puedes lograr un caso especial de unión usando el comando ENRICH. Este comando funciona de forma similar a una 'unión por la izquierda' en SQL, permitiéndote enriquecer resultados de un índice con datos de otro índice basar en una relación espacial entre los dos conjuntos de datos.

Por ejemplo, enriquezcamos los resultados de una tabla de aeropuertos con información adicional sobre la ciudad a la que sirven encontrando el límite de la ciudad que contiene la ubicación del aeropuerto, y luego realicemos algunas estadísticas sobre los resultados:

Si ejecutas esta consulta sin preparar primero el índice de enriquecimiento, recibirás un mensaje de error como:

Esto se debe a que, como mencionamos antes, ES|QL no soporta comandos de JOIN verdadero. Una razón importante para ello es que Elasticsearch es un sistema distribuido, y las uniones son operaciones costosas que pueden ser difíciles de escalar. Sin embargo, el comando ENRICH puede ser bastante eficiente, ya que emplea índices de enriquecimiento especialmente preparados que se duplican a lo largo del clúster, permitiendo realizar uniones locales en cada nodo.

Para entender mejor esto, centrémonos en el comando ENRICH de la consulta anterior:

Este comando instruye a Elasticsearch para enriquecer los resultados recuperados del índice de airports y realizar una unión intersects entre el campo city_location del índice original y el campo city_boundary del índice de airport_city_boundaries , que usamos en algunos ejemplos anteriores. Pero parte de esta información no es claramente visible en esta consulta. Lo que sí vemos es el nombre de una política de enriquecimiento city_boundaries, y la información que falta está encapsulada dentro de esa definición de política.

Aquí podemos ver que realizará una consulta geo_match (intersects es el valor predeterminado), el campo a emparejar es city_boundary, y los enrich_fields son los campos que queremos agregar al documento original. Uno de esos campos, el region , se usó como clave de agrupación para el comando STATS , algo que no podríamos hacer sin esta capacidad de 'unión izquierda'. Para más información sobre las pólizas de enriquecimiento, consulte la documentación de enriquecimiento.

Los índices y políticas de enriquecimiento en Elasticsearch fueron diseñados originalmente para enriquecer datos en el momento del índice, empleando datos de otro índice de enriquecimiento preparado. En ES|QL, sin embargo, el comando ENRICH funciona en el momento de la consulta y no requiere el uso de pipelines de ingest. Esto lo hace efectivamente bastante similar a un LEFT JOINSQL, excepto que no puedes unir dos índices cualquiera, solo un índice normal a la izquierda con un índice enrich especialmente preparado a la derecha.

En cualquier caso, ya sea para canalizaciones de ingesta o para su uso en ES|QL, es necesario realizar algunos pasos preparatorios para establecer el índice de enriquecimiento y la póliza. Ya importamos el índice de airport_city_boundaries arriba, pero este no se puede usar directamente como índice de enriquecimiento en el comando ENRICH . Primero necesitamos realizar dos pasos:

• Crea la política de enriquecimiento descrita anteriormente para definir el índice fuente, el campo en el índice fuente para coincidir y los campos que devolver una vez emparejados.

• Ejecuta esta política para crear el índice enriquecido. Esto construirá un índice interno especial, leyendo el índice original en una estructura de datos más eficiente que se copia a través del clúster.

La política de enriquecimiento puede crear usando el siguiente comando:

Y la política puede ejecutar usando el siguiente comando:

Ten en cuenta que si alguna vez cambias el contenido del índice de airport_city_boundaries , tendrás que volver a ejecutar esta política para ver los cambios reflejados en el índice de enriquecimiento. Ahora vamos a ejecutar el ES| originalConsulta QL de nuevo:

Esto devuelve las 5 regiones con más aeropuertos, junto con el centroide de todos los aeropuertos que tienen regiones coincidentes, y el rango en longitud de la representación WKT de los límites de la ciudad dentro de esas regiones:

centroide

Recuento

región

POINT (-12.139086859300733 31.024386116624648)

126

nulo

POINT (-83.10398317873478 42.300230911932886)

3

Detroit

POINT (39.74537850357592 47.21613017376512)

3

городской округ Батайск

POINT (-156.80986787192523 20.476673701778054)

3

Hawai

POINT (-73.94515332765877 40.70366442203522)

3

Ciudad de Nueva York

POINT (-83.10398317873478 42.300230911932886)

3

Detroit

POINT (-76.66873019188643 24.306286952923983)

2

Nueva Providencia

POINT (-3.0252167768776417 51.39245774131268)

2

Cardiff

POINT (-115.40993484668434 32.73126147687435)

2

Municipio de Mexicali

POINT (41.790108773857355 50.302146775648)

2

Центральный район

POINT (-73.88902732171118 45.57078813901171)

2

Montréal

También puede que notes que la región más común era null. ¿Qué podría implicar esto? Recuerda que comparé este comando con un 'left join' en SQL, lo que significa que si no se encuentra ningún límite de ciudad coincidente para un aeropuerto, el aeropuerto sigue devolver pero con valores null para los campos del índice de airport_city_boundaries . Resulta que hubo 125 aeropuertos que no encontraron city_boundarycoincidentes, y un aeropuerto con un coincidente donde el campo de region estaba null. Esto llevó a un recuento de 126 aeropuertos sin region en los resultados. Si tu caso de uso requiere que todos los aeropuertos puedan coincidir con un límite de ciudad, eso requeriría buscar datos adicionales para cubrir los huecos. Sería necesario determinar dos cosas:

• qué registros en el índice de airport_city_boundaries no tienen campos city_boundary

• qué registros en el índice de airports no coinciden usando el comando ENRICH (es decir, no intersectar)

Usando ES|QL para datos geoespaciales en Kibana Maps

Kibana agregó soporte para Spatial ES|QL en la aplicación de Mapas. Esto significa que ahora puedes usar ES|QL para buscar datos geoespaciales en Elasticsearch y visualizar los resultados en un mapa.

Hay una nueva opción de capa en el menú de agregar capas, llamada "ES|QL". Como todas las características geoespaciales descritas hasta ahora, esto está en "vista previa técnica". Seleccionar esta opción te permite agregar una capa al mapa basada en los resultados de un ES|Consulta QL. Por ejemplo, podrías agregar una capa al mapa que muestre todos los aeropuertos del mundo.

O podrías agregar una capa que muestre los polígonos del índice de airport_city_boundaries , o mejor aún, ¿qué tal esa compleja consulta de ENRICH arriba que genera estadísticas sobre cuántos aeropuertos hay en cada región?

¿Qué sigue ahora?

El anterior blog de búsqueda geoespacial se centraba en el uso de funciones como ST_INTERSECTS para realizar búsquedas, disponibles en Elasticsearch desde la versión 8.14. Y este blog te muestra cómo importar los datos que usamos para esas búsquedas. Sin embargo, Elasticsearch 8.15 venía con una función especialmente interesante: ST_DISTANCE que puede usar para realizar búsquedas espaciales eficientes, ¡y este será el tema del próximo blog!

Elasticsearch 8.12 y 8.13 llevaron soporte básico para tipos geoespaciales a ES|QL. Esto se mejoró significativamente con la incorporación de capacidades de búsqueda geoespacial en la versión 8.14. Más importante aún, este soporte fue diseñado para ajustar estrechamente al estándar Simple Feature Access del Open Geospatial Consortium (OGC) empleado por otras bases de datos espaciales como PostGIS, facilitando mucho su uso para expertos en SIG familiarizados con estos estándares.

En este blog, te mostraremos cómo usar ES|QL para realizar búsquedas geoespaciales y cómo se compara con los equivalentes SQL y Query DSL. También te mostraremos cómo usar ES|QL para realizar uniones espaciales y cómo visualizar los resultados en Kibana Maps. Ten en cuenta que todas las funciones descritas aquí están en "vista previa técnica", y nos encantaría conocer vuestros comentarios sobre cómo podemos mejorarlas.

Búsqueda de datos geoespaciales

Empecemos con una consulta de ejemplo:

Esto realiza una búsqueda de cualquier polígono de límite de ciudad que intersecte con un polígono rectangular alrededor del Aeropuerto Internacional Sanya Phoenix (SYX).

En un conjunto de datos de ejemplo de aeropuertos, ciudades y límites urbanos, esta búsqueda encuentra el polígono que se cruza y devuelve los campos deseados del documento correspondiente:

Abbrev

aeropuerto

región

ciudad

city_location

SYX

Sanya Phoenix Internacional

天涯区

Sanya

POINT(109.5036 18.2533)

¡Eso fue fácil! Ahora compáralo con el tradicional DSL de Elasticsearch Query para la misma consulta:

Ambas consultas son bastante claras en su intención, pero el ES|La consulta QL se parece mucho a SQL. La misma consulta en PostGIS es la siguiente:

Mira atrás en el ES|Ejemplo de QL. Muy parecido, ¿verdad?

Comprobamos que los usuarios actuales de la API de Elasticsearch encuentran ES|QL mucho más fácil de usar. Ahora esperamos que los usuarios existentes de SQL, especialmente los de SQL Espacial, descubran que ES|QL se siente muy familiar con lo que están acostumbrados a ver.

¿Por qué no SQL?

¿Y qué pasa con Elasticsearch SQL? Lleva un tiempo existiendo y tiene algunas características geoespaciales. Sin embargo, Elasticsearch SQL se escribía como un envoltorio sobre la API original de Consultas, lo que significaba que solo se soportaban consultas que podían transpilarse a la API original. ES|QL no tiene esta limitación. Ser una pila completamente nueva permite muchas optimizaciones que no eran posibles en SQL. Nuestros benchmarks muestran ES|QL suele ser muy rápido que la API de Consultas, ¡especialmente con agregaciones!

Diferencias con SQL

Claramente, por el ejemplo anterior, ES|QL es algo similar a SQL, pero hay algunas diferencias importantes. Por ejemplo, ES|QL es un lenguaje de consulta por pipes, que comienza con un comando fuente como FROM y luego encadena todos los comandos posteriores junto con el pipe | carácter. Esto facilita mucho entender cómo cada comando recibe una tabla de datos y realiza alguna acción sobre esa tabla, como filtrar con WHERE, agregar columnas con EVAL, o realizar agregaciones con STATS. En lugar de comenzar con SELECT para definir las columnas de salida finales, puede haber uno o más comandos KEEP , siendo el último el que especifica los resultados finales. Esta estructura simplifica el razonamiento sobre la consulta.

Centrándonos en el comando WHERE del ejemplo anterior, podemos ver que se parece bastante al ejemplo de PostGIS:

ES|QL

PostGIS

Aparte de la diferencia en los caracteres de comillas de cadena, la mayor diferencia está en cómo tipificamos la cadena a un tipo espacial. En PostGIS, usamos el sufijo ::geometry , mientras que en ES|QL, usamos el sufijo ::geo_shape . Esto se debe a que ES|QL se ejecuta dentro de Elasticsearch, y el operador de typecasting :: puede usar para convertir una cadena a cualquiera de los ES| soportadosQL tipia, en este caso, un geo_shape. Además, los tipos geo_shape y geo_point en Elasticsearch implican el sistema de coordenadas espaciales conocido como WGS84, más comúnmente conocido con el número SRID 4326. En PostGIS, esto debe ser explícito, de ahí el uso del prefijo SRID=4326; a la cadena WKT. Si se elimina ese prefijo, el SRID se pondrá en 0, que es más parecido a los tipos de Elasticsearch cartesian_point y cartesian_shape, que no están vinculados a ningún sistema de coordenadas específico.

Ambos ES|QL y PostGIS también proporcionan sintaxis de funciones de conversión de tipos:

ES|QL

PostGIS

Funciones OGC

Elasticsearch 8.14 introduce las siguientes cuatro funciones de búsqueda espacial OGC:

ES|QL

PostGIS

Descripción

ST_INTERSECTS

ST_Intersects

Devuelve verdadero si dos geometrías se cruzan, y falso en caso contrario.

ST_DISJOINT

ST_Disjoint

Devuelve verdadero si dos geometrías no se intersectan, y falso en caso contrario. El inverso de ST_INTERSECTS.

ST_CONTAINS

ST_Contains

Devuelve verdadero si una geometría contiene otra, y falso en caso contrario.

ST_WITHIN

ST_Within

Devuelve verdadero si una geometría está dentro de otra, y falso en caso contrario. El inverso de ST_CONTAINS.

Estas funciones se comportan de forma similar a sus contrapartes PostGIS y se emplean de la misma manera. Por ejemplo, ST_INTERSECTS devuelve verdadero si dos geometrías se intersectan y falso en caso contrario. Si sigues los enlaces de documentación de la tabla anterior, puede que notes que todos los ES|Los ejemplos de QL están dentro de una cláusula de WHERE luego de una cláusula de FROM , mientras que todos los ejemplos de PostGIS usan geometrías literales. De hecho, ambas plataformas soportan el uso de las funciones en cualquier parte de la consulta donde tengan sentido.

El primer ejemplo en la documentación de PostGIS para ST_INTERSECTS es:

El ES|El equivalente en QL de esto sería:

Fíjate en que no especificamos el SRID en el ejemplo de PostGIS. Esto se debe a que en PostGIS, al usar el tipo geometry , todos los cálculos se realizan en un sistema de coordenadas planas, por lo que si ambas geometrías tienen el mismo SRID, no importa cuál sea el SRID. En Elasticsearch, esto también es cierto para la mayoría de las funciones, sin embargo, hay excepciones donde geo_shape y geo_point emplean cálculos esféricos, como veremos en el próximo blog sobre búsqueda por distancia espacial.

ES|Versatilidad en QL

Vimos ejemplos arriba de usar funciones espaciales en cláusulas WHERE y en comandos ROW . ¿Dónde más tendrían sentido? Un lugar muy útil es en el comando EVAL . Este comando te permite evaluar una expresión y devolver el resultado. Por ejemplo, determinemos si los centroides de todos los aeropuertos agrupados por el nombre de sus países están dentro de un límite que delimita el país:

Se esperan los resultados: el centroide de los aeropuertos del Reino Unido está dentro del límite del Reino Unido, y no dentro del límite de Islandia, y viceversa:

centroide

Recuento

in_uk

in_iceland

within_uk

within_iceland

POINT (-21.946634463965893 64.13187285885215)

1

falso

true

falso

true

POINT (-2.597342072712148 54.33551226578214)

17

true

falso

true

falso

POINT (0.04453958108176276 23.74658354606057)

873

falso

falso

falso

falso

De hecho, estas funciones pueden usar en cualquier parte de la consulta donde su firma tenga sentido. Todos toman dos argumentos, que son o bien un objeto espacial literal o un campo de un tipo espacial, y todos devuelven un valor booleano. Una consideración importante es que el sistema de referencia de coordenadas (CRS) de las geometrías debe coincidir, o se devolverá un error. Esto significa que no puedes mezclar geo_shape y cartesian_shape tipos en la misma llamada de función. Sin embargo, puedes mezclar geo_point y geo_shape tipos, ya que el tipo geo_point es un caso especial del tipo geo_shape , y ambos comparten el mismo sistema de referencia de coordenadas. La documentación de cada una de las funciones definidas anteriormente lista las combinaciones de tipos soportadas.

Además, cualquiera de los dos argumentos puede ser un literal espacial o un campo, en cualquiera de los dos ordenes. Incluso puedes especificar dos campos, dos literales, un campo y un literal, o un literal y un campo. El único requisito es que los tipos sean compatibles. Por ejemplo, esta consulta compara dos campos en el mismo índice:

La consulta básicamente pregunta si la ubicación de la ciudad está dentro del límite de la ciudad, lo cual generalmente debería ser cierto, pero siempre hay excepciones:

cardinalidad

Recuento

in_city

poco

29

falso

mucho

740

true

Una pregunta mucho más interesante sería si la ubicación del aeropuerto está dentro de los límites de la ciudad a la que sirve el aeropuerto. Sin embargo, la ubicación del aeropuerto se encuentra en un índice diferente al que contiene los límites de la ciudad. Esto requiere un método para consultar y correlacionar eficazmente los datos de estos dos índices separados.

Unirías espaciales

ES|QL no soporta comandos JOIN, pero puedes lograr un caso especial de unión usando el comando ENRICH, que se comporta de forma similar a una 'unión izquierda' en SQL. Este comando funciona de forma similar a una 'unión por la izquierda' en SQL, permitiéndote enriquecer resultados de un índice con datos de otro índice basar en una relación espacial entre los dos conjuntos de datos.

Por ejemplo, enriquezcamos los resultados de una tabla de aeropuertos con información adicional sobre la ciudad a la que sirven encontrando el límite de la ciudad que contiene la ubicación del aeropuerto, y luego realicemos algunas estadísticas sobre los resultados:

Esto devuelve las 5 regiones con más aeropuertos, junto con el centroide de todos los aeropuertos que tienen regiones coincidentes, y el rango en longitud de la representación WKT de los límites de la ciudad dentro de esas regiones:

centroide

Recuento

min_wkt

max_wkt

región

PUNTO (-32.56093470960719 32.598117914802714)

90

207

207

nulo

POINT (-73.94515332765877 40.70366442203522)

9

438

438

Ciudad de Nueva York

POINT (-83.10398317873478 42.300230911932886)

9

473

473

Detroit

POINT (-156.3020245861262 20.176383580081165)

5

307

803

Hawai

POINT (-73.88902732171118 45.57078813901171)

4

837

837

Montréal

Entonces, ¿qué pasó realmente aquí? ¿Dónde ocurrió la supuesta JOIN ? El núcleo de la consulta reside en el comando ENRICH :

Este comando instruye a Elasticsearch para enriquecer los resultados recuperados del índice de airports y realizar una unión intersects entre el campo city_location del índice original y el campo city_boundary del índice de airport_city_boundaries , que usamos en algunos ejemplos anteriores. Pero parte de esta información no es claramente visible en esta consulta. Lo que sí vemos es el nombre de una política de enriquecimiento city_boundaries, y la información que falta está encapsulada dentro de esa definición de política.

Aquí podemos ver que realizará una consulta geo_match (intersects es el valor predeterminado), el campo a emparejar es city_boundary, y los enrich_fields son los campos que queremos agregar al documento original. Uno de esos campos, el region , se usó como clave de agrupación para el comando STATS , algo que no podríamos hacer sin esta capacidad de 'unión izquierda'. Para más información sobre las pólizas de enriquecimiento, consulte la documentación de enriquecimiento. Al leer esos documentos, notarás que describen el uso de los índices enrich para enriquecer datos en tiempo de indexación, configurando pipelines de ingest. Esto no es necesario para ES|QL, ya que el comando ENRICH funciona en el momento de la consulta. Basta con preparar el índice de enriquecimiento con los datos y la política de enriquecimiento necesarios, y luego usar el comando ENRICH en tu ES|Consultas QL.

También puede que notes que la región más común era null. ¿Qué podría implicar esto? Recuerda que comparé este comando con un 'left join' en SQL, lo que significa que si no se encuentra ningún límite de ciudad coincidente para un aeropuerto, el aeropuerto sigue devolver pero con valores null para los campos del índice de airport_city_boundaries . Resulta que había 89 aeropuertos que no encontraron city_boundarycoincidentes, y un aeropuerto con un region campo de null. Esto llevó a un recuento de 90 aeropuertos sin region en los resultados. Otro detalle interesante es la necesidad del comando MV_EXPAND . Esto es necesario porque el comando ENRICH puede devolver múltiples resultados por cada fila de entrada, y MV_EXPAND ayuda a separar estos resultados en varias filas, una para cada resultado. Esto también aclara por qué "Hawái" muestra resultados min_wkt y max_wkt diferentes: había varias regiones con el mismo nombre pero diferentes límites.

Kibana Maps

Kibana agregó soporte para Spatial ES|QL en la aplicación de Mapas. Esto significa que ahora puedes usar ES|QL para buscar datos geoespaciales en Elasticsearch y visualizar los resultados en un mapa.

Hay una nueva opción de capa en el menú de agregar capas, llamada "ES|QL". Como todas las características geoespaciales descritas hasta ahora, esto está en "vista previa técnica". Seleccionar esta opción te permite agregar una capa al mapa basada en los resultados de un ES|Consulta QL. Por ejemplo, podrías agregar una capa al mapa que muestre todos los aeropuertos del mundo.

O podrías agregar una capa que muestre los polígonos del índice de airport_city_boundaries , o mejor aún, ¿qué tal esa compleja consulta de ENRICH arriba que genera estadísticas sobre cuántos aeropuertos hay en cada región?

¿Qué sigue ahora?

Quizá notaste que en dos de los ejemplos anteriores incluimos otra función espacial ST_CENTROID_AGG. Esta es una función agregadora empleada en el comando STATS , y la primera de muchas funciones de análisis espacial que planeamos agregar a ES|QL. ¡Escribiremos sobre ello en el blog cuando tengamos más que mostrar!

Antes de eso, queremos contarte más sobre una función especialmente emocionante en la que trabajamos: la capacidad de realizar búsquedas espaciales, una de las funciones de búsqueda espacial más empleadas en Elasticsearch. ¿Te imaginas cómo sería la sintaxis de las búsquedas a distancia? ¿Quizá similar a una función OGC? ¡Permanece atento al próximo blog de este serial para descubrirlo!

Alerta de spoilers: Elasticsearch 8.15 acaba de ser lanzado, y la búsqueda por distancia espacial con ES|¡QL está incluido!