You can think of it like faceted search, except instead of just getting a count, you get the top documents for that constraint or category. There are tons of potential use cases:

• For web search, only show 1 or 2 results for a given website by collapsing on a site field.
• For email search, only show 1 or 2 results for a given email thread
• For e-commerce, show the top 3 products for each store category (i.e. “electronics”, “housewares”)
• Hiding duplicate documents at query time.

In addition to being able to group by the values of a field, you can also group by the values of a function query. Given that geo search works as a function query, this also opens up possibilities for showing top query matches within 1 mile, between 1 and 2 miles, etc.

Just like faceting, we’ll be adding new functionality and making continual improvements.
Result Grouping is documented on the Solr Wiki, and you will need a recent
nightly build of Solr 4.0-dev to try it out (just make sure it’s dated after this post).

1. I just committed SOLR-1568 the other day, which adds automatic filter generation to the various point based Field Types in Solr.  It also has some small refactoring in the underlying Lucene code.  Furthermore, it adds a new LatLonType which can be used to represent latitude/longitude pairs seamlessly.  See http://wiki.apache.org/solr/SpatialSearch for the full details on Solr spatial.  Note, this is only available on trunk.  Volunteers to backport to 3.x would be most welcome.
2. As part of SOLR-1568, it became increasingly clear to me that the Cartesian Tier stuff in Lucene spatial simply does not work as intended for many, many things.  In my review and attempt at fixing the code, it became more than apparent that it only really works for the Western Hemisphere above the equator, i.e. the United States.  It may also work in the Eastern Hemisphere above the equator, too.  The reason it only really works above the equator is due to a miscalculation in the SinusoidalProjector.  See LUCENE-2519.  It also does not handle edge cases well at all, such as at the poles or the Prime/Anit Meridians, so if you have that case, then don’t bother.  I didn’t fix the SinusoidalProjector because it turned into a very tangled web of broken unit tests.  In discussions with other developers, we decided the whole tier system (and much of Lucene’s spatial should be deprecated/replaced).

I believe trunk is now in pretty decent shape for spatial search for applications that need:

1. Sorting by distance
2. Boosting by distance
3. Range-query (using Numeric Fields) based bounding box calculations, which should be sufficient for most people
4. Geohash based calculations

Trunk does not yet have the ability to:

1. add “pseudo” fields to the result set, so it is not possible to include the distance in the result set just like other stored fields
2. A tier/tile/grid based approach to filtering.  These approaches are especially helpful in highly dense areas as they can significantly reduce the number of terms that need to be enumerated
3. Faceting by functions, which can be useful for putting distances into buckets, as in something like: walking, biking, driving

For a list of all the related Solr/Lucene spatial issues, see SOLR-773.  Again, see http://wiki.apache.org/solr/SpatialSearch for a full accounting of what is in Solr and how to use it.

In summary, I think trunk is in pretty decent shape for spatial, as far as Solr is concerned.  Pure Lucene users will seem some upheaval in the coming months, but it is for the better.  Testers are needed and patches are welcome.  And, while the tier stuff feels like a step backward, I think it is clear to me that we have several committers along with many contributors who are very interested in seeing spatial support live and prosper.

Much of the functionality behind SOLR-773 is now implemented in the trunk version of Solr and is available for check out.  This includes support for several different distance measures (Euclidean, Haversine, etc.) as well as support for sorting by functions (aka sorting by distance).  Due note there are some minor issues left to fix on that one.  See SOLR-1297 for the gotchas there.  There is also support for several different point based field types now too.  See SOLR-1131 for more info.

Right now, I’m working on SOLR-1568, which will add the last “major” piece of needed functionality: spatial filtering based on FieldType.  I’m getting close to putting up a patch for review, but it will then take a week or two more from there to iterate and commit.

Beyond that, there are some minor things that would be nice to have, but not showstoppers, I don’t think, for the basic spatial use cases (sort, boost, filter by distance.)  For those wanting deeper capabilities along the lines of shape intersections, that’s a bit farther off, unless of course, you have a patch!

As always, feedback welcome!

Related link: On-Demand webinar
From Here to There, You Can Find it Anywhere: Building Local/Geo-Search with Apache Lucene and Solr

I’m particularly excited about a few things:

1. Massive scalability capabilities via distributed search, indexing and shard management – Up until now, Solr scales pretty well on the search side (I’ve seen billion+ document instances and we’ve benchmarked it at that level too), but the work underway in Solr 1.5 will take it to a whole new level, thanks to the integration of Apache ZooKeeper and other distributed technologies.  For those interested, check out the “cloud” branch in SVN.
2. Functions, functions, functions!  We’ve already added a bunch of functions (see my earlier post) and I see more on the horizon.  Additionally, I see great value in adding, for lack of a better phrase, aggregating functions to the mix (via SOLR-1622).  This will allow application designers to do much more sophisticated math across a search result set than what is currently available via the StatsComponent.  In some ways, this can empower business intelligence applications on top of Solr (I realize it is just a small piece of the BI pie) as well as more sophisticated mathematical applications.
3. Spatial Search!  It’s funny, a lot of people want spatial search and Solr could have simply harnessed a really nice existing package (LocalSolr) just as many already do, but by stepping back and taking a look at spatial in the context of the bigger picture of things (see SOLR-773) that would be nice to have in Solr, the community will be able to not only implement spatial search (by leveraging key pieces of LocalSolr where appropriate), but will also get a whole bevy of other features, including:
   1. Sort By Function – Instead of a one off that sorts solely by distance, why not enable Solr users to sort by any arbitrary function? I just committed this tonight via SOLR-1297.
   2. “Poly” Field Types – Thanks to SOLR-1131, Solr’s FieldType mechanism can be used to represent multiple underlying fields.  This is especially useful for representing things like points in an n-dimensional space, Cartesian Tiers (zoom levels) and other cool things.  Moreover, it shows the types of abstractions Solr can overlay on the already powerful Apache Lucene to provide even more functionality.
   3. Facet By Function – Sure, it’s great to put your distances into buckets, but why not put the result of any function into buckets?  See SOLR-1581.
   4. Spatial Query Parsers – aka geocoding – Parse things like street addresses, etc. and get back appropriate Query instances. See SOLR-1568 and SOLR-1578.
   5. Several different distance functions, including haversine (great circle), Manhattan, Euclidean (Solr actually now supports all p-norms as distance functions.)  See SOLR-1302.  I even added in the ability to do String distance calculations using Levenstein (edit), Jaro-Winkler, n-gram (basically all of the Lucene spellchecker distance measures, as well as any user defined String Distance calculation.
   6. “pseudo” fields – Instead of just hacking the ability to put a distance calculation into the result, why not allow the response to stream out “fields” based on things like functions or other user defined values?  See SOLR-1298.
4. Field Collapsing – I haven’t had time to work on it, but I suspect Field Collapsing will finally make it into 1.5.  Field Collapsing allows Solr to “roll-up” similar results much like you see on many Internet search sites that indent results from the same domain.
5. Payload and Span Query support – Solr’s been able to index payloads for some time now, but it still requires a user to hook in their own query parser support.  It would also be really great to see functions that can work on payloads, too. See SOLR-1337 and SOLR-1485.

Of course, as I always say, “in open source, you never know where the next good idea is going to come from”, so I have total faith that the Solr community will come up with a plethora of other great new features, as well as the usual bug fixes, etc.