[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16454013#comment-16454013
]
Karl Wright commented on LUCENE-8276:
-
Ok, that's been committed. The unrelated failure still occurs, however, so I
will create a separate ticket for that and close this one.
> 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
> Fix For: 6.7, 7.4, master (8.0)
>
> Attachments: LUCENE-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453971#comment-16453971
]
ASF subversion and git services commented on LUCENE-8276:
-
Commit f367f3f08e627bfa58d0d3dd80fc211262b89e1b in lucene-solr's branch
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f367f3f ]
LUCENE-8276: Don't allow travel near a pole; require a different choice of
travel plane
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453970#comment-16453970
]
ASF subversion and git services commented on LUCENE-8276:
-
Commit d8aa4afd4a4e2770965f82e899d3310ded2fe6ff in lucene-solr's branch
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=d8aa4af ]
LUCENE-8276: Don't allow travel near a pole; require a different choice of
travel plane
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453968#comment-16453968
]
ASF subversion and git services commented on LUCENE-8276:
-
Commit 9f506635e007ee53498f00e49f67669b099f0506 in lucene-solr's branch
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9f50663 ]
LUCENE-8276: Don't allow travel near a pole; require a different choice of
travel plane
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453932#comment-16453932
]
Karl Wright commented on LUCENE-8276:
-
[~ivera], NEAR_EDGE_CUTOFF that large is crazy large. When I set it to
something reasonable, like -MINIMUM_RESOLUTION * 1000.0, I don't get any
failures.
I will commit that change at least.
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453898#comment-16453898
]
Ignacio Vera commented on LUCENE-8276:
--
Not sure, I think it is showing the same issues. You can check one thing, if
you set the fololwing:
{code:java}
private final static double NEAR_EDGE_CUTOFF = -0.2;{code}
You see that the failing test works and the failure of the other random test is
gone as well. On the other hand there is another failure in test
{{testPolygonFailureCase2}} because the intersection point is on one edge.
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453874#comment-16453874
]
Karl Wright commented on LUCENE-8276:
-
[~ivera] I've committed the tests. The only one that is failing is _case3 at
this time -- it is annotated with "@AwaitsFix". I'll work to resolve that --
but while I was checking that out, a different random test failed.
Reproduction command here:
{code}
ant test -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations
-Dtests.seed=1F49469C1989BC0 -Dtests.slow=true -Dtests.badapples=true -
Dtests.locale=fr-BE -Dtests.timezone=Europe/Malta -Dtests.asserts=true
-Dtests.file.encoding=Cp1252
{code}
I think we likely should have a new ticket for that failure, since it appears
unrelated to the work we've been doing for this ticket.
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453868#comment-16453868
]
ASF subversion and git services commented on LUCENE-8276:
-
Commit ea0edc27df6b5fde226b5ffc797d0316f5ea3c66 in lucene-solr's branch
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ea0edc2 ]
LUCENE-8276: Add new tests which demonstrate the issue. Only one is now
failing.
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453865#comment-16453865
]
ASF subversion and git services commented on LUCENE-8276:
-
Commit e75b968a721442175f5f1195e7c1408ee0760621 in lucene-solr's branch
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e75b968 ]
LUCENE-8276: Add new tests which demonstrate the issue. Only one is now
failing.
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453864#comment-16453864
]
ASF subversion and git services commented on LUCENE-8276:
-
Commit 8e029816cf82b4523c047e04818d16dc940aa72f in lucene-solr's branch
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8e02981 ]
LUCENE-8276: Add new tests which demonstrate the issue. Only one is now
failing.
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453790#comment-16453790
]
Ignacio Vera commented on LUCENE-8276:
--
I did the changes and got a different error. Now in one of the existing tests
the intersection point is on top of one polygon edge and it fails.
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453787#comment-16453787
]
ASF subversion and git services commented on LUCENE-8276:
-
Commit 2265ec1947bb52f7cbb3c3f5c05df66c3e7afa80 in lucene-solr's branch
refs/heads/master from [~simonw]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2265ec1 ]
LUCENE-8276: Remove unused imports
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453597#comment-16453597
]
Karl Wright commented on LUCENE-8276:
-
[~ivera] I have committed the restructuring, but not any of your patches, so
far.
The basic idea now is:
(1) There are two test points.
(2) isWithin() tries the first one initially. If it gets an
IllegalArgumentException, it tries the second one.
I have made no changes to the logic for deciding which travel legs to use; I am
expecting you to add that.
Also, I've removed DualCrossingEdgeIterator entirely, in favor of just using
the linear edge iterators repeatedly. So we now find whether the intersection
point is in-set first, and then we find whether the check point is in set
second. This allows travel of a full 180 degrees, so you can reach the
antipodes now.
I still would like to do some optimizations in the remaining edge iterators,
but that should not collide with anything you want to do to address the
strategy of choosing travel planes. I would also hope you can commit your test
changes that exercise the particular cases that were a problem before, if they
pass.
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453589#comment-16453589
]
ASF subversion and git services commented on LUCENE-8276:
-
Commit f6378894e8fd43f39d44db29c5dca21c52ffe7cf in lucene-solr's branch
refs/heads/branch_6x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f637889 ]
LUCENE-8276: Restructure complex polygon class yet again to allow dual test
points.
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453587#comment-16453587
]
ASF subversion and git services commented on LUCENE-8276:
-
Commit 0d1b4f26706c0b81acd90827d21be174d21ccfda in lucene-solr's branch
refs/heads/branch_7x from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0d1b4f2 ]
LUCENE-8276: Restructure complex polygon class yet again to allow dual test
points.
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453586#comment-16453586
]
ASF subversion and git services commented on LUCENE-8276:
-
Commit 15a6b586c79c19177894aae23e63fd1493710c5e in lucene-solr's branch
refs/heads/master from [~kwri...@metacarta.com]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=15a6b58 ]
LUCENE-8276: Restructure complex polygon class yet again to allow dual test
points.
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453543#comment-16453543
]
Ignacio Vera commented on LUCENE-8276:
--
I have updated the patches with proper numbering and added checks for corner
cases on the random test .
Your proposal makes lot of sense, we need to increment our travel choices.
> 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-8276-random.patch, LUCENE-8276-test.patch,
> LUCENE-8276.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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16453498#comment-16453498
]
Karl Wright commented on LUCENE-8276:
-
[~ivera] I propose restructuring the class along the lines above. This will
take me a while. Then you can add your specific algorithms for selecting an
appropriate choice of test point and travel/testpoint planes.
> 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--test.patch, LUCENE-.patch,
> LUCENE__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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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--test.patch, LUCENE-.patch,
> LUCENE__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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452540#comment-16452540
]
Karl Wright commented on LUCENE-8276:
-
If you think you need two new variants of DualCrossingEdgeIterator, I can write
those, but I'm swamped as usual, so it will have to wait until the weekend, I'm
afraid.
> 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--test.patch, LUCENE-.patch,
> LUCENE__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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452442#comment-16452442
]
Ignacio Vera commented on LUCENE-8276:
--
I think you have no options in the following corner case:
Test point is near to the positive X pole so the {{testPointFixedXPlane}}
cannot be traveled.
Check point is near to the negative X pole so the {{travelPlaneFixedX}} cannot
be traveled.
Then you only have two options:
a) travel in the XZ plane then XY
b) travel in the XY plane then XZ
In any of those two cases you have a leg that is 180 degrees.
> 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--test.patch, LUCENE-.patch,
> LUCENE__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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452395#comment-16452395
]
Karl Wright commented on LUCENE-8276:
-
[~ivera], there is always another choice you could make that would prevent any
dual iterator leg from being = 180 degrees. By definition, it is always
possible to find a shorter path.
> 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--test.patch, LUCENE-.patch,
> LUCENE__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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452358#comment-16452358
]
Ignacio Vera commented on LUCENE-8276:
--
I undestand now. This case would fall in case 1 explained above. The problem
here is that we have a Dual iterator with a leg of 180 degrees.
> 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--test.patch, LUCENE-.patch,
> LUCENE__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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452220#comment-16452220
]
Karl Wright commented on LUCENE-8276:
-
[~ivera], since we basically need to draw a path from the test point to the
check point, we can short-circuit the path by noticing that the check point and
the test point are the same. But that says nothing at all about the antipodes
of the test point. We do not know if that point is in set or out of set. This
is very different from the assumptions about poles made in GeoPolygonFactory.
If you are having trouble building a traversal plane, it means that you have
chosen the wrong kind of iterator to construct. There are three kinds:
SectorLinear (which is < 180 degrees), FullLinear (180 degrees), and Dual
(where each leg is < 180 degrees).
> 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--test.patch, LUCENE-.patch,
> LUCENE__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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452216#comment-16452216
]
Ignacio Vera commented on LUCENE-8276:
--
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 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--test.patch, LUCENE-.patch,
> LUCENE__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
[jira] [Commented] (LUCENE-8276) GeoComplexPolygon failures
[
https://issues.apache.org/jira/browse/LUCENE-8276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16452191#comment-16452191
]
Karl Wright commented on LUCENE-8276:
-
[~ivera], everything looked plausible except for this:
{code}
// If we're right on top of the point, we know the answer.
if (testPoint.isNumericallyIdentical(x, y, z)) {
return testPointInSet;
+} else if (testPoint.isNumericallyIdentical(-x, -y, -z)) {
+ return !testPointInSet;
}
{code}
I don't think you can make this assumption.
> 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
>Priority: Major
> Attachments: LUCENE--test.patch, LUCENE-.patch,
> LUCENE__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
