GeoComplexPolygon fails when intersection of travel plane with edge is near polygon point [LUCENE-8245]

[mikemccand]

When a travel plane crosses an edge close to an edge point , it is possible that the above and below planes crosses different edges. In the current implementation one of the crosses is missed because we only check edges that are crossed by the main plain and the within result is wrong.

One possible fix is to check always the intersection of planes and edges regardless if they are crossed by main plane. That fixed the above issue but shows other issues like travel planes crossing two edges when it should be only one due to the fuzziness at edge intersections.

Not sure of a fix so I add the test showing the issue.

---

Legacy Jira details

LUCENE-8245 by Ignacio Vera (@iverase) on Apr 08 2018, resolved Apr 12 2018 Attachments: LUCENE-8245_case3.patch, LUCENE-8245_Polygon.patch, LUCENE-8245_Random.patch, LUCENE-8245.jpg, LUCENE-8245.patch (versions: 2), LUCENE-8245-case2.patch

[mikemccand]

The logic for crossing near polygon edges has been very carefully thought out, and the major commit made last weekend was designed to resolve those kinds of issues once and for all. The comments in the code describe the algorithm, but basically we are only interested in edges that actually intersect or cross the travel planes. The reason for above/below planes is to be able to accurately count links even when some polygon edges are wholly or in part contained within the envelope.

So it is immaterial that an edge crosses only one or the other envelope planes; that is the whole point of having the envelope planes, in fact. But we do assume that the envelope is narrow enough that an edge that ends inside of it must intersect either the travel plane or the above/below planes; that assumption may be incorrect.

I will not be able to analyze these cases until later today.

[Legacy Jira: Karl Wright on Apr 08 2018]

[mikemccand]

Commit 348de9e8b59d1ba6cf37999fe4c11c8365147fdd in lucene-solr's branch refs/heads/master from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=348de9e

LUCENE-8245: Adjust envelope to not leave as big a gap between travel planes and above/below planes.

[Legacy Jira: ASF subversion and git services on Apr 08 2018]

[mikemccand]

Commit aaddf2ee4267dea3b54990dfeb826a2392dc6fec in lucene-solr's branch refs/heads/branch_7x from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=aaddf2e

LUCENE-8245: Adjust envelope to not leave as big a gap between travel planes and above/below planes.

[Legacy Jira: ASF subversion and git services on Apr 08 2018]

[mikemccand]

Commit 7690e010dfbbdda448a6d562d99e574cdb8b8d46 in lucene-solr's branch refs/heads/branch_6x from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=7690e01

LUCENE-8245: Adjust envelope to not leave as big a gap between travel planes and above/below planes.

[Legacy Jira: ASF subversion and git services on Apr 08 2018]

[mikemccand]

Adjusted the delta between travel planes and above/below planes to make it as small as possible.

[Legacy Jira: Karl Wright on Apr 08 2018]

[mikemccand]

I can still reproduce the issue with other cases. I attach another test.

 

[Legacy Jira: Ignacio Vera (@iverase) on Apr 09 2018]

[mikemccand]

This example has the opposite cause; instead of an edge crossing a bounding plane but not being detected as crossing the main plane, something different is happening. The reason I needed to broaden the envelope in the first place beyond 1e-12 was because of numerical precision issues: sometimes we are detecting that we're crossing both bounding planes when we really are crossing just one, because of the precision of how we compute the intersection point.

I'll have to analyze this case numerically to see if there is a solution to how we calculate this stuff. No chance of having time to look at it until midweek or later.

[Legacy Jira: Karl Wright on Apr 09 2018]

[mikemccand]

Turned on diagnostic output for this case. Here it is:

   [junit4]   1> Considering edge [lat=-0.6183600459696781, lon=-2.770488856855538([X=-0.7593628058597481, Y=-0.29549354861758625, Z=-0.5796996565482825])] -> [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342,
Y=-0.11274773940940182, Z=-0.9927936672533157])]
   [junit4]   1>
   [junit4]   1> The following edges should intersect the travel/testpoint planes:
   [junit4]   1> Travel plane: [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
   [junit4]   1> Test point plane: [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
   [junit4]   1> Travel plane: [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])] -> [lat=0.13953211802880663, lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361, Z=0.139079795174987])]
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
   [junit4]   1>
   [junit4]   1> The following edges should intersect the travel/testpoint planes:
   [junit4]   1> Travel plane: [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
   [junit4]   1> Test point plane: [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
   [junit4]   1> Travel plane: [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])] -> [lat=0.13953211802880663, lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361, Z=0.139079795174987])]
   [junit4]   1>
   [junit4]   1>   Travel inner point [X=1.0, Y=-1.336807223683658E-12, Z=-1.1771178322187736E-11]
   [junit4]   1>   Test point inner point [X=0.7540698997149413, Y=-0.07411317803504912, Z=-0.6525992822440454]
   [junit4]   1>  Edge added 2 to innerCrossingCount
   [junit4]   1>   Test point outer point [X=0.7540698997131706, Y=-0.07411317803527853, Z=-0.6525992822460656]
   [junit4]   1>  Edge added 1 to outerCrossingCount
   [junit4]   1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])] -> [lat=0.13953211802880663, lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361, Z=0.139079795174987])]
   [junit4]   1>
   [junit4]   1> The following edges should intersect the travel/testpoint planes:
   [junit4]   1> Travel plane: [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])] -> [lat=0.13953211802880663, lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361, Z=0.139079795174987])]
   [junit4]   1> Travel plane: [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
   [junit4]   1> Test point plane: [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
   [junit4]   1>
   [junit4]   1>   Travel inner point [X=1.0, Y=-1.3368072236836578E-12, Z=2.920754816285907E-13]
   [junit4]   1>  Edge added 1 to innerCrossingCount
   [junit4]   1>   Travel outer point [X=1.0, Y=6.831927763163421E-13, Z=-1.4926898632243605E-13]
   [junit4]   1>  Edge added 1 to outerCrossingCount

[Legacy Jira: Karl Wright on Apr 09 2018]

[mikemccand]

Reformatted, for easier reading:

   [junit4]   1> The following edges should intersect the travel/testpoint planes:
   [junit4]   1> Travel plane: [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
   [junit4]   1> Test point plane: [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
   [junit4]   1> Travel plane: [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])] -> [lat=0.13953211802880663, lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361, Z=0.139079795174987])]
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-0.6183600459696781, lon=-2.770488856855538([X=-0.7593628058597481, Y=-0.29549354861758625, Z=-0.5796996565482825])] -> [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])]
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
   [junit4]   1>   Travel inner point [X=1.0, Y=-1.336807223683658E-12, Z=-1.1771178322187736E-11]
   [junit4]   1>   Test point inner point [X=0.7540698997149413, Y=-0.07411317803504912, Z=-0.6525992822440454]
   [junit4]   1>  Edge added 2 to innerCrossingCount
   [junit4]   1>   Test point outer point [X=0.7540698997131706, Y=-0.07411317803527853, Z=-0.6525992822460656]
   [junit4]   1>  Edge added 1 to outerCrossingCount
   [junit4]   1>
   [junit4]   1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])] -> [lat=0.13953211802880663, lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361, Z=0.139079795174987])]
   [junit4]   1>   Travel inner point [X=1.0, Y=-1.3368072236836578E-12, Z=2.920754816285907E-13]
   [junit4]   1>  Edge added 1 to innerCrossingCount
   [junit4]   1>   Travel outer point [X=1.0, Y=6.831927763163421E-13, Z=-1.4926898632243605E-13]
   [junit4]   1>  Edge added 1 to outerCrossingCount

