[
https://issues.apache.org/jira/browse/LUCENE-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707734#comment-14707734
]
Karl Wright commented on LUCENE-6699:
-------------------------------------
Ok, I wrote this test code to reproduce the problem simply:
{code}
// Sixth BKD discovered failure
p1 = new
GeoPoint(1.0010893045436076,0.007380935180644008,-0.002140671370616495);
c = new
GeoCircle(PlanetModel.WGS84,-0.006450320645814321,0.004660694205115142,0.00489710732634323);
//xyzb = new XYZBounds();
//c.getBounds(xyzb);
//System.err.println("xmin="+xyzb.getMinimumX()+",
xmax="+xyzb.getMaximumX()+",ymin="+xyzb.getMinimumY()+",
ymax="+xyzb.getMaximumY()+",zmin="+xyzb.getMinimumZ()+",
zmax="+xyzb.getMaximumZ());
//xmin=1.0010356621420726,
xmax=1.0011141249179447,ymin=-2.5326643901354566E-4,
ymax=0.009584741915757169,zmin=-0.011359874956269283,
zmax=-0.0015549504447452225
area =
GeoAreaFactory.makeGeoArea(PlanetModel.WGS84,1.0010822580620098,1.0010945779732867,0.007079167343247293,0.007541006774427837,-0.0021855011220022575,-0.001896122718181518);
assertTrue(!c.isWithin(p1));
assertTrue(GeoArea.CONTAINS == area.getRelationship(c));
assertTrue(PlanetModel.WGS84.pointOnSurface(p1)); // This fails
assertTrue(!area.isWithin(p1)); // This fails
{code}
Note that the bounds for the GeoCircle are in fact outside the XYZsolid that
you are searching. So CONTAINS is not unreasonable. (I'll make certain of
this shortly). Also note that the point being considered is not technically on
the surface, as we discussed. This has definite effects on the math. Any
GeoArea is defined as being the intersection of the shape with the planet
surface, so the behavior of points off that surface are outside the formal
geo3d contract. Since xyzsolid has a lot of space that *isn't* on the surface,
it's pretty likely that the point in question is off the surface in a way that
allows it to fit inside the xyzsolid but is too far inside to be on the correct
side of the circle plane. When I confirm that the XYZSolid really is within
the GeoCircle, by the terms of the GeoArea contract, then we'll know that that
is what is going on.
Off-surface (x,y,z) values are not fatal but it is something we have to
consider carefully and explicitly compensate for. The simplest way is to
return them, even though they technically fail shape membership, which I think
is what your code does with the asserts.
Stay tuned.
> 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, 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: [email protected]
For additional commands, e-mail: [email protected]
