[
https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632284#action_12632284
]
Ryan McKinley commented on SOLR-773:
------------------------------------
I'm looking over the code grant now... (thanks again!)
There are two implementations of LocalUpdateProcessorFactory:
com.mapquest
com.pjaol
They do slightly different things...
* The pjaol version creates a CartesianTierPlotter and then builds a bunch of
fields for each level: _localTierN
* The mapquest verison puts a bunch of spatial tokens (sid/SpatialIndex) into
a single field.
Any pointers on why one approach over the other? Do they solve the same
problem?
The mapquest version seems like it could be easily replaced with an Analyzer...
perhaps one that takes a single lat/lon string:
<str name="location">12.345 -67.89</str>
and then generates tokens for it. All the plumbing to encode the data in an
updateProcessor then decode it in a FieldType seems a bit awkward.
> 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
> Priority: Minor
>
> 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.