As you can see, there's one edge that adds TWO inner crossings and one outer crossing. Quite a feat. Figuring out how it does that is the trick.

[Legacy Jira: Karl Wright on Apr 09 2018]

[mikemccand]

Attached a visual representation of the shape and travel planes.

I think the problem is the edge that adds an inner and an outer plane, it should only add one!

[Legacy Jira: Ignacio Vera (@iverase) on Apr 09 2018]

[mikemccand]

What's right:

The graphic shows there are only two edges that intersect the travel plane and test point plane. And we find two, which is good. These are the ones we find:

   [junit4]   1> Considering edge [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]

and

   [junit4]   1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])] -> [lat=0.13953211802880663, lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361, Z=0.139079795174987])]

We'd expect one of the planes to intersect both the travel and the test point planes, and the other to intersect just one. The second edge intersects just the travel plane, and it crosses both inner and outer envelopes. The first edge, therefore, should cross the test point plane, both inner and outer, and it does. But since the second edge crossed both inner and outer travel plane envelopes, we'd expect that the first edge would do the same, but it doesn't; it only crosses the inner side.

So, either, the first edge should also cross the outer side of the travel plane, or the second edge should NOT cross the outer side of the travel plane. We need to determine what the right behavior is by going deeper numerically – we need to evaluate the edge endpoint to see where it sits relative to the travel plane and to the inner and outer envelopes. I will add evaluate() method calls to the diagnostics so we can see this.

But it's also clear we're looking at a numerical precision problem here.

[Legacy Jira: Karl Wright on Apr 09 2018]

[mikemccand]

I checked the intersection point of the top edge with the travel plane and it is numerically identical to the edge start point and still contributes with an inner and outer crossing.

Maybe this idea is too naive but if we calculate all intersection points we can assume the following:

1) if the intersection point is not numericaly identical to start and end edges, then it should contribute with an inner and an outer crossing. (we don't really need to calculate the crossings)

2) if the intersection point is numericaly identical to start or end edges, then it should contribute with just an inner or an outer crossing. (we just need to find out how to choose one...)

 

 

 

 

[Legacy Jira: Ignacio Vera (@iverase) on Apr 09 2018]

[mikemccand]

Here's the revised output for these two edges:

   [junit4]   1> Considering edge [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
   [junit4]   1>  start point travel dist=-0.11274773940907501; end point travel dist=3.268072236836579E-13
   [junit4]   1>  start point travel above dist=-0.11274773940806501; end point travel above dist=1.336807223683658E-12
   [junit4]   1>  start point travel below dist=-0.11274773941008501; end point travel below dist=-6.831927763163422E-13
   [junit4]   1>  start point testpoint dist=-0.34019438500826027; end point testpoint dist=0.6525992822450555
   [junit4]   1>  start point testpoint above dist=-0.3401943850072502; end point testpoint above dist=0.6525992822460656
   [junit4]   1>  start point testpoint below dist=-0.34019438500927035; end point testpoint below dist=0.6525992822440454
   [junit4]   1>   Travel inner point [X=1.0, Y=-1.336807223683658E-12, Z=-1.1771178322187736E-11]
   [junit4]   1>   Test point inner point [X=0.7540698997149413, Y=-0.07411317803504912, Z=-0.6525992822440454]
   [junit4]   1>  Edge added 2 to innerCrossingCount
   [junit4]   1>   Test point outer point [X=0.7540698997131706, Y=-0.07411317803527853, Z=-0.6525992822460656]
   [junit4]   1>  Edge added 1 to outerCrossingCount
   [junit4]   1>
   [junit4]   1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])] -> [lat=0.13953211802880663, lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361, Z=0.139079795174987])]
   [junit4]   1>  start point travel dist=3.268072236836579E-13; end point travel dist=-0.6365576248358092
   [junit4]   1>  start point travel above dist=1.336807223683658E-12; end point travel above dist=-0.6365576248347993
   [junit4]   1>  start point travel below dist=-6.831927763163422E-13; end point travel below dist=-0.6365576248368193
   [junit4]   1>  start point testpoint dist=0.6525992822450555; end point testpoint dist=0.7916790774200425
   [junit4]   1>  start point testpoint above dist=0.6525992822460656; end point testpoint above dist=0.7916790774210526
   [junit4]   1>  start point testpoint below dist=0.6525992822440454; end point testpoint below dist=0.7916790774190324
   [junit4]   1>   Travel inner point [X=1.0, Y=-1.3368072236836578E-12, Z=2.920754816285907E-13]
   [junit4]   1>  Edge added 1 to innerCrossingCount
   [junit4]   1>   Travel outer point [X=1.0, Y=6.831927763163421E-13, Z=-1.4926898632243605E-13]
   [junit4]   1>  Edge added 1 to outerCrossingCount

