[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
