[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707618#comment-14707618
]
Karl Wright commented on LUCENE-6699:
-------------------------------------
This is the "accept" that is confirming that the shape contains the point:
{code}
@Override
public boolean accept(int docID) {
//System.out.println(" accept?
docID=" + docID);
BytesRef bytes = treeDV.get(docID);
if (bytes == null) {
//System.out.println(" false
(null)");
return false;
}
assert bytes.length == 12;
double x =
Geo3DDocValuesFormat.decodeValue(Geo3DDocValuesFormat.readInt(bytes.bytes,
bytes.offset));
double y =
Geo3DDocValuesFormat.decodeValue(Geo3DDocValuesFormat.readInt(bytes.bytes,
bytes.offset+4));
double z =
Geo3DDocValuesFormat.decodeValue(Geo3DDocValuesFormat.readInt(bytes.bytes,
bytes.offset+8));
// True if x,y,z is within shape
//System.out.println(" x=" + x
+ " y=" + y + " z=" + z);
//System.out.println(" ret: " +
shape.isWithin(x, y, z));
return shape.isWithin(x, y, z);
}
{code}
The "accept" is apparently returning false when you evaluated the point earlier
to be within the XYZ bounds of ... well, what exactly? What was the actual bit
of information in this case from geo3d that is wrong? Also remember that the
point is not exact, because there is imprecision at a level greater than
MINIMUM_RESOLUTION, so that it may well be inside the GeoArea but *not* inside
the actual shape, due to rounding issues. We should figure out a way to
determine if that is in fact what is happening.
> Integrate lat/lon BKD and spatial3d
> -----------------------------------
>
> Key: LUCENE-6699
> URL: https://issues.apache.org/jira/browse/LUCENE-6699
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Attachments: Geo3DPacking.java, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch,
> LUCENE-6699.patch, LUCENE-6699.patch, LUCENE-6699.patch
>
>
> I'm opening this for discussion, because I'm not yet sure how to do
> this integration, because of my ignorance about spatial in general and
> spatial3d in particular :)
> Our BKD tree impl is very fast at doing lat/lon shape intersection
> (bbox, polygon, soon distance: LUCENE-6698) against previously indexed
> points.
> I think to integrate with spatial3d, we would first need to record
> lat/lon/z into doc values. Somewhere I saw discussion about how we
> could stuff all 3 into a single long value with acceptable precision
> loss? Or, we could use BinaryDocValues? We need all 3 dims available
> to do the fast per-hit query time filtering.
> But, second: what do we index into the BKD tree? Can we "just" index
> earth surface lat/lon, and then at query time is spatial3d able to
> give me an enclosing "surface lat/lon" bbox for a 3d shape? Or
> ... must we index all 3 dimensions into the BKD tree (seems like this
> could be somewhat wasteful)?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