The first edge's endpoint is on the "below" travel plane, but not the "above" one, and that's of course true as well for the start point of the second edge, since they're shared. And indeed we see two "inner" crossings of the travel plane – one from each edge. Those are correct.

So we're seeing an extra crossing of the outer plane that we should not, specifically this one:

   [junit4]   1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])] -> [lat=0.13953211802880663, lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361, Z=0.139079795174987])]
   [junit4]   1>   Travel outer point [X=1.0, Y=6.831927763163421E-13, Z=-1.4926898632243605E-13]
   [junit4]   1>  Edge added 1 to outerCrossingCount

We compute this by calling Plane.findCrossings() between the outer travel plane and the edge plane, within the computed bounds planes. We should not find this intersection, but we do anyway, and that is the cause of the problem.

The numeric precision of that method under these conditions is not adequate to this kind of find-grained envelope computation. The next step is to see whether the point that it finds is off the two intersecting planes, and if so, by how much. If that's what is going wrong, we may need to increase MINIMUM_RESOLUTION somewhat to cover the computation issues, maybe to 2e-12. OR we can try a successive approximation approach to the intersection math – but I don't relish that idea, frankly.

[Legacy Jira: Karl Wright on Apr 09 2018]

[mikemccand]

@ivera, I'm afraid that I don't think your solution is the right one.

[Legacy Jira: Karl Wright on Apr 09 2018]

[mikemccand]

I don't think it either. I will add later today or tomorrow a random test that it is extremely good to find all these cases. It can be used to validate solutions.

[Legacy Jira: Ignacio Vera (@iverase) on Apr 09 2018]

[mikemccand]

Ok, looking at the crossings we get, here's the complete output:

   [junit4]   1>
   [junit4]   1> Considering edge [lat=-1.4506713533447755, lon=-1.2251247551355924([X=0.04060395941016342, Y=-0.11274773940940182, Z=-0.9927936672533157])] -> [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])]
   [junit4]   1>  start point travel dist=-0.11274773940907501; end point travel dist=3.268072236836579E-13
   [junit4]   1>  start point travel above dist=-0.11274773940806501; end point travel above dist=1.336807223683658E-12
   [junit4]   1>  start point travel below dist=-0.11274773941008501; end point travel below dist=-6.831927763163422E-13
   [junit4]   1>  start point testpoint dist=-0.34019438500826027; end point testpoint dist=0.6525992822450555
   [junit4]   1>  start point testpoint above dist=-0.3401943850072502; end point testpoint above dist=0.6525992822460656
   [junit4]   1>  start point testpoint below dist=-0.34019438500927035; end point testpoint below dist=0.6525992822440454
   [junit4]   1>   Travel inner point [X=1.0, Y=-1.336807223683658E-12, Z=-1.1771178322187736E-11]; edgeplane=0.0; travelInsidePlane=0.0
   [junit4]   1>   Test point inner point [X=0.7540698997149413, Y=-0.07411317803504912, Z=-0.6525992822440454]; edgeplane=0.0; testPointInsidePlane=0.0
   [junit4]   1>  Edge added 2 to innerCrossingCount
   [junit4]   1>   Test point outer point [X=0.7540698997131706, Y=-0.07411317803527853, Z=-0.6525992822460656]; edgeplane=0.0; testPointOutsidePlane=0.0
   [junit4]   1>  Edge added 1 to outerCrossingCount
   [junit4]   1>
   [junit4]   1> Considering edge [lat=4.9E-324, lon=0.0([X=1.0, Y=0.0, Z=4.9E-324])] -> [lat=0.13953211802880663, lon=-2.443438340098597([X=-0.7585849990851791, Y=-0.6365576248361361, Z=0.139079795174987])]
   [junit4]   1>  start point travel dist=3.268072236836579E-13; end point travel dist=-0.6365576248358092
   [junit4]   1>  start point travel above dist=1.336807223683658E-12; end point travel above dist=-0.6365576248347993
   [junit4]   1>  start point travel below dist=-6.831927763163422E-13; end point travel below dist=-0.6365576248368193
   [junit4]   1>  start point testpoint dist=0.6525992822450555; end point testpoint dist=0.7916790774200425
   [junit4]   1>  start point testpoint above dist=0.6525992822460656; end point testpoint above dist=0.7916790774210526
   [junit4]   1>  start point testpoint below dist=0.6525992822440454; end point testpoint below dist=0.7916790774190324
   [junit4]   1>   Travel inner point [X=1.0, Y=-1.3368072236836578E-12, Z=2.920754816285907E-13]; edgeplane=-5.0487097934144756E-29; travelInsidePlane=2.0194839173657902E-28
   [junit4]   1>  Edge added 1 to innerCrossingCount
   [junit4]   1>   Travel outer point [X=1.0, Y=6.831927763163421E-13, Z=-1.4926898632243605E-13]; edgeplane=2.5243548967072378E-29; travelOutsidePlane=-1.0097419586828951E-28
   [junit4]   1>  Edge added 1 to outerCrossingCount   

The travel outer point it incorrectly finds has a distance to each intersecting plane that's on the order of 1e-28. That basically says it's a real intersection given the inputs. So that second edge does intersect the outer envelope EVEN THOUGH it doesn't look like it should, based on the endpoint.

