Sorry Geert missed of the price value bit from the user interface so we'd display
Facet price Standard fares [10] First fares [3] When traveling in Jan [9] in feb [10] in march [1] Fare Price 0 - 25 : [20] 25 - 50: [10] 50 - 100 [2] cheers lee c On 1 December 2010 17:00, lee carroll <lee.a.carr...@googlemail.com> wrote: > Geert > > The UI would be something like: > user selections > for the facet price > max price: £100 > fare class: any > > city attributes facet > cityattribute1 etc: xxx > > results displayed something like > > Facet price > Standard fares [10] > First fares [3] > in Jan [9] > in feb [10] > in march [1] > etc > is this compatible with your approach ? > > Erick the price is an interval scale ie a fare can be any value (not high, > low, medium etc) > > How sensible would the following approach be > index city docs with fields only related to the city unique key > in the same index also index fare docs which would be something like: > Fare: > cityID: xxx > Fareclass:standard > FareMonth: Jan > FarePrice: 100 > > the query would be something like: > q=FarePrice:[* TO 100] FareMonth:Jan fl=cityID > returning facets for FareClass and FareMonth. hold on this will not facet > city docs correctly. sorry thasts not going to work..... > > > > > > > > > On 1 December 2010 16:25, Erick Erickson <erickerick...@gmail.com> wrote: > >> Hmmm, that's getting to be a pretty clunky query sure enough. Now you're >> going to >> have to insure that HTTP request that long get through and stuff like >> that.... >> >> I'm reaching a bit here, but you can facet on a tokenized field. Although >> that's not >> often done there's no prohibition against it. >> >> So, what if you had just one field for each city that contained some >> abstract >> information about your fares etc. Something like >> janstdfareclass1 jancheapfareclass3 febstdfareclass6.... >> >> Now just facet on that field? Not #values# in that field, just the field >> itself. You'd then have to make those into human-readable text, but that >> would considerably simplify your query. Probably only works if your user >> is >> selecting from pre-defined ranges, if they expect to put in arbitrary >> ranges >> this scheme probably wouldn't work... >> >> Best >> Erick >> >> On Wed, Dec 1, 2010 at 10:22 AM, lee carroll >> <lee.a.carr...@googlemail.com>wrote: >> >> > Hi Erick, >> > so if i understand you we could do something like: >> > >> > if Jan is selected in the user interface and we have 10 price ranges >> > >> > query would be 20 cluases in the query (10 * 2 fare clases) >> > >> > if first is selected in the user interface and we have 10 price ranges >> > query would be 120 cluases (12 months * 10 price ranges) >> > >> > if first and jan selected with 10 price ranges >> > query would be 10 cluases >> > >> > if we required facets to be returned for all price combinations we'd >> need >> > to >> > supply >> > 240 cluases >> > >> > the user interface would also need to collate the individual fields into >> > meaningful aggragates for the user (ie numbers by month, numbers by fare >> > class) >> > >> > have I understood or missed the point (i usually have) >> > >> > >> > >> > >> > On 1 December 2010 15:00, Erick Erickson <erickerick...@gmail.com> >> wrote: >> > >> > > I'd think that facet.query would work for you, something like: >> > > &facet=true&facet.query=FareJanStandard:[price1 TO >> > > price2]&facet.query:fareJanStandard[price2 TO price3] >> > > You can string as many facet.query clauses as you want, across as many >> > > fields as you want, they're all >> > > independent and will get their own sections in the response. >> > > >> > > Best >> > > Erick >> > > >> > > On Wed, Dec 1, 2010 at 4:55 AM, lee carroll < >> > lee.a.carr...@googlemail.com >> > > >wrote: >> > > >> > > > Hi >> > > > >> > > > I've built a schema for a proof of concept and it is all working >> fairly >> > > > fine, niave maybe but fine. >> > > > However I think we might run into trouble in the future if we ever >> use >> > > > facets. >> > > > >> > > > The data models train destination city routes from a origin city: >> > > > Doc:City >> > > > Name: cityname [uniq key] >> > > > CityType: city type values [nine possible values so good for >> > faceting] >> > > > ... [other city attricbutes which relate directy to the doc >> unique >> > > key] >> > > > all have limited vocab so good for faceting >> > > > FareJanStandard:cheapest standard fare in january(float value) >> > > > FareJanFirst:cheapest first class fare in january(float value) >> > > > FareFebStandard:cheapest standard fare in feb(float value) >> > > > FareFebFirst:cheapest first fare in feb(float value) >> > > > ..... etc >> > > > >> > > > The question is how would i best facet fare price? The desire is to >> > > return >> > > > >> > > > number of citys with jan prices in a set of ranges >> > > > etc >> > > > number of citys with first prices in a set of ranges >> > > > etc >> > > > >> > > > install is 1.4.1 running in weblogic >> > > > >> > > > Any ideas ? >> > > > >> > > > >> > > > >> > > > Lee C >> > > > >> > > >> > >> > >
