[
https://issues.apache.org/jira/browse/SOLR-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015216#comment-13015216
]
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
{code}
facet.range.spec=0,5,25,50,100,200,400
{code}
is more fluent and easy to read that the first and last buckets will be 0-5 and
200-400, than with
{code}
facet.range.spec=5,25,50,100,200
facet.range.start=0
facet.range.end=400
{code}
and when talking about before/after,
{code}
facet.range.spec=0,5,25,50,100,200,400,*
{code}
is in my mind better than
{code}
facet.range.spec=5,25,50,100,200
facet.range.start=0
facet.range.end=400
facet.range.other=after
{code}
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 suggestion
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: https://issues.apache.org/jira/browse/SOLR-2366
> 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
> facet.range.gap=5,25,50,100
> 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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
