Sure - and sorry for its density. I reread it and thought the same ;) So imagine a polygon of say 1/2 mile width (I made that up) that stretches around the equator. Let's call this a week's timeline and subdivide it into 7 blocks, one for each day. For the sake of simplicity assume it's a line (which I forget but is supported in Solr as an infinitely small polygon) starting at (0,-180) for Monday at 12:00 AM and ending back at (0,180) for Sunday at 11:59 PM. By subdivide you can think of it either radially or by longitude, but you have 360 degrees to divide into 7, which means that every hour is represented by a range of roughly 2.143 degrees (360/7/24). These regions represent each day and hour (or less), and the region boundaries represent midnight for the day before.
Now for indexing - your open hours then become a combination of these subdivisions. If you're open 24x7 then the whole polygon is indexed. If you're only open on Monday from 9-5 then only the polygon between (0,-160.7) and (0,-143.57) is indexed. With careful attention to detail you can index any combination of times this way. So now the varsity question is how to do this with a fluctuating calendar? I think this example can be extended to include searching against any given day of the week in a year, or years. Just imagine a translation layer that adjusts the latitude N or S by some amount to represent which day in which year you're looking for. Make sense? On Wed, Aug 26, 2015 at 10:50 AM, Upayavira <u...@odoko.co.uk> wrote: > "delightfully dense" = really intriguing, but I couldn't quite > understand it - really hoping for more info > > On Wed, Aug 26, 2015, at 03:49 PM, Upayavira wrote: > > Darren, > > > > That was delightfully dense. Do you think you could unpack it a bit > > more? Possibly some sample (pseudo) queries? > > > > Upayavira > > > > On Wed, Aug 26, 2015, at 03:02 PM, Darren Spehr wrote: > > > If you wanted to try a spatial approach that blended times like above, > > > you > > > could try a polygon of minimum width that spans the globe - this is > > > literally using spatial search (geocodes) against time. So in this > > > scenario > > > you logically subdivide the polygon into 7 distinct regions (for days) > > > and > > > then within this you can defined, like a timeline, what open and closed > > > means. The problem of 3AM is taken care of because of it's continuous > > > nature - ie one day is adjacent to the next, with Sunday and Monday > > > backing > > > up to each other. Just a thought. > > > > > > On Wed, Aug 26, 2015 at 5:38 AM, Upayavira <u...@odoko.co.uk> wrote: > > > > > > > > > > > > > > > On Wed, Aug 26, 2015, at 10:17 AM, O. Klein wrote: > > > > > Those options don't fix my problem with closing times the next > morning, > > > > > or is > > > > > there a way to do this? > > > > > > > > Use the spatial model, and a time window of a week. There are 10,080 > > > > minutes in a week, so you could use that as your scale. > > > > > > > > Assuming the week starts at 00:00 Monday morning, you might index > Monday > > > > 9:00-23:00 as 540:1380 > > > > > > > > Tuesday 9am-Wednesday 1am would be 1980:2940 > > > > > > > > You convert your NOW time into a "minutes since Monday 00:00" and do > a > > > > spatial search within that time. > > > > > > > > If it is now Monday, 11:23am, that would be 11*60+23=683, so you > would > > > > do a search for 683:683. > > > > > > > > If you have a shop that is open over Sunday night to Monday, you just > > > > list it as open until Sunday 23:59 and open again Monday 00:00. > > > > > > > > Would that do it? > > > > > > > > Upayavira > > > > > > > > > > > > > > > > -- > > > Darren > -- Darren
