lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (Issue Comment Edited) (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (LUCENE-3795) Replace spatial contrib module with LSP's spatial-lucene module
Date Thu, 16 Feb 2012 18:39:04 GMT

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

David Smiley edited comment on LUCENE-3795 at 2/16/12 6:38 PM:
---------------------------------------------------------------

h3. Features
The main goals of LSP is to be a great framework to plug in spatial search algorithms and
shape implementations.  It of course includes good implementations of these key abstractions.
 Here are some key features, most of which related to using RecursivePrefixTreeStrategy with
geohashes:

* Multi-valued fields
* Index shapes that have area (e.g. not just points)
  Tests have yet to be added for this.
* No special RAM caches for filtering, just standard term index
  Unlike Solr's LatLonType which needs to cache all points in RAM if the query shape is a
circle
* Fast filtering
  Although SOLR-2155 has been proven, technically LSP hasn't.  3rd party anecodes re-inforce
this claim.
* Multi-value sort
  Based on closest index point to center of query shape.  Distances are returned via the score
of an LSP query.
* Specify precision of query shape and index shape
  Thereby allowing for faster filtering tunable precision
* Multiple distance algorithms:
** Spherical: Law of Cosines, Haversine, Vincenty
** Cartesian: Pythagorean Theorem
* Cartesian (2d flat) & Geospatial sphere models

h3. Todo
There are many things I want to improve and add but in my view there isn't anything truly
making this non-committable.  Chris has raised concerns that the other committers will want
to see benchmark results before accepting this.  I'll leave that for you (the other committers)
to decide.

And I also heard that some committers are unsure wether Lucene should have a spatial module
at all.  However there is certainly demand for it, at least at the Solr level.  Furthermore,
there are some non-spatial use cases of the spatial module.  One interesting use-case is RecursivePrefixTreeStrategy's
(RPTS) unique ability to index shapes with area.  If you had a requirement to index a variable
number of time durations, then unlike Lucene's trie numeric support in which only discrete
numbers are supported, RPTS could be used with x being time and y being unused. Buy the way,
PrefixTree and Trie are synonymous words.
                
      was (Author: dsmiley):
    h3. Features
The main goals of LSP is to be a great framework to plug in spatial search algorithms and
shape implementations.  It of course includes good implementations of these key abstractions.
 Here are some key features, most of which related to using RecursivePrefixTreeStrategy with
geohashes:

* Multi-valued fields
* Index shapes that have area (e.g. not just points)
  Tests have yet to be added for this.
* No special RAM caches for filtering, just standard term index
  Unlike Solr's LatLonType which needs to cache all points in RAM if the query shape is a
circle
* Fast filtering
  Although SOLR-2155 has been proven, technically LSP hasn't.  3rd party anecodes re-inforce
this claim.
* Multi-value sort
  Based on closest index point to center of query shape.  Distances are returned via the score
of an LSP query.
* Specify precision of query shape and index shape
  Thereby allowing for faster filtering tunable precision
* Multiple distance algorithms:
** Spherical: Law of Cosines, Haversine, Vincency
** Cartesian: Pythagorean Theorem
* Cartesian (2d flat) & Geospatial sphere models

h3. Todo
There are many things I want to improve and add but in my view there isn't anything truly
making this non-committable.  Chris has raised concerns that the other committers will want
to see benchmark results before accepting this.  I'll leave that for you (the other committers)
to decide.

And I also heard that some committers are unsure wether Lucene should have a spatial module
at all.  However there is certainly demand for it, at least at the Solr level.  Furthermore,
there are some non-spatial use cases of the spatial module.  One interesting use-case is RecursivePrefixTreeStrategy's
(RPTS) unique ability to index shapes with area.  If you had a requirement to index a variable
number of time durations, then unlike Lucene's trie numeric support in which only discrete
numbers are supported, RPTS could be used with x being time and y being unused. Buy the way,
PrefixTree and Trie are synonymous words.
                  
> Replace spatial contrib module with LSP's spatial-lucene module
> ---------------------------------------------------------------
>
>                 Key: LUCENE-3795
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3795
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: modules/spatial
>            Reporter: David Smiley
>            Assignee: David Smiley
>             Fix For: 4.0
>
>
> I propose that Lucene's spatial contrib module be replaced with the spatial-lucene module
within Lucene Spatial Playground (LSP).  LSP has been in development for approximately 1 year
by David Smiley, Ryan McKinley, and Chris Male and we feel it is ready.  LSP is here: http://code.google.com/p/lucene-spatial-playground/
 and the spatial-lucene module is intuitively in svn/trunk/spatial-lucene/.
> I'll add more comments to prevent the issue description from being too long.

--
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