Use episerver categories? 

In that case you get the facets and getting the associations you can use the category api. 

Or store the paths "groceries/meat" in a separate property that you index as well and do a facet on that one. It's pretty nice to let the index have all information you need so you don't need to do n database calls when displaying lists.

Thanks for the suggestion.

If I had the static tree at the web server, it would all be very simple: all I'd need is the leaves and I could reconstruct the tree. But the tree is implicitly defined by the product properties. That is, if a Catalog administrator adds a product with area "music" and subarea "classical", this should show up, without the need to compatibly edit a separate area/subarea tree.

Then add that information to the object that is indexed in a separate property. And use that property to build your tree. If the taxonomy changes, update the indexed items...?

Sorry, but I don't follow you at all, could you give a concrete example of what you mean?

You can add fields to an indexed object by using conventions like in

http://world.episerver.com/documentation/Items/Developers-Guide/EPiServer-Find/11/DotNET-Client-API/Customizing-serialization/Including-fields/

Then you can add a field in index to your product that contains the full path like "groceries/meat" so you don't have to look it up in db when it is returned from index. Store everything you need to show relations etc directly on the indexed object.

Makes sense?

I guess what I'm not seeing is how to do the reduction at the Find end; that is, if I have 80,000 products which all match the search parameters, but they all have the same property/properties (say all are groceries/deli) how do I get back just the one distinct result from Find, rather than getting back 80,000 results and having to do the reduction/grouping at my end?

Have you seen this thread? http://world.episerver.com/forum/developer-forum/EPiServer-Search/Thread-Container/2016/1/sorting-results-by-quotgroup-byquot-like-function/

Ok, thanks, I guess I'll do something like that. But I have to say, it seems like a very inelegant way to have to do things. I mean, I have a couple of numeric properties*; I have to mash them together, convert to a string, then re-parse at my end. Why wouldn't Find/Elastic Search provide an easy way to return distinct results?

* for ease of description I presented them as strings above but actually they are numeric IDs

Yup, first get them into index as an additional field and the use facet to get them grouped on the other side when you fetch then. Yeah building trees of facets could be made easier. It takes a little work as is. 

Well, as I see it, the problem is not really the tree structure. Let's say all I want is a list of the Areas of the resulting products. Even this seems a bit problematic. "just use facets", but:

Since they are integers, I could try histogram; if they were compact (say 1-100) that would work fine but if they are sparse (depending on the representaion of the histogram) this could be very inefficient.

If I want to treat them as strings to use terms, I thought I could do "...Select(x => new {idstring = x.areaId.tostring()}).TermsForFacet(..." but that won't work, so it's actually necessary to add new fields to the objects I'm indexing, which wastes space and adds significantly to the maintainence of the DB (have to change the code for data entry to include the converted fields, etc.) 

All in all, I find it a bit disappointing that something this common and useful needs this kludgy implementation. I feel like I must be missing something.

Search indexes are great for collections of items but less so for relations between objects. That's where sql db rules. It's possible to solve without too much code but not as easy as if you were using EF and sql no. The last will be prettier code :)

I do however notice that Elastic Search does have aggregation; so why doesn't Find? Is there a theoretical reason, or is it just that they haven't added it to the C# api? Is there a way to directly use the elastic search features?

Facets is a form of aggregation. What was called facets in elastic search has been replaced by aggregate...(Which is more powerful)

Facets are somewhat more limited for nested data like yours true. It would be sweet with support for more than a single level of facets. Shouldn't be too tricky to add to find with a few creative extensions.

I'll add as a feature request...

Yes, Elastic Search aggregates seem to do actual grouping (buckets) which I think would be very useful. Thanks.