lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2366) Facet Range Gaps
Date Mon, 27 Jun 2011 22:00:49 GMT

    [ 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


Mime
View raw message