The only other thing that can be going wrong is that the edge endpoint's bounds are just sloppy enough to permit this intersection to be included in the crossings list, while it really should be rejected. I'll need more diagnostics to rule that in or out as the underlying cause, but I'm getting busy at work now so that's not going to happen for a while.

[Legacy Jira: Karl Wright on Apr 09 2018]

[mikemccand]

Last bit of debugging until later:

   [junit4]   1>   Travel outer point [X=1.0, Y=6.831927763163421E-13, Z=-1.4926898632243605E-13]; edgeplane=2.5243548967072378E-29; travelOutsidePlane=-1.0097419586828951E-28; edgestartplane=-6.993093735168714E-13; edgeendplane=-0.6515740933786793
   [junit4]   1>  Edge added 1 to outerCrossingCount

The bad crossing point it finds is (it appears) on the wrong side of the edge's start cutoff plane, at a value of -6.993093735168714E-13, which is almost big enough to get it kicked out, but not quite.

The interesting thing is that the precision of sidedness checks in general (which is what this is, in fact) is MUCH higher than 1e-12. But if we decreased MINIMUM_RESOLUTION globally, we would not fix the issue, because the above/below planes get closer to the travel plane by exactly a proportional amount. Maybe it would be possible, though, to have a tighter bound on SidedPlane.isWithin() than we'd have elsewhere? Or maybe we could apply an alternate, tighter filter in the case of the crossing points in GeoComplexPolygon alone. I'll have to think this through.

[Legacy Jira: Karl Wright on Apr 09 2018]

[mikemccand]

For fun, I tried to set it up so that the edge cutoff planes had a smaller MINIMUM_RESOLUTION they used than everything else. This unexpectedly broke everything. So then I tried having a smaller MINIMUM_RESOLUTION just for the start/end planes for edges. This allowed me to get the current failing test to start passing, but the other tests committed on the weekend started failing instead. In fact, I could find a value for this that's not much different than MINIMUM_RESOLUTION that led to ALL the complex polygon tests failing. That's a rather worrisome development.

[Legacy Jira: Karl Wright on Apr 09 2018]

[mikemccand]

Reasoning this through, the spacing between the travel plane and the above or below plane should be exactly 2.0 * MINIMUM_RESOLUTION. That will guarantee that any point that falls between the two planes is detected in one or the other (or, very rarely, both). When I set it up this way, the LUCENE8245 test starts passing, but the testAboveBelowCrossingDifferentEdges example now fails. So I will next analyze why that occurs, and see if the problem in that case is more readily addressable.

[Legacy Jira: Karl Wright on Apr 09 2018]

[mikemccand]

I can give you an answer why it fails: In that case the planes above and below cross different edges. Because we only consider edges that crosses the main plain we miss one cross.

[Legacy Jira: Ignacio Vera (@iverase) on Apr 09 2018]

[mikemccand]

Ok, this is the debug output of the now-failing test:

   [junit4] Suite: org.apache.lucene.spatial3d.geom.GeoPolygonTest
   [junit4]   1> Considering edge [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0, Z=1.5463873005088208E-34])] -> [lat=-0.08842062843650192, lon=2.2837078580414776([X=-0.6514839583883643, Y=0.7535056721696336, Z=-0.08830545832969094])]
   [junit4]   1>
   [junit4]   1> The following edges should intersect the travel/testpoint planes:
   [junit4]   1> Travel plane: [lat=0.7779906922732096, lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598, Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0, Z=1.5463873005088208E-34])]
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-0.08842062843650192, lon=2.2837078580414776([X=-0.6514839583883643, Y=0.7535056721696336, Z=-0.08830545832969094])] -> [lat=0.379731892927642, lon=2.3485766139444504([X=-0.651713420845267, Y=0.
6617191814215959, Z=0.370671474528177])]
   [junit4]   1>
   [junit4]   1> The following edges should intersect the travel/testpoint planes:
   [junit4]   1> Travel plane: [lat=0.7779906922732096, lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598, Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0, Z=1.5463873005088208E-34])]
   [junit4]   1>
   [junit4]   1> Considering edge [lat=0.7779906922732096, lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598, Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0, Z=1.5463873005088208E-34])]

   [junit4]   1>
   [junit4]   1> The following edges should intersect the travel/testpoint planes:
   [junit4]   1> Travel plane: [lat=0.7779906922732096, lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598, Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0, Z=1.5463873005088208E-34])]
   [junit4]   1>
   [junit4]   1>  start point travel dist=0.7018495564156595; end point travel dist=-2.330673801245995E-13
   [junit4]   1>  start point travel above dist=0.7018495564176594; end point travel above dist=1.7669326198754006E-12
   [junit4]   1>  start point travel below dist=0.7018495564136594; end point travel below dist=-2.2330673801246E-12
   [junit4]   1>  start point testpoint dist=-0.4923642700993317; end point testpoint dist=-0.7784765265847915
   [junit4]   1>  start point testpoint above dist=-0.49236427009733164; end point testpoint above dist=-0.7784765265827914
   [junit4]   1>  start point testpoint below dist=-0.49236427010133177; end point testpoint below dist=-0.7784765265867916
   [junit4]   1>   Travel inner point [X=1.0, Y=9.103203687613759E-13, Z=2.2330673801246004E-12]; edgeplane=-1.0097419586828951E-28; travelInsidePlane=4.0389678347315804E-28; edgestartplane=0.7579267927410742; edgeendplane=-2.4114877353945626E-12
   [junit4]   1>  Edge added 1 to innerCrossingCount
   [junit4]   1>  Edge added 0 to outerCrossingCount
   [junit4] FAILURE 0.16s | GeoPolygonTest.testAboveBelowCrossingDifferentEdges <<<
   [junit4]    > Throwable #1: java.lang.AssertionError
   [junit4]    >        at org.apache.lucene.spatial3d.geom.GeoPolygonTest.testAboveBelowCrossingDifferentEdges(GeoPolygonTest.java:1486)
   [junit4] Completed [1/1 (1!)] in 0.17s, 1 test, 1 failure <<< FAILURES!

