Also, filtering and sorting on price can be done as well. Just be sure to use the correct price- field. Geert-Jan
2010/12/1 Geert-Jan Brits <gbr...@gmail.com> > Ok longer answer than anticipated (and good conceptual practice ;-) > > Yeah I belief that would work if I understand correctly that: > > 'in Jan [9] > in feb [10] > in march [1]' > > has nothing to do with pricing, but only with availability? > > If so you could seperate it out as two seperate issues: > > 1. ) showing pricing (based on context) > 2. ) showing availabilities (based on context) > > For 1.) you get 39 pricefields ([jan,feb,..,dec,dc] * > [standard,first,dc]) > note: 'dc' indicates 'don't care. > > depending on the context you query the correct pricefield to populate the > price facet-values. > for discussion lets call the fields: _p[fare][date]. > IN other words the price field for no preference at all would become: > _pdcdc > > > For 2.) define a multivalued field 'FaresPerDate 'which indicate > availability, which is used to display: > > A) > Standard fares [10] > First fares [3] > > B) > in Jan [9] > in feb [10] > in march [1] > > A) depends on your selection (or dont caring) about a month > B) vice versa depends on your selection (or dont caring) about a fare type > > given all possible date values: [jan,feb,..dec,dontcare] > given all possible fare values:[standard,first,dontcare] > > FaresPerDate consists of multiple values per document where each value > indicates the availability of a combination of 'fare' and 'date': > > (standardJan,firstJan,DCjan...,standardJan,firstDec,DCdec,standardDC,firstDC,DCDC) > Note that the nr of possible values = 39. > > Example: > 1. ) the user hasn't selected any preference: > > q=*:*&facet.field:FaresPerDate&facet.query=_pdcdc:[0 TO > 20]&facet.query=_pdcdc:[20 TO 40], etc. > > in the client you have to make sure to select the correct values of > 'FaresPerDate' for display: > in this case: > > Standard fares [10] --> FaresPerDate.standardDC > First fares [3] --> FaresPerDate.firstDC > > in Jan [9] -> FaresPerDate.DCJan > in feb [10] -> FaresPerDate.DCFeb > in march [1]-> FaresPerDate.DCMarch > > 2) the user has selected January > q=*:*&facet.field:FaresPerDate&fq=FaresPerDate:DCJan&facet.query=_pDCJan:[0 > TO 20]&facet.query=_pDCJan:[20 TO 40] > > Standard fares [10] --> FaresPerDate.standardJan > First fares [3] --> FaresPerDate.firstJan > > in Jan [9] -> FaresPerDate.DCJan > in feb [10] -> FaresPerDate.DCFeb > in march [1]-> FaresPerDate.DCMarch > > Hope that helps, > Geert-Jan > > > 2010/12/1 lee carroll <lee.a.carr...@googlemail.com> > > 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 >> >> > > > >> >> > > >> >> > >> >> >> > >> > >> > >
