Add Geoshape support

[timonmasberg]

Currently, we can index geo points and sort them by distance or filter them by a radius. Adding a filter operation that filters out points by a polygon and the ability to index shapes with additional operations such as point in polygon, intersecting polygon and so on would be a massive enhancement.

[gmourier]

Hello @timonmasberg 👋

Thanks for your feedback! We already have in mind to add support for polygon and bounding box shapes.

Regarding intersection, it should be possible to express a complex filter that could describe an intersection. For example ... AND (_geoRadius(lat1, lng1, distance1) AND _geoRadius(lat2, lng2, distance2)) to get the documents that are located in the intersection space of the two geoRadius. If we add the support of polygons and bounding boxes it should be directly possible to intersect any shape with another one. Note that the OR and NOT operators can also be used.

You also talk about being able to index shapes directly rather than points. Can you elaborate on your use case?

[timonmasberg]

Thanks for the quick response! Let me elaborate. Imagine we have a dataset of administrative boundaries such as countries, states etc...
We now want to find the related administrative boundaries to a geo point. For that we can index the shapes of the boundaries and query something like _geoWithin(lat, lng). But I am just starting to evaluate different solutions for indexing and searching geospatial data and as far as I understand you currently can not query a specific field? This feature could work with a query like {"boundary": "_geoWithing(lat, long"}.

[gmourier]

Yes, in this case, I think it is interesting to let the choice of the name of the field that can contain the shape at the document level. We made the choice to force _geo to store coordinates but we could also evolve and let the choice to the user in this case too. On the other hand, I think, that it will be necessary to add a setting to specify that it contains and must be parsed as a geographic coordinates / set of geographic coordinates. It is therefore a balance between permissiveness and friction of use.

[timonmasberg]

Yes, or introduce two different field type _geoPoint and _geoShape. With that, it would be clear that a point expects [lat, long] and a shape has at least one nested array with n>=3 points. I understand that you use a rtree for indexing geodata with rstars rtree package (btw I have no experience in rust :( ). This should allow to store bounding boxes of the shapes to narrow the possibilities for point in shape operations.

[irevoire]

Hey @timonmasberg,

I'm late but I just released a prototype that may fit your use-case: prototype-cellulite-1.
It supports:

• Storing polygons at indexing time (as geojson)
• Retrieving anything in the database from a polygon specified in a filter
• ⚠️ It doesn't support sorting

Read the description for more information, and let us know if this has been useful to you and if we should finish the work.