[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453302#comment-16453302
]
Karl Wright commented on LUCENE-8276:
-------------------------------------
[~ivera], a 180-degree version of DualCrossingEdgeIterator is very challenging
to write, because it's not clear at all how we bound the envelope planes in
that case. If you allow one leg to travel a full 180 degrees, then since one
of the envelope planes for the second leg is "beyond" 180 degrees, the cutoffs
for the 180-degree leg cannot be described by a single plane.
All of this is to avoid traveling a very short distance near the pole.
I maybe have a better idea. Suppose instead of one test point for each
GeoComplexPolygon, we have TWO. We pick the second one to be the antipodes of
the first. We compute whether it is within or not using the current techniques
we have for computing crossings, but since it is on the opposite sides of the
world, we know we can reach it without violating any travel restrictions. Once
we have the second test point, we can choose which test point we'll use based
on travel plane geometry, so that we don't have problems with any of the travel
plane geometries.
> GeoComplexPolygon failures
> --------------------------
>
> Key: LUCENE-8276
> URL: https://issues.apache.org/jira/browse/LUCENE-8276
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
> Reporter: Ignacio Vera
> Assignee: Ignacio Vera
> Priority: Major
> Attachments: LUCENE-XXXX-test.patch, LUCENE-XXXX.patch,
> LUCENE_XXXX_random.patch
>
>
> I have tightened a bit more the random test for polygons and
> GeoComplexPolygons still shows issues when traveling planes that are cutting
> the world near the pole. I could identify three cases:
>
> case 1) It happens when the check point is on aone of the test point planes
> but the planes is close to the pole and cannot be traversed. In that case we
> hit the following part of the code:
> {code:java}
> } else if (testPointFixedYPlane.evaluateIsZero(x, y, z) ||
> testPointFixedXPlane.evaluateIsZero(x, y, z) ||
> testPointFixedZPlane.evaluateIsZero(x, y, z)) {
> throw new IllegalArgumentException("Can't compute isWithin for specified
> point");
> } else {{code}
>
> It seems this check is unnecesary. If removed then a traversal is choosen and
> evrything works as expected.
>
> case 2) In this case a {{DualCrossingEdgeIterator}} is used with one of the
> planes being close to the pole but inside current restricutions (is a valid
> traversal). I think the problem happens when computing the intersection
> points for above and below plane in {{computeInsideOutside}}:
> {code:java}
> final GeoPoint[] outsideOutsidePoints =
> testPointOutsidePlane.findIntersections(planetModel, travelOutsidePlane);
> //these don't add anything: , checkPointCutoffPlane, testPointCutoffPlane);
> final GeoPoint outsideOutsidePoint =
> pickProximate(outsideOutsidePoints);{code}
> The intersection above results in two points close to each other and close to
> the intersection point, and therefore {{pickProximate}} fails in choosing the
> right one.
> case 3) In this case a {{LinearCrossingEdgeIterator}} is used with the plane
> being close to the pole. In this case when evaluating the intersection
> between an edge and the plane, we get two intersections (because are very
> close together) inside the bounds instead of one. The result is too many
> crossings.
>
> After evaluating this errors I think we should really prevent using planes
> that are near a pole. I attached a new version of {{GeoComplexPolygon}} that
> seems to solve this issues. The approach is the following:
> {{NEAR_EDGE_CUTOFF}} is not expressed as a linear distance but as a
> percentage, curerntly 0.75 . If ab is the value of a semiaxis, the logic
> disallows to travel a plane if the distance between the plane and the center
> of the world is bigger that {{NEAR_EDGE_CUTOFF}} * pole.
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
