Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Fri, 18 Feb 2011 10:45:38 +0000 (UTC)
From: =?utf-8?Q?Jan_H=C3=B8ydahl_=28JIRA=29?= <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <963164021.229.1298025938459.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1175024671.20510.1297863237656.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Commented: (SOLR-2366) Facet Range Gaps
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/SOLR-2366?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D12996=
341#comment-12996341 ]=20

Jan H=C3=B8ydahl commented on SOLR-2366:
-----------------------------------

+1 for using absolute values instead of gap values
+1 for keeping the bucket spec as a separate param, including start and end
+1 for letting the start/end in the spec automatically disable hardend

I wrote down some thoughts the other day which is almost exactly what Hoss =
suggests, only I called it facet.range.spec :) Was going to start another i=
ssue but now that the dicussion is rolling here, here we go.

The facet.range.spec must be intuitive and should include start, all absolu=
te boundaries and end. Sample:

{code}
facet.range.spec=3D0,5,25,50,100,400 =3D=3D> 0-5, 5-25, 25-50, 50-100, 100-=
400.
{code}

To specify the gap size instead of next absolute threshold, we could have a=
 +N syntax:
{code}
facet.range.spec=3D0,5,25,+25,+50,400
{code}
would be equivalent to the above absolute spec.

A +N value would repeat as many times as needed to reach the next absolute =
value:
{code}
facet.range.spec=3D0,5,+10,25,50,100,+100,400 =3D=3D> 0-5, 5-15, 15-25, 25-=
50, 50-100, 100-200, 200-300, 300-400
facet.range.spec=3D0,5,+10,25,50,100,+100,400 =3D=3D> 0-5, 5-15, 15-25, 25-=
50, 50-100, 100-200, 200-300, 300-400
{code}

Date example:
{code}
facet.range.spec=3D*,2000-01-01T00:00:00Z,+5YEARS,NOW/YEAR,+1MONTH,NOW
{code}
...gives a range before 2000, two 5-year ranges 2000-2005, 2005-2010, one r=
ange until start of this year 2010-2011, then monthly ranges for this year =
until now.

Now, having all this power of defining buckets available, it would be easy =
to introduce (i.e. feature creep :) a facet.range.labels param. Imagine:
{code}
facet.range.spec=3DNOW/MONTH-1MONTH,NOW/MONTH,NOW/DAY-1DAY,NOW/DAY,NOW/HOUR=
,NOW,*
facet.range.labels=3D"Last month","This month","Yesterday","Today","This ho=
ur","Future"
{code}


> 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 complet=
ed and one were doing spatial distance calculations, one could facet by fun=
ction into 3 different sized buckets: walking distance (0-5KM), driving dis=
tance (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, i=
t creates the different size buckets.  If the number of buckets doesn't eve=
nly 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=3D0
> facet.range.end=3D400
> facet.range.gap=3D5,25,50,100
> would yield buckets of:
> 0-5,5-30,30-80,80-180,180-280,280-380,380-400

--=20
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