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/08/21 04:29:33 UTC
[jira] [Comment Edited] (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=14104962#comment-14104962 ]
Varun V Shenoy edited comment on LUCENE-4922 at 8/21/14 2:28 AM:
------------------------------------------------------------------
As my GSOC project, I have implemented a spatial prefix tree with the above mentioned features. This tree, named "FlexPrefixTree" has the following features.
- FPT performs 25% faster for circular queries and 36% faster for rectangular queries compared to QuadTree. 110% faster for circular queries and 70% faster for rectangular queries compared to GeoHashPrefixTree. This is for approximately 1m precision.
- The implementation should be easy to adapt to a future integer based spatial application when floating point isn’t desired.
- Very compact index sizes are possible. Upto 14% lessar than GeoHashPrefixTree and 60% lessar than QuadPrefixTree implementations.
- Flexible trade-offs between index size and search speed. Variable number of sub-cells allows us to achieve very small index sizes.
- FPT internally uses int, to speed up spatial calculations.
- Due to reuse of a FlexCell per level, BytesRef per FPT, Rectangle shape per level, FlexPrefixTreeIterator per level and compact index sizes, we could achieve upto 48% reduction in average used memory and 38% in average total used memory.
was (Author: varunshenoy):
As my GSOC project, I have implemented a spatial prefix tree with the above mentioned features. This tree, named "FlexPrefixTree" has the following features.
- FPT performs 25% faster for circular queries and 36% faster for rectangular queries.
- The implementation should be easy to adapt to a future integer based spatial application when floating point isn’t desired.
- Very compact index sizes are possible. Upto 14% lessar than GeoHashPrefixTree and 60% lessar than QuadPrefixTree implementations.
- Flexible trade-offs between index size and search speed. Variable number of sub-cells allows us to achieve very small index sizes.
- FPT internally uses int, to speed up spatial calculations.
- Due to reuse of a FlexCell per level, BytesRef per FPT, Rectangle shape per level, FlexPrefixTreeIterator per level and compact index sizes, we could achieve upto 48% reduction in average used memory and 38% in average total used memory.
> 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