[Legacy Jira: Karl Wright on Apr 09 2018]

[mikemccand]

@ivera, that case should not occur. The shared endpoint of two edges must either be in the +/- 1e-12 zone of main travel plane, or it's outside. If it's within that zone, then BOTH edges should show up as an intersection candidate.

The tree structures underneath the edge iterator may be the problem, since I don't believe they include the necessary 1e-12 extra bounds needed to guarantee that we compute the intersection. That's what I'm going to look for, since in the dump above it doesn't appear like we even consider more than one edge in the iterator.

[Legacy Jira: Karl Wright on Apr 09 2018]

[mikemccand]

Here's the output of the two edges that get considered in this case:

   [junit4]   1> Considering edge [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0, Z=1.5463873005088208E-34])] -> [lat=-0.08842062843650192, lon=2.2837078580414776([X=-0.6514839583883643, Y=0.7535056721696336, Z=-0.08830545832969094])]
   [junit4]   1> Looking for intersection between plane [A=0.0, B=0.0; C=1.0; D=-2.330673801245995E-13] and plane [A=-1.5358762834889417E-34, B=0.11639624844359603; C=0.9932028560914717; D=0.0] within bounds
   [junit4]   1>  Two points of intersection
   [junit4]   1>   return no solutions
   [junit4]   1> Looking for intersection between plane [A=0.0, B=1.0; C=0.0; D=-0.7784765265847915] and plane [A=-1.5358762834889417E-34, B=0.11639624844359603; C=0.9932028560914717; D=0.0] within bounds
   [junit4]   1>  Two points of intersection
   [junit4]   1>   return no solutions

   [junit4]   1> Considering edge [lat=-0.08842062843650192, lon=2.2837078580414776([X=-0.6514839583883643, Y=0.7535056721696336, Z=-0.08830545832969094])] -> [lat=0.379731892927642, lon=2.3485766139444504([X=-0.651713420845267, Y=0.6617191814215959, Z=0.370671474528177])]
   [junit4]   1> Looking for intersection between plane [A=0.0, B=0.0; C=1.0; D=-2.330673801245995E-13] and plane [A=0.7421702138887571, B=0.6571273907443821; C=0.1317837848515384; D=0.0] within bounds
   [junit4]   1>  Two points of intersection
   [junit4]   1>   return no solutions
   [junit4]   1> Looking for intersection between plane [A=0.0, B=1.0; C=0.0; D=-0.7784765265847915] and plane [A=0.7421702138887571, B=0.6571273907443821; C=0.1317837848515384; D=0.0] within bounds
   [junit4]   1>  no solutions - no intersection
   [junit4]   1> Considering edge [lat=0.7779906922732096, lon=2.728264320121337([X=-0.6523396177204123, Y=0.2861122564854598, Z=0.7018495564158925])] -> [lat=1.5463873005088208E-34, lon=0.0([X=1.0, Y=0.0, Z=1.5463873005088208E-34])]
   [junit4]   1> Looking for intersection between plane [A=0.0, B=0.0; C=1.0; D=-2.330673801245995E-13] and plane [A=5.837507846237386E-35, B=0.9260123314536496; C=-0.377493260861404; D=0.0] within bounds
   [junit4]   1>  Two points of intersection
   [junit4]   1>   returning 1 solution
   [junit4]   1>   Travel inner point [X=1.0, Y=9.103203687613759E-13, Z=2.2330673801246004E-12]; edgeplane=-1.0097419586828951E-28; travelInsidePlane=4.0389678347315804E-28; edgestartplane=0.7579267927410742; edgeendplane=-2.4114877353945626E-12
   [junit4]   1>  Edge added 1 to innerCrossingCount
   [junit4]   1>  Edge added 0 to outerCrossingCount

The second edge is detected as an intersection, but as you surmised, the first is not, even though it's properly found out of the tree.

The reason it's rejected is because of bounds; two points of intersection are in fact found, but apparently the bounding planes operate a bit too strenuously and do not permit either intersection point to remain.

It should be possible to bypass this case, however, since the case we're trying to catch is when an edge's endpoint is actually on the travel plane. In that case, we've already got an intersection point to check. I'll see if that solves this problem.

[Legacy Jira: Karl Wright on Apr 09 2018]

[mikemccand]

Commit 9bd6d1305c8bbccf2f3a22079a523b483325e9eb in lucene-solr's branch refs/heads/master from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=9bd6d13

LUCENE-8245: Don't rely only on 'intersects' code to determine whether we should bother looking for crossings; also see if endpoints lie on travel planes.

[Legacy Jira: ASF subversion and git services on Apr 10 2018]

[mikemccand]

Not sure if it belongs on this issue, but this is a reproducing TestGeo3DPoint.testGeo3DRelations() failure, from https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4557/:

