[ 
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]

Reply via email to