lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl (JIRA) <>
Subject [jira] [Commented] (SOLR-2366) Facet Range Gaps
Date Sun, 03 Apr 2011 20:59:05 GMT


Jan Høydahl commented on SOLR-2366:

bq. If you want "everything before" and/or "everything after" use facet.range.include=before
and/or facet.range.include=after .. otherwise it would be confusing to decide what things
like facet.range.include=before&facet.range.seq=*,10,20 and facet.range.include=none&facet.range.seq=
* ,10,20 mean.

I think you meant facet.range.other=before/after, not facet.range.include=before/after - see,
the syntax is confusing :)

Guess my main point with the examples was to suggest that a facet.range.spec should not require
facet.range.start and facet.range.end, but that the first and last values in the spec list
should be taken as start and end, instead of requiring start and end in addition. In my opinion

is more fluent and easy to read that the first and last buckets will be 0-5 and 200-400, than

and when talking about before/after,

is in my mind better than

Simply document that facet.range.spec is mutually exclusive to the parameters gap,start,end
and other.

bq. I REALLY don't think we should try to implement something like Jan's facet.range.labels

Sure, this is not a priority since it's possible with facet.query

+1 on concentrating on a simple "spec" or "sequence" feature in some flavour

> Facet Range Gaps
> ----------------
>                 Key: SOLR-2366
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Grant Ingersoll
>            Priority: Minor
>             Fix For: 3.2, 4.0
>         Attachments: SOLR-2366.patch, SOLR-2366.patch
> There really is no reason why the range gap for date and numeric faceting needs to be
evenly spaced.  For instance, if and when SOLR-1581 is completed and one were doing spatial
distance calculations, one could facet by function into 3 different sized buckets: walking
distance (0-5KM), driving distance (5KM-150KM) and everything else (150KM+), for instance.
 We should be able to quantize the results into arbitrarily sized buckets.  I'd propose the
syntax to be a comma separated list of sizes for each bucket.  If only one value is specified,
then it behaves as it currently does.  Otherwise, it creates the different size buckets. 
If the number of buckets doesn't evenly divide up the space, then the size of the last bucket
specified is used to fill out the remaining space (not sure on this)
> For instance,
> facet.range.start=0
> facet.range.end=400
> would yield buckets of:
> 0-5,5-30,30-80,80-180,180-280,280-380,380-400

This message is automatically generated by JIRA.
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message