Checking out Revision b82f5912a05ceffd28cf2a600c701e2fb387014d (refs/remotes/origin/master)
[...]
  [junit4] Suite: org.apache.lucene.spatial3d.TestGeo3DPoint
  [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=TestGeo3DPoint -Dtests.method=testGeo3DRelations -Dtests.seed=7BAAE36CC3CC7C16 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=shi-Tfng-MA -Dtests.timezone=America/Swift_Current -Dtests.asserts=true -Dtests.file.encoding=UTF-8
  [junit4] ERROR   0.67s J0 | TestGeo3DPoint.testGeo3DRelations <<<
  [junit4]    > Throwable #1: java.lang.IllegalArgumentException: No off-plane intersection points were found; can't compute traversal
  [junit4]    >     at __randomizedtesting.SeedInfo.seed([7BAAE36CC3CC7C16:CBD59EF84C81D28A]:0)
  [junit4]    >     at org.apache.lucene.spatial3d.geom.GeoComplexPolygon$DualCrossingEdgeIterator.pickProximate(GeoComplexPolygon.java:1201)
  [junit4]    >     at org.apache.lucene.spatial3d.geom.GeoComplexPolygon$DualCrossingEdgeIterator.computeInsideOutside(GeoComplexPolygon.java:1181)
  [junit4]    >     at org.apache.lucene.spatial3d.geom.GeoComplexPolygon$DualCrossingEdgeIterator.matches(GeoComplexPolygon.java:1254)
  [junit4]    >     at org.apache.lucene.spatial3d.geom.GeoComplexPolygon$Node.traverse(GeoComplexPolygon.java:664)
  [junit4]    >     at org.apache.lucene.spatial3d.geom.GeoComplexPolygon$Tree.traverse(GeoComplexPolygon.java:760)
  [junit4]    >     at org.apache.lucene.spatial3d.geom.GeoComplexPolygon$Tree.traverse(GeoComplexPolygon.java:746)
  [junit4]    >     at org.apache.lucene.spatial3d.geom.GeoComplexPolygon.isWithin(GeoComplexPolygon.java:456)
  [junit4]    >     at org.apache.lucene.spatial3d.geom.GeoBaseMembershipShape.isWithin(GeoBaseMembershipShape.java:36)
  [junit4]    >     at org.apache.lucene.spatial3d.geom.BaseXYZSolid.isAreaInsideShape(BaseXYZSolid.java:130)
  [junit4]    >     at org.apache.lucene.spatial3d.geom.StandardXYZSolid.getRelationship(StandardXYZSolid.java:432)
  [junit4]    >     at org.apache.lucene.spatial3d.TestGeo3DPoint.testGeo3DRelations(TestGeo3DPoint.java:311)
  [junit4]    >     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  [junit4]    >     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  [junit4]    >     at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  [junit4]    >     at java.base/java.lang.reflect.Method.invoke(Method.java:564)
  [junit4]    >     at java.base/java.lang.Thread.run(Thread.java:844)
[...]
  [junit4]   2> NOTE: test params are: codec=Asserting(Lucene70): {id=BlockTreeOrds(blocksize=128)}, docValues:{id=DocValuesFormat(name=Lucene70), point=DocValuesFormat(name=Asserting)}, maxPointsInLeafNode=910, maxMBSortInHeap=5.851383459429137, sim=Asserting(org.apache.lucene.search.similarities.AssertingSimilarity@1f97fd1a), locale=shi-Tfng-MA, timezone=America/Swift_Current
  [junit4]   2> NOTE: Mac OS X 10.11.6 x86_64/Oracle Corporation 9 (64-bit)/cpus=3,threads=1,free=30828472,total=54853632

[Legacy Jira: Steven Rowe on Apr 10 2018]

[mikemccand]

Commit 2ef5c946c3e19a49c712047f0825c26d5db09cf6 in lucene-solr's branch refs/heads/branch_7x from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2ef5c94

LUCENE-8245: Don't rely only on 'intersects' code to determine whether we should bother looking for crossings; also see if endpoints lie on travel planes.

[Legacy Jira: ASF subversion and git services on Apr 10 2018]

[mikemccand]

Commit 95435d4e738869a4dc46c5f47a59a7df44d0c593 in lucene-solr's branch refs/heads/branch_6x from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=95435d4

LUCENE-8245: Don't rely only on 'intersects' code to determine whether we should bother looking for crossings; also see if endpoints lie on travel planes.

[Legacy Jira: ASF subversion and git services on Apr 10 2018]

[mikemccand]

Not sure if it belongs on this issue, but this is a reproducing TestGeo3DPoint.testGeo3DRelations() failure, from https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/4557/:

As of Karl's 9bd6d13 commit, this failure ^^ no longer reproduces.

[Legacy Jira: Steven Rowe on Apr 10 2018]

[mikemccand]

I need to re-open again as I see still errors related with travel plane intersecting near a polygon point.

[Legacy Jira: Ignacio Vera (@iverase) on Apr 10 2018]

[mikemccand]

I attached the patches:

case3: Contains three test cases.

1) The first cases seems to fail because we need to increase the envelope for asserting if we need to look for inner and outer crossings. The following seems to help:

 

final GeoPoint[] travelCrossings = travelPlane.findIntersections(planetModel, edge.plane, checkPointCutoffPlane, checkPointOtherCutoffPlane, edge.startPlane, edge.endPlane);
if (travelCrossings != null && travelCrossings.length == 0) {
  final GeoPoint[] testPointCrossings = testPointPlane.findIntersections(planetModel, edge.plane, testPointCutoffPlane, testPointOtherCutoffPlane, edge.startPlane, edge.endPlane);
  if (testPointCrossings != null && testPointCrossings.length == 0) {
    // As a last resort, see if the edge endpoints are on either plane.  This is sometimes necessary because the
    // intersection computation logic might not detect near-miss edges otherwise.
    if (Math.abs(travelPlane.evaluate(edge.startPoint)) > Plane.MINIMUM_PLANE_OFFSET  &&
        Math.abs(travelPlane.evaluate(edge.endPoint)) > Plane.MINIMUM_PLANE_OFFSET &&
        Math.abs(testPointPlane.evaluate(edge.startPoint)) > Plane.MINIMUM_PLANE_OFFSET &&
        Math.abs(testPointPlane.evaluate(edge.endPoint)) > Plane.MINIMUM_PLANE_OFFSET) {
      return true;
    }
  }
}

 

2)  We miss crossings but the end point or start point are actually on the plane. I have changed the way we count crossings and it seems to help:

 

