If these are not raw times, but quantized on-the-hour, would it be faster to create a bit map of hours and then query across the bit maps?
On Sun, Dec 9, 2012 at 8:06 AM, Erick Erickson <erickerick...@gmail.com> wrote: > Thanks for the discussion, I've added this to my bag of tricks, way cool! > > Erick > > > On Sat, Dec 8, 2012 at 10:52 PM, britske <gbr...@gmail.com> wrote: > >> Brilliant! Got some great ideas for this. Indeed all sorts of usecases >> which use multiple temporal ranges could benefit.. >> >> Eg: Another Guy on stackoverflow asked me about this some days ago.. He >> wants to model multiple temporary offers per product (free shopping for >> christmas, 20% discount for Black friday , etc) .. All possible with this >> out of the box. Factor in 'offer category' in x and y as well for some >> extra powerfull querying. >> >> Yup im enthousiastic about it , which im sure you can tell :) >> >> Thanks a lot David, >> >> Cheers, >> Geert-Jan >> >> >> >> Sent from my iPhone >> >> On 9 dec. 2012, at 05:35, "David Smiley (@MITRE.org) [via Lucene]" < >> ml-node+s472066n4025434...@n3.nabble.com> wrote: >> >> > britske wrote >> > That's seriously awesome! >> > >> > Some change in the query though: >> > You described: "To query for a business that is open during at least some >> > part of a given time duration" >> > I want "To query for a business that is open during at least the entire >> > given time duration". >> > >> > Feels like a small difference but probably isn't (I'm still wrapping my >> > head on the intersect query I must admit) >> > So this would be a slightly different rectangle query. Interestingly, >> you simply swap the location in the rectangle where you put the start and >> end time. In summary: >> > >> > Indexed span CONTAINS query span: >> > minX minY maxX maxY -> 0 end start * >> > >> > Indexed span INTERSECTS (i.e. OVERLAPS) query span: >> > minX minY maxX maxY -> 0 start end * >> > >> > Indexed span WITHIN query span: >> > minX minY maxX maxY -> start 0 * end >> > >> > I'm using '*' here to denote the max possible value. At some point I >> may add that as a feature. >> > >> > That was a fun exercise! I give you credit in prodding me in this >> direction as I'm not sure if this use of spatial would have occurred to me >> otherwise. >> > >> > britske wrote >> > Moreover, any indication on performance? Should, say, 50.000 docs with >> > about 100-200 points each (1 a 2 open-close spans per day) be ok? ( I >> know >> > 'your mileage may very' etc. but just a guestimate :) >> > You should have absolutely no problem. The real clincher in your favor >> is the fact that you only need 9600 discrete time values (so you said), not >> Long.MAX_VALUE. Using Long.MAX_VALUE would simply not be possible with the >> current implementation because it's using Doubles which has 52 bits of >> precision not the 64 that would be required to be a complete substitute for >> any time/date. Even given the 52 bits, a quad SpatialPrefixTree with >> maxLevels="52" would probably not perform well or might fail; not sure. >> Eventually when I have time to work on an implementation that can be based >> on a configurable number of grid cells (not unlike how you can configure >> precisionStep on the Trie numeric fields), 52 should be no problem. >> > >> > I'll have to remember to refer back to this email on the approach if I >> create a field type that wraps this functionality. >> > >> > ~ David >> > >> > britske wrote >> > Again, this looks good! >> > Geert-Jan >> > >> > 2012/12/8 David Smiley (@MITRE.org) [via Lucene] < >> > [hidden email]> >> > >> > > Hello again Geert-Jan! >> > > >> > > What you're trying to do is indeed possible with Solr 4 out of the box. >> > > Other terminology people use for this is multi-value time duration. >> This >> > > creative solution is a pure application of spatial without the >> geospatial >> > > notion -- we're not using an earth or other sphere model -- it's a flat >> > > plane. So no need to make reference to longitude & latitude, it's x & >> y. >> > > >> > > I would put opening time into x, and closing time into y. To express a >> > > point, use "x y" (x space y), and supply this as a string to your >> > > SpatialRecursivePrefixTreeFieldType based field for indexing. You can >> give >> > > it multiple values and it will work correctly; this is one of RPT's >> main >> > > features that set it apart from Solr 3 spatial. To query for a >> business >> > > that is open during at least some part of a given time duration, say >> 6-8 >> > > o'clock, the query would look like openDuration:"Intersects(minX minY >> maxX >> > > maxY)" and put 0 or minX (always), 6 for minY (start time), 8 for maxX >> > > (end time), and the largest possible value for maxY. You wouldn't >> actually >> > > use 6 & 8, you'd use the number of 15 minute intervals since your >> epoch for >> > > this equivalent time span. >> > > >> > > You'll need to configure the field correctly: geo="false" >> worldBounds="0 0 >> > > maxTime maxTime" substituting an appropriate value for maxTime based on >> > > your unit of time (number of 15 minute intervals you need) and >> > > distErrPct="0" (full precision). >> > > >> > > Let me know how this works for you. >> > > >> > > ~ David >> > > Author: >> > > http://www.packtpub.com/apache-solr-3-enterprise-search-server/book >> > Author: >> http://www.packtpub.com/apache-solr-3-enterprise-search-server/book >> > >> > >> > If you reply to this email, your message will be added to the discussion >> below: >> > >> http://lucene.472066.n3.nabble.com/Modeling-openinghours-using-multipoints-tp4025336p4025434.html >> > To unsubscribe from Modeling openinghours using multipoints, click here. >> > NAML >> >> >> >> >> -- >> View this message in context: >> http://lucene.472066.n3.nabble.com/Modeling-openinghours-using-multipoints-tp4025336p4025454.html >> Sent from the Solr - User mailing list archive at Nabble.com. >> -- Lance Norskog goks...@gmail.com
