As you've observed, this does make geo calculations in this manner inefficient. However, you just have to think about the problem differently. Instead, you can set up an artificial grid (of say 1 mile squares), and for each location, emit as the key which grid cell it lies in. Then, when you're looking for a center point, you find which grid cell it lies in, and query accordingly. For a 1 mile radius, you might ask for the cell containing the center point itself and 4 of it's neighbors (using multi-key fetch). For 2 miles, you might ask for 16 cells (4x4 cells).
This will give you approximate results - it will always include all of the locations, but will include some extra locations as well. So you just need to filter them down at this point, in the client-side (or somewhere else in your backend). For our application (http://www.magnifeast.com), we didn't use CouchDB for the geo search directly - we do the bucketing in a separate search server that pulls documents from Couch using all_docs_by_seq. But that's because we have to search on a lot of different criteria, and that would create an explosion of different views for all of the combinations and sorting options (not to mention the difficulty of merging / combining the output of multiple views). On Sat, Aug 8, 2009 at 10:06 AM, Adam Kocoloski<[email protected]> wrote: > On Aug 7, 2009, at 1:35 PM, Matt King wrote: > >> Hi all, >> >> I have question about how views work. I read that when you create a view, >> CouchDB indexes it so it's faster on the next request. But if I pass in >> startkey and endkey, does it only index the docs that are returned? Or is >> the entire list indexed and CouchDB returns the offsets as requested? > > Hi Matt, each time a view is queried CouchDB indexes all the documents that > have changed since the last query and then returns the updated result. > Query-string parameters like startkey and endkey don't affect this behavior > (in fact, if you think about we _can't_ filter the list of docs to be > indexed based on those parameters, since we don't know a priori what keys > will be emitted by a map over a given document). > > Best, Adam >
