[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16452216#comment-16452216
]
Ignacio Vera edited comment on LUCENE-8276 at 4/25/18 1:08 PM:
---------------------------------------------------------------
Yes, I added that because the test with the antipode failed with a problem when
creating a plane. Because in the polygon factory we have the following:
{code:java}
public GeoComplexPolygon createGeoComplexPolygon(final PlanetModel planetModel,
final List<List<GeoPoint>> pointsList, final GeoPoint testPoint) {
// Is it inside or outside?
final Boolean isTestPointInside = isInsidePolygon(testPoint, points);
if (isTestPointInside != null) {
// Legal pole
if (isTestPointInside == poleMustBeInside) {
return new GeoComplexPolygon(planetModel, pointsList, testPoint,
isTestPointInside);
} else {
return new GeoComplexPolygon(planetModel, pointsList, new
GeoPoint(-testPoint.x, -testPoint.y, -testPoint.z), !isTestPointInside);
}
}
// If pole choice was illegal, try another one
return null;
}
{code}
I though it was a valid assumption. I have a look if I can handle that case in
a more robust way.
was (Author: ivera):
Yes, I added that the last bit because the test with the atipole failed with a
problem when creating a plane. Because in the polygon factory we have the
following:
{code:java}
public GeoComplexPolygon createGeoComplexPolygon(final PlanetModel planetModel,
final List<List<GeoPoint>> pointsList, final GeoPoint testPoint) {
// Is it inside or outside?
final Boolean isTestPointInside = isInsidePolygon(testPoint, points);
if (isTestPointInside != null) {
// Legal pole
if (isTestPointInside == poleMustBeInside) {
return new GeoComplexPolygon(planetModel, pointsList, testPoint,
isTestPointInside);
} else {
return new GeoComplexPolygon(planetModel, pointsList, new
GeoPoint(-testPoint.x, -testPoint.y, -testPoint.z), !isTestPointInside);
}
}
// If pole choice was illegal, try another one
return null;
}
{code}
I though it was a valid assumption. I have a look if I can handle that case in
a more robust way.
> 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: [email protected]
For additional commands, e-mail: [email protected]
