Improvements to geo-coordinate based filtering about weaviate HOT 5 OPEN

+1 This was unintuitive and masked some issues with other parts of our retrieval stack; from the documentation I assumed that a nearText combined with withinGeoRange would return all the relevant documents, not a subset.

from weaviate.

Please fix this issue it renders using maps in any mobile app with Weaviate under the hood useless. Make the expected behavior actually work (expand the geo radius as you make the max distance parameter bigger)

Test it for yourselves it's horrible 👨🥹

from weaviate.

Please fix this issue it renders using maps in any mobile app with Weaviate under the hood useless. Make the expected behavior actually work (expand the geo radius as you make the max distance parameter bigger)
Test it for yourselves it's horrible 👨🥹

Hey @crispyadmin I understand this is a frustrating issue but let's keep the discussion constructive :). In the meantime, a workaround might be to use geohashing, and then to use filters such as containsAll or containsAny to match sections within X number of tile range.

Note that due to how filters work, substring matches (i.e. LIKE) filters will be slower than exact matches, which is why I recommend using containsAll / containsAny.

Here is a brief explanation of geohashing. https://medium.com/@bkawk/geohashing-20b282fc9655

from weaviate.

can you show a code example of how I would use geohashing with the client?

Sorry geo hashing is quite new to me. So i would convert lat and long to the geohash and then what field am I filtering on in my Weaivate Cluster? Would i still be using my geo field?

from weaviate.

Sorry geo hashing is quite new to me. So i would convert lat and long to the geohash and then what field am I filtering on in my Weaivate Cluster? Would i still be using my geo field?

The geohash would be a string, where the longer the matched string the smaller the area is. In the articled that I linked to above, “9q8y” and “9q8z" are subsets of the “9q8” area.

from weaviate.