You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2011/06/28 00:00:49 UTC

[jira] [Commented] (SOLR-2366) Facet Range Gaps

    [ https://issues.apache.org/jira/browse/SOLR-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13055793#comment-13055793 ] 

Hoss Man commented on SOLR-2366:
--------------------------------

bq. 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. ...

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

I respect your argument, but i think if this new "spec" param is going to be mutually exclusive of facet.range.other as well as all of the existing mandatory facet.range params (facet.range.gap, facet.range.start, and facet.range.end) then it seems like what you're describing really shouldn't be an extension of "facet.range" at all ... it sounds should be some completley distinct type of faceting ("sequence faceting" ?) with it's own params and section in the response.  ie...

{noformat}
facet.seq=fieldName
f.fieldName.facet.seq.spec=0,5,25,50,100,200,400,*
f.fieldName.facet.seq.include=edge
{noformat}

(where facet.seq.include has same semantics as facet.range.include ... except i don't think "edge" makes sense at all w/o the "other" param concept ... need to think it through more)

Otherwise it could get really confusing for users trying to udnerstandwhat "facet.range.*" params do/don't make sense if they start using facet.range.gap and then switch to facet.range.spec (or vice-versa)  ... ie: "how come i'm not getting the before/after ranges when i use 'facet.range.spec=0,5,25,50&facet.range.other=after' ?")



> 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.3
>
>         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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org