You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Varun V Shenoy (JIRA)" <ji...@apache.org> on 2014/03/03 08:02:20 UTC
[jira] [Commented] (LUCENE-4922) A SpatialPrefixTree based on the
Hilbert Curve and variable grid sizes
[ https://issues.apache.org/jira/browse/LUCENE-4922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917781#comment-13917781 ]
Varun V Shenoy commented on LUCENE-4922:
-----------------------------------------
I am Varun and I will be really interested to pursue this as my GSOC2014 project. Any documentation, references, papers etc on this topic will be extremely helpful.
> 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: gsoc2014
> 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 was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [jira] [Commented] (LUCENE-4922) A SpatialPrefixTree based on the
Hilbert Curve and variable grid sizes
Posted by Hatim Hakeel <ha...@gmail.com>.
Hi,
I have provided a link to the proposal I prepared last year for the benefit
of anyone looking for related background material like documentation,
papers etc. Hope it would be helpful.
http://hatimhakeel.blogspot.com/2014/03/this-is-my-gsoc-2013-project-proposal.html
On Mon, Mar 3, 2014 at 12:32 PM, Varun V Shenoy (JIRA) <ji...@apache.org>wrote:
>
> [
> https://issues.apache.org/jira/browse/LUCENE-4922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13917781#comment-13917781]
>
> Varun V Shenoy commented on LUCENE-4922:
> -----------------------------------------
>
> I am Varun and I will be really interested to pursue this as my GSOC2014
> project. Any documentation, references, papers etc on this topic will be
> extremely helpful.
>
> > 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: gsoc2014
> > 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 was sent by Atlassian JIRA
> (v6.2#6252)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>