[
https://issues.apache.org/jira/browse/LUCENE-7160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221389#comment-15221389
]
Michael McCandless commented on LUCENE-7160:
--------------------------------------------
+1
> LatLonPoint quantization should use same rounding mode as GeoPointField
> -----------------------------------------------------------------------
>
> Key: LUCENE-7160
> URL: https://issues.apache.org/jira/browse/LUCENE-7160
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Attachments: LUCENE-7160.patch
>
>
> Both of these fields quantize doubles in a lossy way, but GeoPoint rounds
> towards negative infinity (because all values get shifted to positive space
> first), whereas LatLonPoint currently rounds towards zero.
> At the same time they share the same basic logic for e.g. tree traversal and
> same basic tests: so it creates confusion that they round differently.
> Especially since e.g. LatLonPoint does some operations in binary/integer
> space (some of these optimizations such as its box query are currently buggy
> for edge cases, and tests are lenient as TODO, another issue, may or may not
> impact GeoPoint, it at least tries harder).
> I think LatLonPoint should round down to be more like GeoPoint here? By the
> way, doing this also gives more consistency, it reduces the difference
> between the two implementations in e.g. openstreetmaps searching (distance
> query benchmark now differs by only 4 hits...)
> This quantization makes things complicated to reason about. I understand the
> advantages it brings but I think along with that comes the responsibility of
> us handling edge cases better. I don't think we do well at this today...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
