[FR] Query optional for geo use cases in FT.SEARCH

[stockholmux]

Let's say I have 20 widgets scattered around a field. These widgets have certain characteristics (colour, name, whatev) I want searchable, so I use RediSearch and have a location field. Normally, I want to be able to find these widgets by colour and use this

FT.SEARCH widgets "@colour:blue" GEOFILTER location -113.48 53.56 10 m

But sometimes I don't care about those characteristics and I just want to find all the widgets, so my query argument could be empty but that isn't possible.

I can accomplish this with a dirty hack:
FT.SEARCH widgets "~x" GEOFILTER location -113.48 53.56 10 m (x doesn't appear any any of the data... so everything)

I imagine this is not intended to work. Seems like something along the lines of:
FT.GEOONLYSEARCH widget location -113.48 53.56 10 m
or
FT.SEARCH widgets GEOONLY location -113.48 53.56 10 m
Would be the way to address this use case

(I know that geo:widgets/location is just a zset/geo store, but the members are meaningless).

[dvirsky]

It would require designing a syntax to allow the geofilter to get into the query language, like the numeric filters. I'm not so sure about how to express it syntactically.

[dvirsky]

Ok, how about this for the syntax of geo queries @stockholmux:

since a numeric query is expressed as @field[{min} {max}] i.e. @price:[250 350] etc.

How about we express radius clauses like this:

@field:[{lon} {lat} {radius} {unit}]

e.g.

@location:[32.0853 34.7818 10 km]
@location:[32.0853 34.7818 10000 m]

So having it as optional will look like:

@business_name:mcdonalds ~@location:[32.0853 34.7818 10 km]

And you can also combine it any other way - in unions, negative clauses, intersection with other geo fields, whatever.

Of course it will usually be abstracted by the client library, but I still want a clear and simple syntax for this.

WDYT?

[stockholmux]

I think that makes a lot of sense.

My only question would be if you executed something like this:

FT.SEARCH widgets "@location:[32.0853 34.7818 10 km]" GEOFILTER location -113.48 53.56 10 m

I assume the query syntax would take precedent over the geofilter? It might need a little explanation in documentation since they seem very close in application.

[dvirsky]

I will deprecate the keyword once I've put it in the query string I guess, and advise against using the keyword.

[dvirsky]

And it's not a question of precedence - they will both apply and you will get the intersection of the two filters. If there is no overlap you will get no results.

[dvirsky]

It's been merged into master, syntax is "@location:[32.0853 34.7818 10 km]