[
https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708680#action_12708680
]
Grant Ingersoll commented on SOLR-773:
--------------------------------------
{quote}
1) What is the goal we want to achieve?
* Provide a first iteration of a geographical search entity to SOLR
* Bring an external popular plugin, in out of the cold into ASF and SOLR,
helps solr users out, increases developers from 1 to many.
{quote}
Agreed on the first, not 100% certain on the second. On the second, this issue
is the gate keeper. If people reviewing the patch feel there are better ways
to do things, then we should work through them before committing. What you are
effectively seeing is an increase in the developers working on from 1 to many,
it's just not on committed code.
{quote}
2) What is the level of commitment, and road map of spatial solutions in lucene
and solr?
* The primary goal of SOLR is as a text search engine, not GIS search,
there are other and better ways to do that
without reinventing the wheel and shoe horn-ing it into lucene.
(e.g. persistent doc id mappings that can be referenced outside of
lucene, so things like postGis and other tools can be used)
* We can never fully solve everyone's needs at once, lets start with what
we have, and iterate upon it.
* I'm happy for any improvements as long as they keep to two goals A. don't
make it stupid B. don't make it complex.
{quote}
On the first point, I don't follow. Isn't LocalLucene and LocalSolr, just
exactly a GIS search capability for Lucene/Solr? I'm not sure if I would
categorize it as shoe-horning. There are many things that Lucene/Solr can
power, GIS search is one of them. By committing this patch (or some
variation), we are saying Solr is going to support GIS search. Of course,
there are other ways to do it, but that doesn't preclude it from L/S. The
combination of text search plus GIS search is very powerful, as you know.
Still, I think Yonik's main point is why reinvent the wheel when it comes to
things like distributed search and the need for custom code for indexing, etc.
when they likely can be handled through function queries and field types and
therefore all of Solr's current functionality would just work. The other
capabilities (like sorting by a FunctionQuery) is icing on the cake that helps
solve other problems as well.
Totally agree on the other points. Also very cool to see the benchmarking info.
> Incorporate Local Lucene/Solr
> -----------------------------
>
> Key: SOLR-773
> URL: https://issues.apache.org/jira/browse/SOLR-773
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Grant Ingersoll
> Priority: Minor
> Attachments: lucene.tar.gz, SOLR-773-local-lucene.patch,
> SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch,
> SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773.patch,
> SOLR-773.patch, spatial-solr.tar.gz
>
>
> Local Lucene has been donated to the Lucene project. It has some Solr
> components, but we should evaluate how best to incorporate it into Solr.
> See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
