[
https://issues.apache.org/jira/browse/SOLR-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114839#comment-13114839
]
geert-jan brits commented on SOLR-2155:
---------------------------------------
David,
I try not to swamp this discussion, but I have a totally different issue for
which I might misuse this patch / LSP.
It's about pois having multiple openinghours (depending on day of week, special
festivitydays, and sometimes even multiple timeslots per day)
I want to query, for example, all pois that are open NOW, and that will remain
open until NOW+3H.
For background see:
http://lucene.472066.n3.nabble.com/multiple-dateranges-timeslots-per-doc-modeling-openinghours-td3368790.html
on why all normal approaches don't work (afaik): basically it's about needing
multiple opening/closing times and having them be pairwise related.
I have the feeling that opening/closing datetimes might be modelled as multiple
lat/long points. But I would need a query of the form:
Given a user defined point x, return all docs that have a point p defined for
which:
- x.latitude > p.latitude
- x.longitude < p.longitude
Is this possible? (As far as I see GeoFilt, BBox, GeoDist don't provide me with
what I need)
Basically this is how I envision encoding it:
- each <open,closedelta)>-tuple is represented as a (lat/long)point
- open is matched on latitude
- closedelta (closedelta is represented as delta from open) is matched on
longitude
- granularity is 5 minutes
- open can be a max of 100 days in future -> ~30.000 distinct values.
- closedelta can be at most 24 hours -> ~300 distinct values
The above lat/long query applied to the domain would become:
Given a user defined open/closedelta-datetime x, return all docs that have a
open/close-datetime p defined for which:
- x.open > p.open (poi is already open at requested opening time)
- x.closedelta < p.closedelta (poi is not yet closed on the requested closing
time)
In other words, the poi is open from the requested open-datetime until at least
the requested close-datetime.
Ok, good exercise in writing this down, the question remains is this query
possible (perhaps with some coding-efforts)?
Thanks,
Geert-Jan
> Geospatial search using geohash prefixes
> ----------------------------------------
>
> Key: SOLR-2155
> URL: https://issues.apache.org/jira/browse/SOLR-2155
> Project: Solr
> Issue Type: Improvement
> Reporter: David Smiley
> Assignee: Grant Ingersoll
> Attachments: GeoHashPrefixFilter.patch, GeoHashPrefixFilter.patch,
> GeoHashPrefixFilter.patch,
> SOLR-2155_GeoHashPrefixFilter_with_sorting_no_poly.patch, SOLR.2155.p3.patch,
> SOLR.2155.p3tests.patch
>
>
> There currently isn't a solution in Solr for doing geospatial filtering on
> documents that have a variable number of points. This scenario occurs when
> there is location extraction (i.e. via a "gazateer") occurring on free text.
> None, one, or many geospatial locations might be extracted from any given
> document and users want to limit their search results to those occurring in a
> user-specified area.
> I've implemented this by furthering the GeoHash based work in Lucene/Solr
> with a geohash prefix based filter. A geohash refers to a lat-lon box on the
> earth. Each successive character added further subdivides the box into a 4x8
> (or 8x4 depending on the even/odd length of the geohash) grid. The first
> step in this scheme is figuring out which geohash grid squares cover the
> user's search query. I've added various extra methods to GeoHashUtils (and
> added tests) to assist in this purpose. The next step is an actual Lucene
> Filter, GeoHashPrefixFilter, that uses these geohash prefixes in
> TermsEnum.seek() to skip to relevant grid squares in the index. Once a
> matching geohash grid is found, the points therein are compared against the
> user's query to see if it matches. I created an abstraction GeoShape
> extended by subclasses named PointDistance... and CartesianBox.... to support
> different queried shapes so that the filter need not care about these details.
> This work was presented at LuceneRevolution in Boston on October 8th.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
