[
https://issues.apache.org/jira/browse/LUCENE-4978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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=759h=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=759h=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
