[ https://issues.apache.org/jira/browse/LUCENE-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13799375#comment-13799375 ]
oli mcc edited comment on LUCENE-4978 at 10/18/13 6:30 PM: ----------------------------------------------------------- Hi David, Sorry for the delay in following up, I've actually been spending some time familiarizing myself with the code and have some followup thoughts/questions. I think I get the issue now; the optimization short circuits to using the centre (a cheaper relation verification) in some cases, and as a result, the following two query types (a point and polygon) would not match due to no intersection with the centre. !https://docs.google.com/drawings/d/1iEX4D7PXQHq3mJvSII-Y0Y5MHPKSGOkqjUV6UcIecY4/pub?w=759&h=353! - It's not clear to me why the quick fix doesn't work in both cases you described however, maybe I'm missing the underlying problem. If we _always_ use cell.getShape() won't we be guaranteed to match all points in the cell (potentially inefficient and with false positives, but not false negatives)? - I think this is purely a query time issue, would that be right? I'd like to start indexing documents now, but will avoid doing so if a fix to this will require a re-index. To hopefully answer your question, Elasticsearch does have a specific mapping type for geo points ([GeoPointFieldMapper.java|https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/index/mapper/geo/GeoPointFieldMapper.java] which I think follows the pattern you described. was (Author: olimcc): Hi David, Sorry for the delay in following up, I've actually been spending some time familiarizing myself with the code and have some followup thoughts/questions. I think I get the issue now; the optimization short circuits to using the centre (a cheaper relation verification) in some cases, and as a result, the following two query types (a point and polygon) would not match due to no intersection with the centre. !https://docs.google.com/drawings/d/1iEX4D7PXQHq3mJvSII-Y0Y5MHPKSGOkqjUV6UcIecY4/pub?w=759&h=353! - It's not clear to me why the quick fix doesn't work in both cases you described however, maybe I'm missing the underlying problem. If we _always_ use cell.getShape() won't we be guaranteed to match all points in the cell (potentially inefficient and with false positives, but not false negatives)? - I think this is purely a query time issue, would that be right? I'd like to start indexing documents now, but will avoid doing so if a fix to this will require a re-index. To answer your question, Elasticsearch does have a specific mapping type for geo points ([GeoPointFieldMapper.java|https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/index/mapper/geo/GeoPointFieldMapper.java] which I think follows the pattern you described. > Spatial search with point query won't find identical indexed point > ------------------------------------------------------------------ > > Key: LUCENE-4978 > URL: https://issues.apache.org/jira/browse/LUCENE-4978 > Project: Lucene - Core > Issue Type: Bug > Components: modules/spatial > Affects Versions: 4.1 > Reporter: David Smiley > Assignee: David Smiley > Priority: Minor > Fix For: 4.6 > > > Given a document with indexed POINT (10 20), when a search for INTERSECTS( > POINT (10 20)) is issued, no results are returned. > The work-around is to not search with a point shape, use a very small-radius > circle or rectangle. (I'm marking this issue as "minor" because it's easy to > do this). > An unstated objective of the PrefixTree/grid approximation is that no matter > what precision you use, an intersects query will find all true-positives. > Due to approximations, it may also find some close false-positives. But in > the case above, that unstated promise is violated. But it can also happen > for query shapes other than points which do in fact barely enclose the point > given at index time yet the indexed point is in-effect shifted to the center > point of a cell which could be outside the query shape, and ultimately > leading to a false-negative. -- This message was sent by Atlassian JIRA (v6.1#6144) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org