Re: Search opening hours

[David Smiley]

Lets say you wanted to do ranges over some integer.  Simply convert those
integers to dates, such as
java.time.Instant.ofEpochSecond(myInteger).toString().  It's more efficient
to convert to seconds (as in this example) as a base instead milliseconds
because the internal date oriented tree has 1000 leaves at the millisecond
level to aggregate to the next higher (second).  Also keep in mind you have
to work within a signed Long space.

Longer term, hopefully someone will add a Solr adapter to Lucene's
new IntRangeField (and *RangeField variants) which is for general use.  I'm
not sure if LongRangeField would be faster than DateRangeField as the
approaches are internally quite different.  It probably would be.  The
other factor is index size, and I think those new range fields would
generally be leaner.

~ David

On Fri, Nov 25, 2016 at 4:18 PM O. Klein  wrote:

> Thank you for your reply David.
>
> Yes, I ended up using a DateRangeField. Down side is that it needs frequent
> updates. Luckily not an issue for my use case.
>
> BTW how could I abuse DateRangeField for non-date data?
>
>
>
>
> david.w.smi...@gmail.com wrote
> > I just saw this conversation now.  I didn't read every word but I have to
> > ask immediately: does DateRangeField address your needs?
> > https://cwiki.apache.org/confluence/display/solr/Working+with+Dates  It
> > was
> > introduced in 5.0.
> >
> > On Wed, Nov 16, 2016 at 4:59 AM O. Klein 
>
> > klein@
>
> >  wrote:
> >
> >> Above implementation was too slow, so wondering if Solr 6 with all its
> >> new
> >> features provides a better solution to tackle operating hours.
> Especially
> >> dealing with different timezones.
> >>
> >> Any thoughts?
> >>
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4306073.html
> >> Sent from the Solr - User mailing list archive at Nabble.com.
> >>
> > --
> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > http://www.solrenterprisesearchserver.com
>
>
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4307463.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Search opening hours

[O. Klein]

Thank you for your reply David.

Yes, I ended up using a DateRangeField. Down side is that it needs frequent
updates. Luckily not an issue for my use case.

BTW how could I abuse DateRangeField for non-date data?




david.w.smi...@gmail.com wrote
> I just saw this conversation now.  I didn't read every word but I have to
> ask immediately: does DateRangeField address your needs?
> https://cwiki.apache.org/confluence/display/solr/Working+with+Dates  It
> was
> introduced in 5.0.
> 
> On Wed, Nov 16, 2016 at 4:59 AM O. Klein 

> klein@

>  wrote:
> 
>> Above implementation was too slow, so wondering if Solr 6 with all its
>> new
>> features provides a better solution to tackle operating hours. Especially
>> dealing with different timezones.
>>
>> Any thoughts?
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4306073.html
>> Sent from the Solr - User mailing list archive at Nabble.com.
>>
> -- 
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com





--
View this message in context: 
http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4307463.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Search opening hours

[David Smiley]

I just saw this conversation now.  I didn't read every word but I have to
ask immediately: does DateRangeField address your needs?
https://cwiki.apache.org/confluence/display/solr/Working+with+Dates  It was
introduced in 5.0.

On Wed, Nov 16, 2016 at 4:59 AM O. Klein  wrote:

> Above implementation was too slow, so wondering if Solr 6 with all its new
> features provides a better solution to tackle operating hours. Especially
> dealing with different timezones.
>
> Any thoughts?
>
>
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4306073.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Search opening hours

[O. Klein]

Above implementation was too slow, so wondering if Solr 6 with all its new
features provides a better solution to tackle operating hours. Especially
dealing with different timezones.

Any thoughts?





--
View this message in context: 
http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4306073.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Search opening hours

[O. Klein]

BTW any idea how index speed is influenced?

I used worldbounds with -1 and 1 y-axes. But figured this could also be 0.

After changing to 0 indexing became a lot slower though (no exceptions in
log).



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4227531.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Search opening hours

[Darren Spehr]

Sounds odd that the indexing times would change. Hopefully something else
was going on - I've not experienced this.

On Tue, Sep 8, 2015 at 4:31 AM, O. Klein  wrote:

> BTW any idea how index speed is influenced?
>
> I used worldbounds with -1 and 1 y-axes. But figured this could also be 0.
>
> After changing to 0 indexing became a lot slower though (no exceptions in
> log).
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4227531.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>



-- 
Darren

Re: Search opening hours

[O. Klein]

Doesn't sound odd to me. I just expected index time to be faster with smaller 
"world"

I used minutes as scale first, but that slows it even down a lot more. So
changed to 15 minute interval to keep it reasonable.

Maybe there is a setting that can speed this up. Like the precisionStep in a
Triefield?



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4227606.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Search opening hours

[O. Klein]

OK. Just wanted to see if it was possible for documentation.

