[
https://issues.apache.org/jira/browse/LUCENE-8587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16715216#comment-16715216
]
Zsolt Gyulavari commented on LUCENE-8587:
-----------------------------------------
Apparently I've tapped in a bigger question here.
The tests are failing (10% of the time) because GeoPoint serialization is based
on lat/lon fields and equals are based on x/y/z fields. When creating GeoPoints
out of lat/lon data in the test suite (as it is done for the shapes) then the
same rounding happens as in the deserialization. The testPoint however is
generated based on x/y/z in the test suite, so the rounding of the
deserialization will result in different coordinates.
If I changed the equals method to allow a threshold below MINIMUM_RESOLUTION
the hashCodes would be different for object that would be equal.
If I changed the generation of the random test data I would hide a potential
problem in serialization:
When a GeoPoint is created using the x/y/z constructor the
serialization/deserialization would potentially result in an object that isn't
equal to the original.
Please advise.
> Self comparison bug in GeoComplexPolygon.equals method
> ------------------------------------------------------
>
> Key: LUCENE-8587
> URL: https://issues.apache.org/jira/browse/LUCENE-8587
> Project: Lucene - Core
> Issue Type: Bug
> Affects Versions: 7.1
> Reporter: Zsolt Gyulavari
> Priority: Major
> Attachments: LUCENE-8587.patch
>
>
> GeoComplexPolygon.equals method checks equality with own testPoint1 field
> instead of the other.testPoint1.
--
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
