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

David Smiley commented on LUCENE-4922:
--------------------------------------

Thanks for your interest in this John. You've gotten the ball rolling. I 
confess I don't do any byte or bit manipulation work so it'll take some time to 
fully digest what's going on in this code which uses a lot of it.  More 
comments would have helped. It might be interesting to look at how Lucene Trie 
floating point fields work.  Thanks for the reference to efficient ways to 
interleave bits; I'll re-post here for convenient reference: 
http://www-graphics.stanford.edu/~seander/bithacks.html#InterleaveBMN
 (there are 2 approaches there).  I'm not sure when I'll have significant time 
to contribute more directly other than add to the conversation.
                
> A SpatialPrefixTree based on the Hilbert Curve and variable grid sizes
> ----------------------------------------------------------------------
>
>                 Key: LUCENE-4922
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4922
>             Project: Lucene - Core
>          Issue Type: New Feature
>          Components: modules/spatial
>            Reporter: David Smiley
>            Assignee: David Smiley
>              Labels: gsoc2013, mentor, newdev
>         Attachments: HilbertConverter.zip
>
>
> My wish-list for an ideal SpatialPrefixTree has these properties:
> * Hilbert Curve ordering
> * Variable grid size per level (ex: 256 at the top, 64 at the bottom, 16 for 
> all in-between)
> * Compact binary encoding (so-called "Morton number")
> * Works for geodetic (i.e. lat & lon) and non-geodetic
> Some bonus wishes for use in geospatial:
> * Use an equal-area projection such that each cell has an equal area to all 
> others at the same level.
> * When advancing a grid level, if a cell's width is less than half its 
> height. then divide it as 4 vertically stacked instead of 2 by 2. The point 
> is to avoid super-skinny cells which occurs towards the poles and degrades 
> performance.
> All of this requires some basic performance benchmarks to measure the effects 
> of these characteristics.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Reply via email to