[
https://issues.apache.org/jira/browse/LUCENE-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15224929#comment-15224929
]
Robert Muir commented on LUCENE-7168:
-------------------------------------
we can start by just testing that the query's logic within x/y/z space is
correct (e.g. consistent with what would happen if it just returned
CELL_CROSSES_QUERY from compare() for every call)?
This at least tells us that compare() is consistent with visit().
Then separately, we test that 2D -> 3D conversion works as we expect (these can
be unit tests for GeoPoint.java).
And separately test that visit() for a single point really does what we think
it should (maybe tests against specific 3D shapes, etc)
Unfortunately this means we can't reuse all our 2D testing infra for Geo3D, but
I think it would be complicated if we tried?
> Remove geo3d test leniency
> --------------------------
>
> Key: LUCENE-7168
> URL: https://issues.apache.org/jira/browse/LUCENE-7168
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Michael McCandless
> Attachments: LUCENE-7168.patch, LUCENE-7168.patch
>
>
> Today the test hides possible failures by leniently handling quantization
> issues.
> We should fix it to do what geo2d tests now do: pre-quantized indexed points,
> but don't quantize query shapes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]