Query geospatial data with a bounding box

It would be a great addition to the Redis geospatial query system to be able to query with a bounding box.

Use case; Populate a map view with points of interest from the geospatial data. Eg. An app where a user opens a map, moves the view to a specific area, and then would like to see all points of interests within this crop of the map.

Proposed command(a): GEOBOUNDINGBOX key longitudeTopLeft latitudeTopLeft longitudeBottomRight latitudeBottomRight [WITHCOORD] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key]

Proposed command(b): GEOBOUNDINGBOX key longitudeCenter latitudeCenter height width m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]

I am not familiar with the details of how the geospatial system is implemented, so I am not aware of any difficulties relating to creating this command. Between a and b I would prefer b.

I am submitting this request in response to the answer on Stackoverflow: https://stackoverflow.com/questions/47110812/query-redis-geospatial-data-with-a-bounding-box/47111206#47111206

Comment From: itamarhaber

+1 for the proposed functionality and AFAIU it shouldn't be too hard to expose the internally-used bounding box logic for public use.

WRT to the proposed API:

  • option b is preferable because it is more similar to the existing radius query approach
  • for symmetry's sake there should also be a GEOBOUNDINGBOXBYMEMBER
  • the STORE subcommand has a design flaw as we've seen with the existing query commands - see https://github.com/antirez/redis/commit/f8547e53f0d80b4cd2a84c6d39d1e08a470f0a2c

Comment From: lkonzen-garupa

Any news about this feature?

Comment From: itamarhaber

@antirez I can take a stab at implementing this, providing that I get your blessing :-)

Comment From: madolson

Status: There is very clearly interest in this feature, I think the status here is we need to get conensus on the API. I am also in fan of option b, as it's more consistent with other types of GEO commands. So we need consensus about adding the following two types of commands, and then we need someone to implement it. Itamar expressed interest in the implementation, but I think anyone could work on this. 

GEOBOUNDINGBOX key longitudeCenter latitudeCenter height width m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]

GEOBOUNDINGBOXBYMEMBER key member height width m|km|ft|mi [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]

Comment From: itamarhaber

For the sake of API succinctness and following industry standards, I'd like to propose GEOBBOX and GEOBBOXBYMEMBER as an alternative.

Comment From: yangbodong22011

hi, @itamarhaber I don’t know if you have already started the implementation. If not, can I get your approval to start the implementation. (GEOBBOX and GEOBBOXBYMEMBER)

Comment From: oranagra

Hi all, in the PR discussion we came up with a slightly different idea to deprecated the 4 existing GEORADIUS* commands and create something new, instead of adding 4 more variants.

These commands with with an optional STORE argument are causing a lot of pain (it's hard to flag them as write or read commands, and it's hard to extract the key names from the arguments).

so the new idea is to have:

GEOSEARCH key [FROMMEMBER member] [FROMLOC long lat] [BYRADIUS radius unit] [BYBOX width height unit] [WITHCORD] [WITHDIST] [WITHASH] [COUNT count] [ASC|DESC]

GEOSEARCHSTORE dest_key src_key [FROMMEMBER member] [FROMLOC long lat] [BYRADIUS radius unit] [BYBOX width height unit] [WITHCORD] [WITHDIST] [WITHASH] [COUNT count] [ASC|DESC] [STOREDIST]

meaning: we only have two commands, one that always stores, and one that never stores. instead of the 4 commands we already have, and the 4 we were going to add. the store variant can either store the results, or the dist (same as the original commands had both STORE and STOREDIST arguments), but the key name is in a fixed position and easy to extract from the command arguments. the commands have a FROMMEMBER optional argument (instead of the specific command variant for that) the BYBOX / BYRADIUS options can be extended in the future with other creteria (non-axis-aligned bbox)

Let us know if you find any problem with that suggestion or see ways to improve it.

Comment From: sapirshamun

Hi all, I didn't understand if there is an option to search by bounding box which isn't axis-aligned?

Comment From: oranagra

@sapirshamun, no. only axis-aligned (the arguments are "width" and "height"), see https://redis.io/docs/latest/commands/geosearch/