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
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
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
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-tp4225
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
Triefi
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.
>
> Aft
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-tp422
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 arc
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
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-o
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 minu
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
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
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
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
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
polygon
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
(wh
"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?
>
> Upay
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 minim
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
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 th
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.
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
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 don
On Tue, Aug 25, 2015, at 10:54 PM, Yonik Seeley wrote:
> On Tue, Aug 25, 2015 at 5:02 PM, O. Klein 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] +
On Tue, Aug 25, 2015 at 5:02 PM, O. Klein 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 f
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
27 matches
Mail list logo