if (testPointInnerCrossings != null && testPointInnerCrossings.length > 0) {
  for (final GeoPoint crossing : testPointInnerCrossings) {
    //System.out.println("  Test point inner point "+crossing+"; edgeplane="+edge.plane.evaluate(crossing)+"; testPointInsidePlane="+testPointInsidePlane.evaluate(crossing)+"; edgestartplane="+edge.startPlane.evaluate(crossing)+"; edgeendplane="+edge.endPlane.evaluate(crossing));
    countingHash.add(crossing);
  }
} else if (testPointOuterCrossings != null && testPointOuterCrossings.length > 0) {
  if (testPointInsidePlane.evaluateIsZero(edge.endPoint) || testPointInsidePlane.evaluateIsZero(edge.startPoint)) {
    countingHash.add(edge.endPoint);
  }
}

 

I added the random test I am using to uncover all these cases. It still gets spurious errors but after the changes above they don't seem related with this case.

The last patch is my version of GeoComplexPolygon.

 

 

 

 

[Legacy Jira: Ignacio Vera (@iverase) on Apr 10 2018]

[mikemccand]

Commit 661fdf3a43e6d7a8b8b28254f69387209bafcd75 in lucene-solr's branch refs/heads/master from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=661fdf3

LUCENE-8245: Add more tests that demonstrate problems with GeoComplexPolygon.

[Legacy Jira: ASF subversion and git services on Apr 10 2018]

[mikemccand]

Commit 138e206547f7a6732dc6dd56a516ad440256eaf0 in lucene-solr's branch refs/heads/branch_7x from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=138e206

LUCENE-8245: Add more tests that demonstrate problems with GeoComplexPolygon.

[Legacy Jira: ASF subversion and git services on Apr 10 2018]

[mikemccand]

Commit 3a0aef1fe91039b397e4b023238fd0e0296459a3 in lucene-solr's branch refs/heads/branch_6x from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3a0aef1

LUCENE-8245: Add more tests that demonstrate problems with GeoComplexPolygon.

[Legacy Jira: ASF subversion and git services on Apr 10 2018]

[mikemccand]

@ivera, I've committed the tests with the @AwaitsFix annotation. I'm looking at them one at a time.

Please let me turn your attention to "case2". Debug output from this case looks like this:

   [junit4]   1>
   [junit4]   1> The following edges should intersect the travel/testpoint planes:
   [junit4]   1> Travel plane: [lat=-0.09183481853716734, lon=0.0([X=0.9957861458099824, Y=0.0, Z=-0.09170578941866683])] -> [lat=-0.3728403971990659, lon=-0.27395646628085935([X=0.8965665862615776, Y=-0.25195523953197785, Z=-0.3642621496554991])]
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-0.09183481853716734, lon=0.0([X=0.9957861458099824, Y=0.0, Z=-0.09170578941866683])] -> [lat=-0.3728403971990659, lon=-0.27395646628085935([X=0.8965665862615776, Y=-0.25195523953197785, Z=-0.3642621496554991])]
   [junit4]   1>  Intersection found with travel plane...
   [junit4]   1>  Edge intersects travel or testPoint plane
   [junit4]   1>  Edge added 0 to innerCrossingCount
   [junit4]   1>  Edge added 1 to outerCrossingCount
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-0.28073906699213097, lon=0.21188006007761473([X=0.9393636799476138, Y=0.20206530496788694, Z=-0.2770658573760249])] -> [lat=-0.1600017188310958, lon=0.0849758111192731([X=0.983664825750331, Y=0.08378949178268695, Z=-0.1593199034909639])]
   [junit4]   1>  No intersections with travel plane...
   [junit4]   1>  No intersections with testpoint plane...
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-0.1600017188310958, lon=0.0849758111192731([X=0.983664825750331, Y=0.08378949178268695, Z=-0.1593199034909639])] -> [lat=-0.09183481853716734, lon=0.0([X=0.9957861458099824, Y=0.0, Z=-0.09170578941866683])]
   [junit4]   1>  No intersections with travel plane...
   [junit4]   1>  No intersections with testpoint plane...
   [junit4]   1>
   [junit4]   1> Considering edge [lat=-0.3728403971990659, lon=-0.27395646628085935([X=0.8965665862615776, Y=-0.25195523953197785, Z=-0.3642621496554991])] -> [lat=-0.4683367913453203, lon=0.09620752412577895([X=0.8881938751251655, Y=0.08571555484949944, Z=-0.4514027955684197])]
   [junit4]   1>  No intersections with travel plane...
   [junit4]   1>  No intersections with testpoint plane... 

So, the sole edge that intersects with the travel plane does not intersect at either edge's endpoint; it intersects by virtue of an actual mathematical intersection being detected. Since there is no detection of an intersection of the travel plane by any of the other edges, we can conclude, as you certainly have, that the edge's endpoints both lie outside of the zone where we would consider those endpoints to be on the travel plane. So far, so good. But let's be clear: this means, mathematically, that there is no intersection between any of the other edges and the travel plane.

What we need to do is figure out how the edge winds up crossing just one side of the envelope, and not exiting anywhere, without intersecting either the inner or outer envelope planes. We know that intersection computation is not guaranteed to come up with a plane intersection unless there's an actual crossing of the plane within the intersection bounds. So, probably, the endpoint's intersection with the inner/outer envelope plane(s) is what's being missed.

I'll try a fix and see how that does.

[Legacy Jira: Karl Wright on Apr 10 2018]

[mikemccand]

The problem why the plane enters the polygon and never exists is because it reaches the intersection point. The actual travel plane is just outside of the polygon running in paralell (never crosses) and only the inner plane enters until the intersection point is reached.

what we currently do is to check for crossing of all travel planes if either the test plane or the check plane has an intersections. Maybe we need to separate this logic.

[Legacy Jira: Ignacio Vera (@iverase) on Apr 10 2018]

[mikemccand]

