With the number of hotspots on the network growing at a fast clip, it's getting too expensive to fetch and store all hotspots in memory. And Algolia's geospatial search while fast, is pricey, only gives us a limited number of hotspots within a radius, and isn't integrated with helium-js to return Hotspot objects. Therefore it'd be great to allow our existing hotspots route to take a bounding box which would be the currently viewed map area, and return a cursor-paginated list of hotspots within that bounding box.
I'd propose a bounding box be defined as the SW + NE coordinates to be consistent with Mapbox. If indexes are added to the lat/lng columns, then it should be relatively efficient to do a BETWEEN query:
WHERE lat BETWEEN :minLat AND :maxLat AND lng BETWEEN :minLng AND :maxLng
We can choose to address the wrapping issue at 180 degrees longitude if we want, or just do the above as a first pass at a solution, given that we don't expect m/any queries to be made over the pacific in that geography.
madninja
commented
3 years ago
With the number of hotspots on the network growing at a fast clip, it's getting too expensive to fetch and store all hotspots in memory. And Algolia's geospatial search while fast, is pricey, only gives us a limited number of hotspots within a radius, and isn't integrated with helium-js to return
Hotspotobjects. Therefore it'd be great to allow our existing hotspots route to take a bounding box which would be the currently viewed map area, and return a cursor-paginated list of hotspots within that bounding box.I'd propose a bounding box be defined as the SW + NE coordinates to be consistent with Mapbox. If indexes are added to the lat/lng columns, then it should be relatively efficient to do a
BETWEENquery:We can choose to address the wrapping issue at 180 degrees longitude if we want, or just do the above as a first pass at a solution, given that we don't expect m/any queries to be made over the pacific in that geography.