[jira] Created: (SOLR-773) Incorporate Local Lucene/Solr

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.

    [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631963#action_12631963 ]

Yonik Seeley commented on SOLR-773:
-----------------------------------

I haven't yet looked at the contributions (but I did read the whitepaper).

It seems like we want lat+lon in the same field value.  That will remove the need for any other mechanism to correlate the two (what lat goes with what lon) and will allow future indexing mechanisms that operate on both values at once.

Do we need a new basic output type (in addition to str, int, long, etc)?  For now perhaps we should just use a string representation?
 <str name="my_house">12.345,-67.89</str>  
  or in JSON
"my_house":"12.345,-67.89"

So breaking things down, it seems like we basically need to be able to:
1) filter by a bounding box
2) filter by a geo radius (impl could first get the bounding box and narrow within that...)
3) sort by distance
4) return the distance

It also seems like there could be an opportunity to make much/most of this generic (not specific to geosearch).

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

    [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631992#action_12631992 ]

Ryan McKinley commented on SOLR-773:
------------------------------------

LocalLucene/Solr are currently designed to do exactly points 1-4.

As for storing lat/lon in a single field... that sounds really interesting.  Currently the local lucene stuff uses two fields and [NumberUtils.java|http://svn.apache.org/repos/asf/lucene/solr/trunk/src/java/org/apache/solr/util/NumberUtils.java] to index/store the distance.  It does a lot of good work to break various bounding box levels into tokens and only performs math on the minimum result set.

We should consider a geohash field type: http://en.wikipedia.org/wiki/Geohash to store lat/lon in a single string.  This has some really interesting features that are ideal for lucene.  In particular, checking if a point is within a bounding box is simply a lexicographic range query.  

Here is a public domain python geohash implementation: http://mappinghacks.com/code/geohash.py.txt 

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

    [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632053#action_12632053 ]

Ryan McKinley commented on SOLR-773:
------------------------------------

We should also consider the OGC standard "Well Known Text":
http://en.wikipedia.org/wiki/Well-known_text

This is what MySQL and PostGIS use to enter GIS data

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

[Jason Rutherglen-2]

Does Geohash enable range based queries?  It's unclear from the wiki site.

Can we do something like this
http://code.google.com/apis/base/attrs-queries.html#LocDatQuer  I
would rather see SOLR go in the direction of being compatible with
GData and GBase and invent more unique things, unless they are better
somehow.

GBase has a notation for doing function queries as well that we should
build into SOLR, current SOLR function queries really are very
non-intuitive for me and I spend a lot of time each time trying to
figure out how to do them.

Check this stuff out.
http://code.google.com/apis/base/ranking-lang-spec.html#functions  I'm
not sure we need to create something quite this complex.  However, I
would like a way to do something like this without having to reboot
the server.  I personally thing this is best implemented using dynamic
classloading.  If people find that interesting, then we could look at
scripting.  I'm not a big fan of scripting because it's not object
oriented, it's not maintainable, scripts always grow and get too
complex to read so that when new people take a look at it the ramp up
time is high.  With dynamic classes, all of the functionality of what
is available is there.  No need to create new script functions, test
them out, load them, fix bugs and all that.

On Wed, Sep 17, 2008 at 7:01 PM, Ryan McKinley (JIRA) <jira@...> wrote:

>
>    [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631992#action_12631992 ]
>
> Ryan McKinley commented on SOLR-773:
> ------------------------------------
>
> LocalLucene/Solr are currently designed to do exactly points 1-4.
>
> As for storing lat/lon in a single field... that sounds really interesting.  Currently the local lucene stuff uses two fields and [NumberUtils.java|http://svn.apache.org/repos/asf/lucene/solr/trunk/src/java/org/apache/solr/util/NumberUtils.java] to index/store the distance.  It does a lot of good work to break various bounding box levels into tokens and only performs math on the minimum result set.
>
> We should consider a geohash field type: http://en.wikipedia.org/wiki/Geohash to store lat/lon in a single string.  This has some really interesting features that are ideal for lucene.  In particular, checking if a point is within a bounding box is simply a lexicographic range query.
>
> Here is a public domain python geohash implementation: http://mappinghacks.com/code/geohash.py.txt
>
>> 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.
>
>

[ryantxu]

On Sep 18, 2008, at 9:28 AM, Jason Rutherglen wrote:

> Does Geohash enable range based queries?  It's unclear from the wiki  
> site.
>

yes -- if you munge the algorithm a bit, finding points within a  
region is a lexographic range query.

This alteration was developed to support bounding box queries in big  
table.  Big table does not let you perform multiple operations on  
multiple fields in a single query, so you have to figure out how to do  
it with one:

http://labs.metacarta.com/blog/27.entry/geographic-queries-on-google-app-engine/

I have not worked with it yet, but it seem like it has some nice  
characteristics for lucene indexes



> Can we do something like this
> http://code.google.com/apis/base/attrs-queries.html#LocDatQuer  I
> would rather see SOLR go in the direction of being compatible with
> GData and GBase and invent more unique things, unless they are better
> somehow.
>

are you just talking about the query syntax?

Yes, we should just use something that others are already doing...

    [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632239#action_12632239 ]

patrick o'leary commented on SOLR-773:
--------------------------------------

Hey guys

Placing both lat and long in the same field is good when used internally, the majority of users
of localsolr have separate fields representing lat long, so make sure the representation
does not effect the original document.

WKT uses point as the naming convention for single item's and I'd suggest that rather than just str, it would
also be nice to get to a KML wt format as well.  I've done some stuff integrating in mapping components and
KML goes down real well.

However be aware as soon as you start supporting WKT, you will be asked for ERSI support, and poly support,
ray tracing, collision and a lot more fun things :-)

P

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

[Jason Rutherglen-2]

Too many acronyms in there.  What is the WKT used for?  Storing the
data?  The schema?  I am confused by the wikipedia text about WKT.

On Thu, Sep 18, 2008 at 11:08 AM, patrick o'leary (JIRA)
<jira@...> wrote:

>
>    [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632239#action_12632239 ]
>
> patrick o'leary commented on SOLR-773:
> --------------------------------------
>
> Hey guys
>
> Placing both lat and long in the same field is good when used internally, the majority of users
> of localsolr have separate fields representing lat long, so make sure the representation
> does not effect the original document.
>
> WKT uses point as the naming convention for single item's and I'd suggest that rather than just str, it would
> also be nice to get to a KML wt format as well.  I've done some stuff integrating in mapping components and
> KML goes down real well.
>
> However be aware as soon as you start supporting WKT, you will be asked for ERSI support, and poly support,
> ray tracing, collision and a lot more fun things :-)
>
> P
>
>> 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.
>
>

[Jason Rutherglen-2]

> Placing both lat and long in the same field is good when used internally

The initial filtered range query should be much faster this way.  Is
it possible to then extract the lat and long out of the geohash for
the narrowing portion?

On Thu, Sep 18, 2008 at 11:08 AM, patrick o'leary (JIRA)
<jira@...> wrote:

>
>    [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632239#action_12632239 ]
>
> patrick o'leary commented on SOLR-773:
> --------------------------------------
>
> Hey guys
>
> Placing both lat and long in the same field is good when used internally, the majority of users
> of localsolr have separate fields representing lat long, so make sure the representation
> does not effect the original document.
>
> WKT uses point as the naming convention for single item's and I'd suggest that rather than just str, it would
> also be nice to get to a KML wt format as well.  I've done some stuff integrating in mapping components and
> KML goes down real well.
>
> However be aware as soon as you start supporting WKT, you will be asked for ERSI support, and poly support,
> ray tracing, collision and a lot more fun things :-)
>
> P
>
>> 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.
>
>

[ryantxu]

WKT is just a standard way to describe geometry.  There *many* other  
options, but WKT is a simple text based one that is used in other gis  
databases, including mysql and PostGIS:
  http://dev.mysql.com/doc/refman/5.0/en/gis-wkt-format.html

I'm not saying we *should* use it, just that we should keep it in mind.

If we were able to have an arbitrary geometry type, WKT would be a  
good option to put in our xml documents to populate the data.

<str name="shape">POLYGON((0 0,10 0,10 10,0 10,0 0),(5 5,7 5,7 7,5 7,  
5 5))</str>

However, discussion of arbitrary shapes may be a ways off... for now  
if we get points and bounding boxes, i think we are in good shape :)


On Sep 18, 2008, at 11:49 AM, Jason Rutherglen wrote:

> Too many acronyms in there.  What is the WKT used for?  Storing the
> data?  The schema?  I am confused by the wikipedia text about WKT.
>
> On Thu, Sep 18, 2008 at 11:08 AM, patrick o'leary (JIRA)
> <jira@...> wrote:
>>
>>   [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632239 
>> #action_12632239 ]
>>
>> patrick o'leary commented on SOLR-773:
>> --------------------------------------
>>
>> Hey guys
>>
>> Placing both lat and long in the same field is good when used  
>> internally, the majority of users
>> of localsolr have separate fields representing lat long, so make  
>> sure the representation
>> does not effect the original document.
>>
>> WKT uses point as the naming convention for single item's and I'd  
>> suggest that rather than just str, it would
>> also be nice to get to a KML wt format as well.  I've done some  
>> stuff integrating in mapping components and
>> KML goes down real well.
>>
>> However be aware as soon as you start supporting WKT, you will be  
>> asked for ERSI support, and poly support,
>> ray tracing, collision and a lot more fun things :-)
>>
>> P
>>
>>> 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.
>>
>>

[ryantxu]

On Sep 18, 2008, at 11:53 AM, Jason Rutherglen wrote:

>> Placing both lat and long in the same field is good when used  
>> internally
>
> The initial filtered range query should be much faster this way.  Is
> it possible to then extract the lat and long out of the geohash for
> the narrowing portion?

correct -- depending on the hash length, you get greater precision.  
With a 10 character long hash, you get 2 foot precision.

I'm not sure how we would do the implementation details, but I'm  
imagining the stored value would (could) be the exact input string and  
an analyzer generates geohash token.  and maybe stores the exact  
location as  payload.  Then a location query would do a range query on  
the proper geohash, and then if necessary do real math on the exact  
locations -- either from a payload or stored field...

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

    [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632327#action_12632327 ]

patrick o'leary commented on SOLR-773:
--------------------------------------

I believe you guys are using a branch of the code as we were looking at using the mapquest sids.

Both versions are solving the same basic problem, creating a sudo quad tree implementation.
com.pjaol was the initial API I built, com.mapquest is donated to us by MapQuest.

Both versions work by flattening out the earth onto a series of grids, the grids get progressively smaller
with each _localTierN, in the MapQuest version there is a notion of zooming.
Some quick info graphics here:
http://www.nsshutdown.com/projects/lucene/whitepaper/locallucene_v2.html

The differences are, com.pjaol uses pretty exact measurements, the flattening method is based on something
called a sinusoidal projection, where I translate lat / longs to x,y coordinates which provide an equal spaced projection on a flat surface. Then I use GeoTools for the actual precise distance calculation.

It comes at a slight performance cost to be that exact, but users have a need for it.

The com.mapquest code, does a direct conversion to cartesian x,y coordinate from lat / long, encodes and generates sids and uses a standard great circle equation for distance calculation. So not as convoluted.
It does come at a slight accuracy cost - but only in a few places, Greenland, New Zealand, some places around the poles and equator.

So it's perfect for web based applications as the +/- error differential is small enough to be acceptable for most users.
There is however a good audience for local lucene, who use it for more exact calculation, even down to the meter range. It's also used by some research groups for non-land based activities hence the desire to retain the exactness.


 

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

    [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632356#action_12632356 ]

Ryan McKinley commented on SOLR-773:
------------------------------------

Thanks for the clarification...

>
> Then I use GeoTools for the actual precise distance calculation.
>

FYI, in the initial apache checking, I'm removing the GeoTools dependancy (it is LGPL)

I'd like to make the distanceHandler logic for distance calculations pluggable so its easy to link to GeoTools when necessary.

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

    [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632358#action_12632358 ]

patrick o'leary commented on SOLR-773:
--------------------------------------

Yep agree

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

     [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

patrick o'leary updated SOLR-773:
---------------------------------

    Attachment: spatial-solr.tar.gz

Port of LocalSolr to spatial-solr for inclusion in solr's contrib.
Provides geographical based search capabilities to solr

> 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
>         Attachments: 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.

    [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660219#action_12660219 ]

Ryan McKinley commented on SOLR-773:
------------------------------------

Thanks patrick!

Two things stick out to me:

1. LocalSolrQueryComponent duplicates most of the code from SolrQueryComponent.  Perhaps a better solution would be to have a custom [QParser|http://lucene.apache.org/solr/api/org/apache/solr/search/QParser.html] that builds the query and then add a SearchComponent to the chain to augment the results with the calculated distance.

2. (related)  If the query is implemented as a QParser, we would just need to implement:
{code:java}
  public SortSpec getSort(boolean useGlobalParams) throws ParseException
{code}
rather then use the LocalSolrSortParser.

> 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
>         Attachments: 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.

    [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660220#action_12660220 ]

Ryan McKinley commented on SOLR-773:
------------------------------------

Not a big deal, but it looks like the List<CartesianTierPlotter> plotters could be initialized once for the Factory then reused rather then initializing it for each request.

> 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
>         Attachments: 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.

     [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan McKinley updated SOLR-773:
-------------------------------

    Attachment: SOLR-773-local-lucene.patch

Here is a (totally untested) patch that uses QParser.

This requires some small tweeks to the QParser class to make the sort parsing extensible.

Take a look and see what you think...

> 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
>         Attachments: SOLR-773-local-lucene.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.

     [ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan McKinley updated SOLR-773:
-------------------------------

    Attachment: SOLR-773-local-lucene.patch

This version runs, but still no tests.

I added spatial stuff to the example configs, but I'm not sure I like that long term.  The examples are getting a bit over cluttered.

http://localhost:8983/solr/select?q=*:*&qt=geo&lat=40&long=-75&radius=99

> 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
>         Attachments: SOLR-773-local-lucene.patch, SOLR-773-local-lucene.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.