Hello, I'm afraid it may hurt precommit like https://jenkins.thetaphi.de/job/Lucene-Solr-7.x-Solaris/551/

[forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) [Use home-grown methods instead] [forbidden-apis] in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest (RandomGeoPolygonTest.java:177) [forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) [Use home-grown methods instead] [forbidden-apis] in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest (RandomGeoPolygonTest.java:177) [forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) [Use home-grown methods instead] [forbidden-apis] in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest (RandomGeoPolygonTest.java:214) [forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) [Use home-grown methods instead] [forbidden-apis] in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest (RandomGeoPolygonTest.java:214) [forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) [Use home-grown methods instead] [forbidden-apis] in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest (RandomGeoPolygonTest.java:216) [forbidden-apis] Forbidden method invocation: java.lang.Math#toDegrees(double) [Use home-grown methods instead] [forbidden-apis] in org.apache.lucene.spatial3d.geom.RandomGeoPolygonTest (RandomGeoPolygonTest.java:216)

[Legacy Jira: Mikhail Khludnev (@mkhludnev) on Apr 10 2018]

[mikemccand]

Commit 14b313f42bbc061704232eda0d0c3ff1405fe9e3 in lucene-solr's branch refs/heads/master from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=14b313f

LUCENE-8245: Adopt a more-rigorous way of finding intersections with envelope planes.

[Legacy Jira: ASF subversion and git services on Apr 10 2018]

[mikemccand]

Commit 99e5a411861fdd9a0af2eda4c09fa83b49e80d11 in lucene-solr's branch refs/heads/branch_7x from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=99e5a41

LUCENE-8245: Adopt a more-rigorous way of finding intersections with envelope planes.

[Legacy Jira: ASF subversion and git services on Apr 10 2018]

[mikemccand]

Commit 16e5ab161cc97a46c4dd115c409e8ed4ddf3b40f in lucene-solr's branch refs/heads/branch_6x from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=16e5ab1

LUCENE-8245: Adopt a more-rigorous way of finding intersections with envelope planes.

[Legacy Jira: ASF subversion and git services on Apr 10 2018]

[mikemccand]

Well, I have a fix committed for case2. But the fix only narrowly applies to that failure, apparently. The full fix requires new math: I need to be able to determine, somehow, if the surface path of a plane which connects two points stays everywhere within MINIMUM_RESOLUTION of another plane. I'll have to think that through but there's no more time today.

[Legacy Jira: Karl Wright on Apr 10 2018]

[mikemccand]

Commit 61c37551aca28341acef176d9dc088b37c84d307 in lucene-solr's branch refs/heads/master from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=61c3755

LUCENE-8245: Fix precommit.

[Legacy Jira: ASF subversion and git services on Apr 10 2018]

[mikemccand]

Commit b873d1fb3422206ff7adf756791258333f1bf9f0 in lucene-solr's branch refs/heads/branch_7x from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b873d1f

LUCENE-8245: Fix precommit.

[Legacy Jira: ASF subversion and git services on Apr 10 2018]

[mikemccand]

Commit 19feef73bf17796cad27215602a8f5cdad5266f1 in lucene-solr's branch refs/heads/branch_6x from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=19feef7

LUCENE-8245: Fix precommit.

[Legacy Jira: ASF subversion and git services on Apr 10 2018]

[mikemccand]

I'm still seeing precommit errors. Am about to push out a fix for them.

[Legacy Jira: Joel Bernstein (@joel-bernstein) on Apr 10 2018]

[mikemccand]

Commit e90ab4bb8191644a19308c30a3e4752043d50985 in lucene-solr's branch refs/heads/master from @joel-bernstein https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e90ab4b

LUCENE-8245: Fix precommit

[Legacy Jira: ASF subversion and git services on Apr 10 2018 [updated: Oct 08 2019]]

[mikemccand]

Commit 48325cf8ce8de647300409def9c0b18c116ea307 in lucene-solr's branch refs/heads/branch_7x from @joel-bernstein https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=48325cf

LUCENE-8245: Fix precommit

[Legacy Jira: ASF subversion and git services on Apr 10 2018 [updated: Oct 08 2019]]

[mikemccand]

Commit 6f68f74f7f36b0410dcfc29c03e5a970670c81ee in lucene-solr's branch refs/heads/branch_6x from @joel-bernstein https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=6f68f74

LUCENE-8245: Fix precommit

[Legacy Jira: ASF subversion and git services on Apr 10 2018 [updated: Oct 08 2019]]

[mikemccand]

The more-rigorous way of properly discovering the above condition is sort of already present. What's needed is to find the XYZBounds of the bit of arc between the intersection point and the end point of the arc, and make sure that it all fits within the envelope plane bounds.

Unfortunately, this is all rather expensive to compute – mainly because of significant object creation being required. Fortunately, it happens only in very specific cases so maybe it would be limited enough to not impact things too badly. But no question it would need to happen every time an edge ends on an envelope plane, and the distance between the edge endpoint and the intersection point is greater than MINIMUM_RESOLUTION.

I'm going to take a break from this particular part of the problem to give myself a chance to think it through to be sure there isn't a better way. I'm also going to analyze case3 to see what the issue is there – tomorrow.

[Legacy Jira: Karl Wright on Apr 10 2018]

[mikemccand]

Commit 8e77892443601d702071dae4336d4976d9a7564f in lucene-solr's branch refs/heads/master from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8e77892

LUCENE-8245: Handle parallel planes case properly.

[Legacy Jira: ASF subversion and git services on Apr 11 2018]

[mikemccand]

Commit 2376b6c51c4fa7bb4ae8c1dfa04b1704a0d9f37a in lucene-solr's branch refs/heads/branch_7x from [~kwright@metacarta.com] https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2376b6c

LUCENE-8245: Handle parallel planes case properly.

[Legacy Jira: ASF subversion and git services on Apr 11 2018]