In order to get the results, why do we need to store Location IDs in quad tree. Aren’t we already storing the Grid Id (as a column) against each place in the database?
Search flow would be (Keeping it simple for brevity sake)
Get to the lead node in which the search lat, long falls into
Get its grid ID
and search places from DB that has this Grid Id
Am I missing something? Kindly clarify. Thank you!
I’m confused too. There are not many details. Do we even have grid ID in the quadtree?
All locations in the grid will not satisfy the distance so we filter those location ids with lat/long and only query the locations which satisfy. We don’t need gridId in this case.
If you go with the grid Id approach, you will end up doing intersection of all the lists filtered by lat, long and grid.
Your statement “and search places from DB that has this Grid ID” itself gives it away why you store the LocationID. Once you have reached the Grid which has all the places, why do you want to query the DB again. The data is right there… all the locations the user will be interested in. So why make another DB call ?
I think author missed to write the point that to make better search instead of DB query we would rather create a separate Data Structure in order to find the location IDs efficiently. In that case I think we don’t need to put GRIDID in each row of the location information in Location table. We can directly query to QuadTree DB to find the nearest location for the given location Id.
I’m late to the party here, but note that GridId is not constant for a location. As we add locations we might repartition the QuadTree, which would change the GridId for many locations. Therefore I do not think we should put GridId in the location table since it would require a mass update.