[ 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org