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-4922) A SpatialPrefixTree based on the Hilbert Curve and variable grid sizes
Date Fri, 12 Apr 2013 13:22:16 GMT

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

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

Thanks for your interest Hatim!

Your assessment of just needing to extend SpatialPrefixTree is mostly correct.  It also involves
implementing Cell (formerly known as Node) which is tightly related.  There are lots of potential
optimizations here.  As part of this task, modifying SpatialPrefixTree & Cell itself is
absolutely okay if we find better (more optimized) ways of doing things, though we need to
retain backwards compatibility with the two existing SpatialPrefixTree implementations --
geohash & quad.  *If* retaining that backwards compatibility turns out to be too constraining
on making this SPT be even better, then we could make SPT an interface.  But the general API
of SPT & Cell should be the same as it is now.  

What will help in this task is to know that there are extensive tests of the PrefixTree based
spatial search strategies, such that if supplying a new SPT causes a failure, then you know
you've got a bug ;-).  But there are few unit level tests of the SPT itself, and so knowing
precisely what is broken could be hard.

You are correct that the bonus wishes are purely optional optimizations, time permitting.
 Very optional; in general I want to see that without these optimizations that the SPT is
as good as it can reasonably be.  It _may_ turn out that these geo specific optimizations
have extra runtime costs (such as calculating the sin() a lot or complexity that make it not
worthwhile; I don't know.
                
> 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
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message