You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tests run: 100, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.437 sec <<< FAILURE! - in org.locationtech.spatial4j.shape.impl.BBoxCalculatorTest
testGeoLongitude { seed=[859E55631A6DA980:F0F85AA453DFE02B]}(org.locationtech.spatial4j.shape.impl.BBoxCalculatorTest) Time elapsed: 0.016 sec <<< FAILURE!
java.lang.AssertionError: Rect(minX=180.0,maxX=180.0,minY=-90.0,maxY=60.0) intersect Rect(minX=-180.0,maxX=-180.0,minY=-90.0,maxY=60.0) expected:<Rect(minX=180.0,maxX=180.0,minY=-90.0,maxY=60.0)> but was:<Rect(minX=-180.0,maxX=-180.0,minY=-90.0,maxY=60.0)>
at __randomizedtesting.SeedInfo.seed([859E55631A6DA980:F0F85AA453DFE02B]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.locationtech.spatial4j.shape.RandomizedShapeTest._assertIntersect(RandomizedShapeTest.java:151)
at org.locationtech.spatial4j.shape.RandomizedShapeTest.assertRelation(RandomizedShapeTest.java:141)
at org.locationtech.spatial4j.shape.RandomizedShapeTest.assertRelation(RandomizedShapeTest.java:135)
at org.locationtech.spatial4j.shape.impl.BBoxCalculatorTest.testGeoLongitude(BBoxCalculatorTest.java:61)
These are two rectangles that are vertical lines along the dateline, but one of them is defined with -180 and the other with +180. They are otherwise equal (same latitude range). But they don't report themselves as equal.
If we normalized zero-width rectangles at construction then we wouldn't have this problem. That's one way to fix, though loses the input coordinates as given and I'm not sure if that matters?
Alternatively, assertIntersect could be smarter to try and detect this. It already detects rectangles that are actually degenerate points at the pole. That could have been handled via rectangle normalization as well (zero height rects at the pole could have their longitudes normalized, to say, 0,0). Given this precedent, I guess we could continue with it and have assertIntersects detect this scenario. I'm inclined to go with that as it's least risky (will impact nobody; just updating a test to not fail).
The text was updated successfully, but these errors were encountered:
I got this failure:
These are two rectangles that are vertical lines along the dateline, but one of them is defined with -180 and the other with +180. They are otherwise equal (same latitude range). But they don't report themselves as equal.
If we normalized zero-width rectangles at construction then we wouldn't have this problem. That's one way to fix, though loses the input coordinates as given and I'm not sure if that matters?
Alternatively, assertIntersect could be smarter to try and detect this. It already detects rectangles that are actually degenerate points at the pole. That could have been handled via rectangle normalization as well (zero height rects at the pole could have their longitudes normalized, to say, 0,0). Given this precedent, I guess we could continue with it and have assertIntersects detect this scenario. I'm inclined to go with that as it's least risky (will impact nobody; just updating a test to not fail).
The text was updated successfully, but these errors were encountered: