Distance from [lon,lat] to geo_shape

[eskibars]

Currently, we can do distance math for filter (geo_distance) and sort (_geo_distance) from a given [lon,lat] to a geo_point. We cannot do this currently for a [lon,lat] to the surface of a geo_shape object (distance "N"). There's a bit of a workaround for the geo_distance filter: you can create a circle of a specified radius M and check for an "intersects" relation. However, there are some cases where this does not work (e.g. if M > (N + [span of geo_shape]) it's now "within").

A few examples:

• A vehicle is supposed to follow an indexed LineString / MultiLineString path and we want to find when it has deviated from the path by more than 100 meters [filter]
• Find the nearest landmark (geo-shape) to my present location [sort]

[Ghost93]

Hi,
any news on this?

We also need geo_distance to support geo_shape fields.

[clintongormley]

@nknize any thoughts on this?

[nknize]

This will likely follow the Lucene 5.5 release which includes the API and performance improvements needed to make this perform at scale.

[akamanocha]

+1 for this. I guess es is now on 5.5 any plan to do this.

Or suggested architecture/ workaround please?

[imalygin]

Do you have any updates for this by any chance?

[clintongormley]

Not yet. A new geo field type is being worked on which combines geo-point and geo-shape functionality, but it is early days still

[jfitz1]

+1

[kaxil]

+1

[riconegri]

+1

[juanpujol]

👍

[akamanocha]

Anything on this?

[publicaddm]

+1

[lukas-gitl]

+1

[TomerGold1998]

+1 any update ??

[radeno]

I dont want to be troll but even javascript (i work with it) has awesome library https://github.com/Turfjs/turf but high-scalabe technology doesn't.

[mgerasimchuk]

+1

[christian-froh]

+1

[jpountz]

Some thoughts:

• sorting (or aggregating) geo shapes is going to be at least controversial due to the fact that it requires storing shapes in doc values
• filtering shapes by geo distance is going to be easy with the upcoming BKD-based shape support
• filtering or sorting points by their distance to a (query) shape would be doable efficiently I believe, eg. by splitting the query shape into multiple sub shapes and partitioning the space based on their closest sub-shape so that we wouldn't have to consider the entire shape every time.

Let's maybe split this issue for these different use-cases?

[imotov]

Depends on #32039 and #37206

[blkbltjns]

We could really use this as the new BKD index methodology does not work with intersecting circles in latest ES, and intersecting with circles by converting to polygons is wasteful and inaccurate.

[talevy]

and intersecting with circles by converting to polygons is wasteful and inaccurate.

I am not sure this issue is the right place to have this discussion. but could you explain your use-case a bit more and what type of distance queries you are interested in doing?

[blkbltjns]

and intersecting with circles by converting to polygons is wasteful and inaccurate.

I am not sure this issue is the right place to have this discussion. but could you explain your use-case a bit more and what type of distance queries you are interested in doing?

Sure, and my apologies if this is the wrong thread for this. My use case is querying for arbitrary shapes (can be points, multipoints, geometrycollection, polygon, etc...) at a certain distance from a point (actually thousands of points, but we handle this with a bool query). Due to geo_distance only working point-to-point, the workaround way to do this used to be to intersect a circle shape with the relevant index containing the arbitrary shapes. However, due to 6.8’s BKD indexing methodology not working with circles and geoshape intersection, I am left with using the deprecated geohash or prefixtree indexing or turning the circles into polygons and intersecting those. Both these workarounds are not good in my opinion, and are really just backwards ways to do a basic distance filter between a point and a shape, which geo_distance currently doesn’t support.