I am using stateless script, so can fix it in client.

Thank you for the help.



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4227405.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Search opening hours

[Upayavira]

I can't answer it, but I wonder if searches related to the international
date line might help - that's where the equivalent issue is in spatial
terms.

Upayavira

On Sun, Sep 6, 2015, at 06:32 PM, O. Klein wrote:
> OK. I got most of it working.
> 
> I created a worldBounds="0 -1 762 1"
> 
> 15 minute intervals for a week.
> 
> And use "linestring(1 0, 2 0)" to index data for Monday 00:15 to 00:30
> 
> How do I get to index Sunday 24:00 to Monday 01:00 ?
> 
> I have a feeling the linestring just goes back and doesn't wrap around
> the
> plane.
> 
> 
> 
> 
> 
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4227374.html
> Sent from the Solr - User mailing list archive at Nabble.com.

Re: Search opening hours

[O. Klein]

Saw that, but not a lot of info about it.

>From my understanding, the way it supposed to work is that a value bigger
then boundary get's normalized.

I just get an exception "bad x not in boundary rect"

Any pointers?



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4227384.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Search opening hours

[Darren Spehr]

I think the client code has to normalize the input. There are methods in the 
spatial libraries that will do this - or maybe I wrote them my code, can't 
remember. How are you handling parsing the hours?

- Darren

> On Sep 6, 2015, at 4:56 PM, O. Klein  wrote:
> 
> Saw that, but not a lot of info about it.
> 
> From my understanding, the way it supposed to work is that a value bigger
> then boundary get's normalized.
> 
> I just get an exception "bad x not in boundary rect"
> 
> Any pointers?
> 
> 
> 
> --
> View this message in context: 
> http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4227384.html
> Sent from the Solr - User mailing list archive at Nabble.com.

Re: Search opening hours

[O. Klein]

OK. I got most of it working.

I created a worldBounds="0 -1 762 1"

15 minute intervals for a week.

And use "linestring(1 0, 2 0)" to index data for Monday 00:15 to 00:30

How do I get to index Sunday 24:00 to Monday 01:00 ?

I have a feeling the linestring just goes back and doesn't wrap around the
plane.





--
View this message in context: 
http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4227374.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Search opening hours

[O. Klein]

Darren,

So I created worldBounds="0 0 10080 0"

Didn't get polygons to work (needed at least 4 points that closed the
polygon), but I figured I only needed a line and check if a point was on
there. So I am using linestring now

Was wondering if this would work for Monday problem. Will the line be drawn
through the boundary and start at front again?






--
View this message in context: 
http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4227330.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Search opening hours

[Darren Spehr]

So thanks to the tireless efforts of David Smiley and the devs at Vivid
Solutions (not to mention the various contributors that help power Solr and
Lucene) spatial search is awesome, efficient and easy.  The biggest
roadblock I've run into is not having the JTS (Java Topology Suite) JAR
where Solr can find it. It doesn't ship with Solr OOB so you have to either
add it to one of the dynamic directories, or bundle it with the WAR (I
think pre-5.0). The link above has most of what you need to index data and
issue queries. I'd also suggest the sections on spatial search in Solr In
Action (Grainger, Potter) - they add a few more use cases that I've found
interesting. Finally, the aging wiki has some good info too:

http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4

Basically indexing spatial data is as easy as anything else: define the
field in the solrconfig.xml, create the data and push it in. Now the data
in this case are boxes or polygons (effectively the same here) and come in
a specific format known as WKT, or Well-Known-Text
https://en.wikipedia.org/wiki/Well-known_text. I'd say unless you're
aiming at an advanced use case set the max dist error on the field config a
little higher than normal - precision isn't really a requirement here and
good unit tests would alert you to any unforeseen issues. Then for the
query side of the world you just ask for point inclusion like:

q=+polygon:Contains(POINT(my_long my_lat))

Please note that WKT reverses the order of lat/lng because it uses
euclidean geometry heuristics (so X=longitude and Y=latitude). Can't tell
you how many times my brain hurt thanks to this idiom combined with janky
client logic :) Anyway, that's about it - let me know if you have any other
questions.


On Wed, Aug 26, 2015 at 1:56 PM, O. Klein kl...@octoweb.nl wrote:

 Darren,

 This sounds like solution I'm looking for. Especially nice fix for the
 Sunday-Monday problem.

 Never worked with spatial search before, so any pointers are welcome.

 Will start working on this solution.



 --
 View this message in context:
 http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4225443.html
 Sent from the Solr - User mailing list archive at Nabble.com.




-- 
Darren

Re: Search opening hours

[O. Klein]

Darren,

This sounds like solution I'm looking for. Especially nice fix for the
Sunday-Monday problem.

Never worked with spatial search before, so any pointers are welcome. 

Will start working on this solution.



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4225443.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Search opening hours

[Darren Spehr]

