Running geo_shape queries on geo_points

[krambambuli]

Hi, the forum already has a few questions related to this (some unfortunately unanswered) but I'm unsure what the best practice is: If I have geo_points in my data on which I want to run geo_shape queries, should I

• put the point in my document twice, once as shape, once as point,
• or is there some other way I don't know about? (transforming the type when running the query etc.)

Thanks.

[warkolm (Mark Walkom)]

You mean you want to run intersects/contains/etc type queries on your point?

[krambambuli]

Yes, exactly, though I guess the query I'm most interested in is a geo_shape query with "within" as the relation.

[Ignacio_Vera]

I don't understand the problem here. Intersects and within when querying for points are basically equivalent, and intersects normally runs much faster. Why do you thing you need geo_shape queries in this case?

[krambambuli]

Maybe I'm not understanding the documentation correctly, sorry for any confusion caused by this.

I have documents with a location field. What I would like to do is to run a query to find out for which documents the location falls within a given shape. If I understand the documentation correctly, my options for this are geo_polygon or geo_shape queries.

Since my shapes are quite big and will be reused, I'd rather have them indexed instead of putting them directly into the query. As far as I can see, geo_polygon queries don't support that. So I have to use geo_shape queries which ask for the field to be filtered on to be mapped to type geo_shape (as per the documentation).

Since I also want the option to run geo_distancequeries, I need my locations as geo_points too.

Happy to learn that the above is not correct and life is simpler than it seems.

[Ignacio_Vera]

Thanks for the explanation. Querying by indexed shapes is only supported for geo_shapes. My recommendation in that cases would be to use intersects as a relationship as it is faster than within.

Not sure if indexing the shapes is the best strategy here, geo_polygon queries are the most efficient ones, so you might want to test if the strategy gives you the performance and accuracy that you need.