lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-4157) Improve Spatial Testing
Date Wed, 27 Jun 2012 05:26:44 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13401974#comment-13401974
] 

David Smiley commented on LUCENE-4157:
--------------------------------------

RE QuadPrefixTree, I'll see if I can reproduce your test errors.  I'm not surprised if the
QuadPrefixTree.MAX_LEVELS_POSSIBLE is perhaps too big (notice the comment at it's declaration
"not really sure how big this should be".  Assuming the default 12 levels pass, I think we
can find a safer max number to use for the time being that is less than 50, and maybe one
day when we have time we can confidently determine exactly what it can support.  I venture
to guess it might be similar to the mantissa of a double which is 53, but perhaps not or maybe
it's half that or something.  FYI about 26 is needed for ~1meter accuracy.  If a non-geo scenario
is needed, then who knows what your requirements might be.

RE Testing of TermQueryPrefixGridStrategy, I agree that its tests are too minimal, in Lucene
spatial. FWIW, I'm about to update a patch to SOLR-3304 that tests a variety of strategies
against the same test code (based on test code from Solr 3 spatial filter tests).  TermQueryPrefixGridStrategy
passes fine.

I definitely welcome any input on making the tests better overall.  It's a bit of a challenge
because there are a variety of strategies, and some like TwoDoublesStrategy are known to not
yet support certain geo cases like the poles (if I recall).  I'm not sure if the idea of a
test file of query cases was your idea or Ryan's (e.g. cities-IsWithin-BBox), but instead
or in addition, I like the idea of automatically generating random data and queries, and then
double checking search results against a simple brute force algorithm.

If you don't feel any better about these two classes, then I like your suggestion of not releasing
them in 4.0 and leave in trunk.
                
> Improve Spatial Testing
> -----------------------
>
>                 Key: LUCENE-4157
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4157
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: modules/spatial
>            Reporter: David Smiley
>            Assignee: David Smiley
>            Priority: Critical
>             Fix For: 4.0
>
>         Attachments: LUCENE-4157_Improve_Lucene_Spatial_testing_p1.patch
>
>
> Looking back at the tests for the Lucene Spatial Module, they seem half-baked.  (At least
Spatial4j is well tested).  I've started working on some improvements:
> * Some tests are in an abstract base class which have a subclass that provides a SpatialContext.
The idea was that the same tests could test other contexts (such as geo vs not or different
distance calculators (haversine vs vincenty) but this can be done using RandomizedTesting's
nifty parameterized test feature, once there is a need to do this.
> * Port the complex geohash recursive prefix tree test that was developed on the Solr
side to the Lucene side where it belongs.
> And some things are not tested or aren't well tested:
> * Distance order as the query score
> * Indexing shapes other than points (i.e. shapes with area / regions)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message