Sorry - didn't finish my thought. I need to address querying :) So using
the above to define what's in the index your queries for a day/time become
a CONTAINS operation against the field. Let's say that the field is defined
as a location_rpt using JTS and its Spatial Factory (which supports
polygons) - oh, and it would need to be multi-valued. Querying the field
would require first translating now or in an hour or Monday at 9am to
a geocode, then hitting the index with a CONTAINS request per the docs:

https://cwiki.apache.org/confluence/display/solr/Spatial+Search


On Wed, Aug 26, 2015 at 11:23 AM, Darren Spehr darre...@gmail.com wrote:

 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




-- 
Darren

Re: Search opening hours

[Stefan Matheis]

Have a look at the links that Alexandre mentioned. a somewhat non-obvious style 
solution because you'd probably not think about spatial features while dealing 
with opening time - but it's worth having a look. 

-Stefan 


On Wednesday, August 26, 2015 at 10:16 AM, O. Klein wrote:

 Thank you for responding.
 
 Yonik's solution is what I had in mind. Was hoping for something more
 elegant, as he said, but it will work.
 
 The thing I haven't figured out is how to deal with closing times early
 morning next day.
 
 So it's 22:00 now and opening hours are 20:00 to 03:00
 
 Can this be done with either or both approaches?
 
 
 
 
 
 --
 View this message in context: 
 http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4225339.html
 Sent from the Solr - User mailing list archive at Nabble.com 
 (http://Nabble.com).
 
 

Re: Search opening hours

[Upayavira]

On Tue, Aug 25, 2015, at 10:54 PM, Yonik Seeley wrote:
 On Tue, Aug 25, 2015 at 5:02 PM, O. Klein kl...@octoweb.nl wrote:
  I'm trying to find the best way to search for stores that are open NOW.
 
 It's probably not the *best* way, but assuming it's currently 4:10pm,
 you could do
 
 +open:[* TO 1610] +close:[1610 TO *]
 
 And to account for days of the week have different fields for each day
 openM, closeM, openT, closeT, etc...  not super elegant, but seems to
 get the job done.

So, the basic question is what does now mean? If it is 5:29pm and a
shop closes at 5:30pm, does that count as open? If you want to query
a single time within a range, then Yonik's approach will work
(although I'd use open0 to open6 for the days of the week).

If you want to find a range within another range, then use what
Alexandre suggested - spatial search functionality. For example, you
could say, is the shop open for 10 minutes either side of now. Of
course, you could use spatial for a time within a range, and it might be
a little more elegant because you can use a multivalued field to specify
the open/close ranges for your store.

Upayavira

Re: Search opening hours

[O. Klein]

Thank you for responding.

Yonik's solution is what I had in mind. Was hoping for something more
elegant, as he said, but it will work.

The thing I haven't figured out is how to deal with closing times early
morning next day.

So it's 22:00 now and opening hours are 20:00 to 03:00

Can this be done with either or both approaches?





--
View this message in context: 
http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4225339.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Search opening hours

[O. Klein]

Those options don't fix my problem with closing times the next morning, or is
there a way to do this?



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250p4225354.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Search opening hours

[Upayavira]

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

Re: Search opening hours

[Upayavira]

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

Re: Search opening hours

[Upayavira]

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

Re: Search opening hours

[Darren Spehr]

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

Re: Search opening hours

[Darren Spehr]

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

Re: Search opening hours

[Yonik Seeley]

On Tue, Aug 25, 2015 at 5:02 PM, O. Klein kl...@octoweb.nl wrote:
 I'm trying to find the best way to search for stores that are open NOW.

It's probably not the *best* way, but assuming it's currently 4:10pm,
you could do

+open:[* TO 1610] +close:[1610 TO *]

And to account for days of the week have different fields for each day
openM, closeM, openT, closeT, etc...  not super elegant, but seems to
get the job done.

-Yonik

Re: Search opening hours

[Alexandre Rafalovitch]

Have you seen:
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201212.mbox/%3c1354991310424-4025359.p...@n3.nabble.com%3E
https://wiki.apache.org/solr/SpatialForTimeDurations
https://people.apache.org/~hossman/spatial-for-non-spatial-meetup-20130117/

Regards,
   Alex.

Solr Analyzers, Tokenizers, Filters, URPs and even a newsletter:
http://www.solr-start.com/


On 25 August 2015 at 17:02, O. Klein kl...@octoweb.nl wrote:
 I'm trying to find the best way to search for stores that are open NOW.

 I have day of week, open and closing times.

 I've seen some examples, but not an exact fit.

 What is the best way to tackle this?

 Thank you for any suggestions you have to offer.








 --
 View this message in context: 
 http://lucene.472066.n3.nabble.com/Search-opening-hours-tp4225250.html
 Sent from the Solr - User mailing list archive at Nabble.com.