[
https://issues.apache.org/jira/browse/LUCENE-7165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15226557#comment-15226557
]
Robert Muir commented on LUCENE-7165:
-------------------------------------
the subtraction in encode yes (and addition in decode). I don't understand why
we need those?
Maybe we should just reuse the latlonpoint encoding but then interleave those
bits? This one just has divide or multiply and makes it easier have consistent
rounding. If we do other intermediate calculations this kind of stuff gets
hairy.
If we want to make it hairy with additional stuff, thats ok, but we should
still try to achieve goals like stability, well-defined rounding, no overflows,
etc. random.nextDouble() * 360 + 180 is not good enough in tests to find bugs
in these issues.
> Return GeoPointField Encoding to use full 64 bit space
> -------------------------------------------------------
>
> Key: LUCENE-7165
> URL: https://issues.apache.org/jira/browse/LUCENE-7165
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Nicholas Knize
> Attachments: LUCENE-6996.patch
>
>
> This was originally done in LUCENE-6710 but then reverted due to issues with
> GeoHash encoding (which has since been removed). This issue will revert the
> GeoPoint encoding back to full 64 bit space which will synchronize
> quantization TOLERANCE between {{LatLonPoint}} and {{GeoPointField}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
