LocalSolr Support

subscribe

Hey. Any thoughts on this?

Will they add the module to the hosted Acquia version?

Thanks.

Yes. We absolutely will :)

Mike O'Connor has a working implementation of this. Contact him before anyone begins a parallel effort.

Robert can you contact Mike to post his code in here? We're about to delve into it as well...

Here's what I have so far.

location_solr.zip is a very basic module to add a node's primary location field to the solr index. It needs to be expanded to support multiple locations.

localsolr.zip the custom schema.xml and solrconfig.xml I used on my tomcat server. I haven't really had time to clean this up, but everything works.

gz_solr.zip a simple proof of concept(ugly code, haven't had a chance to clean it up) to create a directory page with faceted search based on a geo query. you can see this in action @ http://gz.commerceguys.com/directory, and play with the query here http://dev2.commerceguys.com:8080/localsolr/select?long=-122.5&lat=37.5&radius=20&sort=geo_distance%20asc&qt=geo&q=(type:business)&fl=id,nid,lat,lng,geo_distance

Notice the geo_distance field, which calculates the distance from the coordinates you provide, to the location.

I have ran into a few problems along the way.
It doesn't seem to support the fq parameter.
Without modifying the end tier to get reasonably accurate results(within 5 miles)
localsolr doesn't seem to support geo searches based on polygons.

subscribe

mikejoconnor: Can you re-submit this as a patch please?

Thanks,
Jacob

http://3281d.com/2009/03/27/death-to-subscribe-comments

This looks like Drupal could have some really cool functionality for building a faceted directory out the box without a lot of work.

I am very new to SOLR, used it briefly on a Drupal project where we had 5 days to get Drupal to show nodes as well as Magento search results within a search query, this included reading up on SOLR and setting up Tomcat etc (luckily I have Java experience).

Anyway back on to topic. Mikejoconnor you map you the longitude / latitude in the schema xml manually which works as a proof of concept. What I think would be more useful if we created a CCK field to store the longitude / latitude (some modules already out there to use as a base). The only problem I see would be setting the correct data types for the cck lng/lat fields in the solr schema without a user manually updating Solr each time they add the geospartial cck field as currently the field names are hardcoded...but cck fieldnames are dynamic.

Another issue I see is how a user gets the lng/lat to start with. I was thinking maybe running a second core in SOLR with a dataset of locations with corresponding lng / lat. My idea is a user would enter a location and SOLR would return suggestions for a user to select, the document selected would contain the lng/lat to store in the nodes cck field. A free dataset with world wide data I just found and looks interesting is at http://download.geonames.org/export/ . I got this idea of using SOLR to get the spartial data for a location after reading http://www.gissearch.com/Query_Location_Chapter (which by coincidence is a Drupal site :) ) . If anyone has any comments on this it would be appreciated. I guess running this on a separate core would be the better option so I don't have to filter out town data in the main Drupal search results?

If anyone has any comments / suggestions on my ideas it would be much appreciated. SOLR / Lucene is all new to me and I'm trying to find out as much as I can without having had enough time to sit down and spend a great deal of time playing about with it. Advice on good books, resources, blogs are also appreciated (got Lucene in action 2nd addition on order).

Ok had a few hours to play today.

-Downloaded and setup tomcat.
-Downloaded solr 1.4 nightly snapshot.
-Setup a clean install of drupal with latest build of the solr module
-Deployed solr using jndi to map solr-home.
-Copied schema.xml + solrconfig.xml to solr-home/conf form the apachesolr module
-Downloaded latest versions of solr local + lucene local from http://sourceforge.net/projects/locallucene/ and placed into solr-home/lib
-Downloaded geotools 2.1.1 to solve some class not found errors in solr and placed into solr-home/lib http://maven.geotools.fr/repository/org/opengis/geoapi-nogenerics/
-Updated the solrconfig.xml + schema.xml as per the readme in solr local (see attached files)
-Download the Location module (had to fix a view bugs)

Enabling the Location node module let me create a new node type called bussiness and the module adds the address + lng/lat fields. After fixing a few issues (http://drupal.org/node/411360) I got the module to get the lng/lat using the google maps api. I was impressed once the module worked how simple it was to create a business nodetype, add some taxonomy and have the foundations of a basic directory site.

I also noticed the hooks on the homepage of the solr module. This means mapping the locations module fields to the one we set up in the solr config is very easy:

In location_node.module it's a case of adding

<?php
function location_node_apachesolr_update_index(&$document, $node) {    
   if($node->location){
      $document->lat = $node->location['latitude'];
      $document->lng = $node->location['longitude'];
   }
}
?>

I also noticed the solr module has hooks for handling cck fields so I guess the Location module's cck field can be trivialy mapped to the solr local config.

As you can see, things are far to easy. Now the problem...
The apachesolr module is using solr 1.4 . I am getting a 'java.lang.NoSuchFieldError' when I run cron to submit documents to the index. Reading the blog jarchowk posted (http://www.nsshutdown.com/blog/index.php?itemid=87) it looks like the solr local module works on 1.3 and 2 other people get the ' java.lang.NoSuchFieldError' on 1.4 . So I guess the next task is to track down this error, I guess it's a bit beyond me at the moment not knowing the inner workings of solr but i'll try when I get some more time.

On a plus note, once this issue is solved it looks like we can use the Location module's functionality again for displaying a search form, getting a center point to search from using a postcode / geo codeded address from google and selecting the distance, then query solr.

We're working on a project that will rely heavily on this, so it's great to see some belated activity in this issue.

For iteration 1, we've decided to just do a bounding box search, submitting lat/long fields to solr, and then doing a simple numeric filter based on input from a javascript widget that allows users to zoom and drag a google map to determine the bounds. This is a reasonable alternative if Local Solr isn't quite ready for primetime yet. If it works well enough, I'll post the code here.

It would be great if someone explained the procedure to get Local Solr working with apachesolr and the nightly version of solr it uses.
Is it sufficient to download the localsolr jar file and throw it in the lib directory, or do we need to compile from source?

-- Alex

I've had some success getting solrlocal running on solr 1.4 today.

My issue was there was some debug left in the latest release on sourceforge, trying to print a debug message to a logger which didn't exist.

It's a fairly simple fix but you will need ant installed to build from source.
Do a svn checkout of locallucene / localsolr

svn co https://locallucene.svn.sourceforge.net/svnroot/locallucene/trunk locallucene
 

Once you have it checked out go into localsolr/src/com/pjaol/search/solr/update/LocalUpdateProcessorFactory.java . Remove the log.debug('..') message at line 138.

Once that is done go in to the locallucene directory in a console and type ant. Thats the locallucene dependency built. Now go into the localsolr directory in a console and type ant. Thats it, everything is built. Copy the localsolr/dist/localsolr.jar , locallucene/dist/localucene.jar, locallucene/lib/geoapi-nogenerics-2.1-M2.jar, locallucene/lib/gt2-referencing-2.3.1.jar, locallucene/lib/jsr108-0.01.jar and locallucene/lib/junit.jar to solr-home/lib. Also copy my schema.xml and solrconfig.xml attached in my last post to solr-home/conf .

It's strange that I needed Junit in the solr-home/libs otherwise I got class not found errors in solr when adding documents. Junit is for testing so I guess there's some debug still in the codebase.

Anyway it's a bit of a hassle getting it set up, but it works. Good news when I was doing some reading up is that lucenelocal is now in the official lucene contribs repository and solrlocal is in the process of moving to the official solr repository. This means in future releases of solr this functionality should be pretty much up and running out the box.

With solrlocal up and running and the patch to the Location module implementing the solr hook I have managed to add documents to my index and then query based on distance using

http://localhost:8080/solr/select?q=*:*&qt=geo&lat=53.384227&long=-2.621073&radius=16&sort=geo_distance%20asc

The radius param is miles, changing this successfully brings back results on the selected distance and in the order specified.

My next step is to build some sort of search interface in drupal for geo queries. I am going to take a look at the 'gz_solr.zip' attachment posted by mikejoconnor to use as a base. This will probably be next weekend though, the girlfriends just got home and I'm getting the look as I've been on the computer all weekend.

I'm quite excited with what I have so far, it's been fairly trivial ( a few hours this weekend) getting Drupal to geocode a address and then add it to solr for spartial querying.

That's very encouraging, thanks!

Although the steps you describe sound simple, my java's rusty, and I've never even used ant before.
Just in case I get tripped up, would you mind uploading the resulting jars?

Here's a patch to apachesolr, to go with the other info in comment # 6

I think Jacob means a patch like http://drupal.org/patch/create and under the headline "Adding/Deleting Files usin gthe Diff command"

Its ugly and not fun but doable.

O ya subscribe +1
http://3281d.com/2009/03/27/death-to-subscribe-comments

:-D that won't get old now..

Sorry, I was a bit unclear, below is the progress I've made, as a simple proof of concept for one of my clients. It has a number of short comings, mostly that it doesn't currently use the drupal search framework, but simply a custom callback. Here are the files with a short description of each.

Attached is a patch(localsolr.patch) for the apachesolr module, this patch modifies the schema.xml and solrconfig.xml files to add the required localsolr information. This is the only code that should be integrated into apachesolr right now. We should work on an apachesolr local search module.

Also attached is a short module(location_solr) to provide integration between apachesolr and the location module. This simply implements hook_apachesolr_update_index(). We should consider making this part of the end solution.

Also attached is a custom module(gz_solr) that I used as my simple proof of concept for my customer. It creates a location search results page based on the predefined gps coordinates in the module(37.5 lat, -122.5 long), and includes faceted search. This code is simply proof of concept, and should not be included in the final version.

In order to get this working you need to compile locallucene/localsolr(instructions provided in their documentation) with the latest nightly solr build, and you need the patch to resolve the arg(1) dependency issue, if you plan on using my gz_solr module.

Hopefully I will be posting more useful code later this week, if someone else doesn't beat me too it. I'll also start working on an official search page, using apachesolr, localsolr, and the search framework provided by Drupal.

OK, here is the start of apachesolr_local. It needs a lot of love, but it does work. I created the patch from svn. If it doesn't work let me know and I'll find another way to create it.

Requirements

• Apachesolr 1.4, with Locallucene and localsolr, compiled from the latest svn version. Don't let this step put you off, it was surprisingly easy
• Location module

Installation steps

1. Apply the attached patch to the latest version of the apachesolr module.
2. Edit line 39 of apachesolr_local.module, replace **insert your api key** with your google maps api key //TODO: replace this lame step with form
3. Replace your schema.xml and solrconfig.xml files
4. Start solr
5. Enable the "Apache Solr local search" module
6. Add nodes with location data, using the location module
7. Run cron
8. Navigate to /search/apachesolr_local
9. Enjoy the localsolr search.

So this is going to boil down to around 30 LOC to the two xml files and a whole new module. That whole new module, and perhaps the patched versions of the xml files, should go in a new contrib project, I think. There are several reasons for this. First, only a small subset of the people who use ApacheSolr are going to want LocalSolr. Second, it doesn't make any sense having LocalSolr directives in there if you're not using LocalSolr (might even result in something like ClassNotFound exceptions?) And third, the reality of the project is that it is quite tied to the product cycle at Acquia. To have autonomy and the freedom to just commit stuff without needing to take that fact into consideration, it needs to be its own project. The ApacheSolr module will do everything it can to be a good framework for this effort, but I think it should turn into its own project.

@jarchowk

If you check mikejoconnor's latest patches looking at them he has had the same idea I have and initially started working on. Using the location module will be far more usable for a user....to be honest a 60K drop down isn't usable. The location module lets you enter a address (predictive text on province field), it then geo caches it using google if set up, if not set up or it doesn't get a result it falls back to it's internal database which geocaches the address based on postcode. I have access to uk postal data and was initially going to use this to get the longitude / latitude, after looking at the Location module I'd just be creating extra work as what I need is already there.

Good news is you have solr setup which is the hard bit, if you apply mikejoconnor's patch you should have the Location module up and running within the hour. I was using the Location module to get the address data, not render it, so once it is in the search index I was going to expand search as you are to use 'Search query', 'Near', 'Distance'. I don't want to display them on a map as of yet and just show a standard search page.... I've not had time to check mike's patch but I think he has this or the foundations for this up and running.

In Mikes location_solr module he also stores city, province, county. I am just learning solr but now these are stored (I didn't in my testing) you can do facted search (if i am am right on how solr works) on county / province / city. Furthering this it's my idea to use this functionality to create a huge spider page. I am uk based so the top page would have links 'Find businesses in County' where county is replaced with a name, clicking through would then have links to the towns within the county 'Find businesses in manchester'.... clicking the towns would then bring up the search results. I also plan on using pathauto so location nodes would be in the format of http://example.com/businesses-type/county/town/node-title , remove title it shows all businesses in the town, removce town it shows a list of towns for the county..... I think this structure would be highly efficient on getting traffic to the site for data which would otherwise be hidden unless a search form was submitted.

.....
@robertDouglass

As for this module going into a new project. At the moment probably sounds like a good idea as localsolr isn't in the solr codebase just yet so with the patched xml files you would get errors on updating data. As far as I know though localsolr is activley being moved over to the solr codebase so it's only a matter of time.

As for creating a new project I'm not sure how this works so guess I'd have to read the docs. I know very little on SOLR so wouldn't want to put my name down for maintaining a project on it however I am more than happy to actively contribute and work on it as I can see this being quite major functionality (local blogs, local news, local business reviews, local classifieds).

I'm assumng Mike O'Connor would star the new project based on the code he's posted here. He's already an active module maintainer, so that should be a straightforward process.

@mikejoconnor

I've been playing around with your code today, I've managed to refactor apachesolr_local.module and remove alot of the code duplication handled in the apachesolr module in regards to searching.

There's a bug in the apachesolr module where if it doesn't find any highlighted keywords it doesn't show a snippet, this means if you leave the search keys empty and only enter a location you only see the node title. I'll check to see if this issue has been raised and if not I'll create one.

I have spotted a limitation in the current localsolr libary, it only queries the default or specified field. In the solrconfig the default field is body, to query title you would need "?q=title:[TITLE]" . This is less than ideal as it then means taxonomy wouldn't be queried either or any other usefull information. I guess the work around for the time being would be to append title, taxonomy etc to the node body for location nodes.

I did have a play with the localsolr libary and after compiling got it to query existing documents on all fields, when new documents where submitted and then queried I got errors. I'd guess i'd have to spend a great deal of time getting my head around localsolr to get this functionality working properly but I am limited at the moment on time. Hopefully when it's in the solr repository we can raise a issue.

I prefer this patch to the solrconfig and schema. It provides the dismax searching with the local solr filtering. This is getting ready to be baked into the Views module as I am about to launch a project on with it. Works cleanly, very excited.

edit: didnt read the comment above me. This also address those concerns. And it also explains my troubles earlier. This definitely will search titles as well as taxonomy etc.

Hi folks

I'd appreciate it, if you could send any bugs or issues to locallucene-users@lists.sourceforge.net
That way I could discover what the problems are and help resolve them for localsolr

BTW this looks like a great addition to drupal, good work @jarchowk

Thanks
Patrick

Hi Scott,

Please can you confirm what version of localsolr you are using. I have tried your patch (and in previous testing tried enabling dismax myself as you have) but still have no luck, only the body field is being queried. I am using the latest svn trunk of localsolr. Also what version of solr are you using?

Below is a sample query I am using when running solr with your patch http://localhost:8080/solr/select/?long=-2.2343765&q=potty&radius=10&qt=... . The query returns no results but it should as I have a document in the index with the title 'Potty .....', if I then change the q parameter to a value which is in a body field I then get results.

Can we concatenateall the field for search somehow? WHen doing the geo search it only searches on drupal's body... You must add "title:" to search on title...

How about all the CCK fields?

Thanks

Bill

@billnbell

Scott Reynolds says it searches all fields for him with his solrconfig patch. It doesn't for me so I wounder what version of solr / localsolr he is using. Last night I had another play and managed to get localsolr libary to use dismax search by patching com.pjaol.search.solr.component.LocalSolrQueryComponent . This now works, updates also work for me.

As I am just getting to grips with solr I need to test there are no unexpected side effects from my patch. I got a busy weekend with it being a holiday and a few friends staying so it'll probably be next weekend I get chance to check it over proper and submit it to the localsolr mailing list for review.

Another thing I have noticed from Scott's patch, some of the default values for highlighting / qf field boosting may not be needed using my approach (http://drupal.org/files/issues/apache_localsolr.zip) as I use hook_apachesolr_modify_query which has these default's set when the hook is executed.

Also another observation....may be just a case I don't know solr. The location values for city, province, country are mapped to dynamic fields, sm_city, sm_province etc. I was unable to create facets for these. I instead had to add the city, province, country field explicitly in the schema to be able to create facets. Now I have these hopefully it's trivial to create country, province, city filter blocks, which is another one on my todo list.

It definately does not search the title unless you put in title: before the search term... We could change the index hook to include title I guess....v(not sure where it does this)

$doc->body = fields . $node->title

Maybe a patch for that?

The non-geo search does search all fields, it's just when you pick geo that the title is not searched. (Is it even indexed?)

Can someone give an example of a geo query with multiple keywords? I do not know the syntax to make this and not sure if there is any documentation.

Pretty convinced my patch works. cause i see it working ;). I am not using any files contained in this issue, I am using my apachesolr Views implementation. It will be packaged with the Views module once someone creates a project for this. It allows for an arbitrary string to be entered, uses JS to geocode it via Google (use JS so that the geocode action doesn't count against the server IP. Thus, netting virtually unlimited Geocoding).

So what my patch does is define the defaults for the searching. Notably it says, "define query type as dismax. Use body^40.0 title^5.0 name^3.0 taxonomy_names^2.0 tags_h1^5.0 tags_h2_h3^3.0 tags_h4_h5_h6^2.0 tags_inline^1.0 formulation"

So whatever that module is doing, seems like that is screwing it up? Maybe all those defaults that you put in the hook_query_alter() are doing it.

I am using the same solr versions everyone is. Again, the only difference I see is that I don't use anything from this issue.

You guys did restart Solr right? Only way new schema or config files are read.

edit: ok found my bug. It appeared to be working cause it wasn't actually doing the localsolr query. this is fixed, but it doesn't search the other fields. That patch doesn't add anything as the localsolr query component doesn't understand those params me thinks.

@Scott - your patch defines a defualt q, but I think it should be q.alt.

Also, I don't know what the performance implications are of adding the component <str>localsolr</str> to the handler, but it seems like you might be able to get away with adding just that to the default handler and be done? Like:

    <arr name="first-components">
      <str>localsolr</str>
    </arr>

How do I limit the results to type_name = xxx ?

I ma having a hard time getting the query set right?

Thanks.

Update: I figured it out. You must have a space before and after. Adding q=type: does not work with geo.

q=+type:+findme

The facets does not work "fq" does not do anything when using geo. One solution would be to get both results and "AND" them. One from GEO and one from regular query.

In regards to facets not working:
http://sourceforge.net/mailarchive/forum.php?thread_name=1e33aedb0903261...

So those that have facets not working, do a new SVN checkout of localsolr

In the latest trunk, there are facets for localsolr

Simply extends current solr facet's, to activate geo facet add
the parameters
Required:
&facet=true // enables facets display
&facet.geo_distance=true // enable geo_distance facet

Optional (defaults shown):
&facet.geo_distance.mod=1  // float variable to uses as a modules 0.5= half mile, 1= mile etc..
&facet.geo_distance.type=count // sort by either count or distance
&facet.geo_distance.direction=asc // sort either asc or desc
&facet.geo_distance.count=100 // maximum facets to display, 0 is unlimited
&facet.geo_distance.inclusive=true // add's up previous distances so facet 19 miles, includes 0-19, 
									// false it will be (19 - mod) to 19, say mod = 1 as default
									// 18 to 19 miles will be the facet result. 

&facet.geo_distance.buckets= (no default) // switches the a predefinable bucket list
										  // e.g &facet.geo_distance.buckets=0.5,1,3,8
										  // will return inclusive facets for 0.5 miles, 1 mile, 3 etc..

How do you do a svn of the latest trunk? Thanks for the help.

I tried the latest build and now I get null errors. Note this happens even with a basic query. At some point - it clears up until I load another document, then I get this again... I went back to the previous version. If someone has a good locallucene.jar and localsolr.jar please email me bell.william@comcast.net. Thanks.

INFO: [core1] webapp=/solr path=/select params={spellcheck=true&qf=body^40&qf=tags_inline^1.0&qf=title^8.0&qf=taxonomy_names^2.0&qf=name^3.0&qf=tags_h2_h3^3.0&lat=39.7550920&facet.limit=20&wt=json&rows=10&json.nl=map&start=0&sort=geo_distance+asc&facet=true&facet.mincount=1&q=test&fl=id,nid,title,comment_count,type,created,changed,score,url,uid,name,body&qt=geo&long=-104.9881230&version=1.2&radius=40&f.ss_cck_field_salary.facet.limit=20&spellcheck.q=test&facet.field=ss_cck_field_co_size&facet.field=ss_cck_field_employee_type&facet.field=ss_cck_field_employer_type&facet.field=im_vid_9&facet.field=sm_cck_field_job_hours&facet.field=sm_cck_field_job_length&facet.field=ss_cck_field_job_app_status&facet.field=im_vid_11&facet.field=im_vid_10&facet.field=im_vid_12&facet.field=ss_cck_field_salary&facet.field=ss_cck_field_siterole&facet.field=im_vid_15&facet.field=ss_cck_field_co_type&bf=recip(rord(created),4,58,58)^200.0&facet.sort=true} status=500 QTime=95

Apr 13, 2009 3:03:17 PM org.apache.solr.common.SolrException log
SEVERE: java.lang.NullPointerException
at com.pjaol.search.geo.utils.DistanceSortSource$DistanceScoreDocLookupComparator.compare(DistanceSortSource.java:74)
at org.apache.lucene.search.FieldSortedHitQueue.lessThan(FieldSortedHitQueue.java:122)
at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:139)
at org.apache.lucene.util.PriorityQueue.put(PriorityQueue.java:53)
at org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:78)
at org.apache.lucene.search.FieldSortedHitQueue.insertWithOverflow(FieldSortedHitQueue.java:105)
at org.apache.solr.search.SolrIndexSearcher$9.collect(SolrIndexSearcher.java:1229)
at org.apache.lucene.search.IndexSearcher$MultiReaderCollectorWrapper.collect(IndexSearcher.java:313)
at org.apache.lucene.search.TermScorer.score(TermScorer.java:76)
at org.apache.lucene.search.TermScorer.score(TermScorer.java:61)
at org.apache.lucene.search.IndexSearcher.doSearch(IndexSearcher.java:262)
at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:250)
at org.apache.lucene.search.Searcher.search(Searcher.java:126)
at org.apache.lucene.search.Searcher.search(Searcher.java:105)
at org.apache.solr.search.SolrIndexSearcher.getDocListAndSetNC(SolrIndexSearcher.java:1217)
at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:924)
at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:345)
at org.apache.solr.search.SolrIndexSearcher.getDocListAndSet(SolrIndexSearcher.java:1477)
at com.pjaol.search.solr.component.LocalSolrQueryComponent.process(LocalSolrQueryComponent.java:299)
at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195)
at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1333)
at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:172)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:174)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:703)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:895)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:595)

Did you delete the index and re-index the site after moving to svn trunk versions of localsolr?

Yes,

I redid the index... What version of lucene.jar is in your Solr.war file? Also your schema/solrconf.xml ?

Can you send me your Solr.war, and your /home/solr/lib directory? I can try it and report back.

I compiled with At revision 171.

I thought maybe I was running out of memory, but that does not seem to be the case. The issue has something to do with adding a new document to Solr that has lat/long and not being able to get a distance. It happens as soon nas I type http:///cron.php after the new document is ready ot be indexed.

Anything else I can try? The old one works fine, but no facets. I tried for 3-4 hours last night, and deleted the index and restarted about 30 times, and told Solr to reindex, ran cron.php a bunch of times....

There really might be a bug in there?

OK I spoke with Patrick O'Leary (author or LocalLucene and LocalSolr). We got it working. It was the solr.war file that was causing the problems.

Here is what is supported:

Solr Specification Version: 1.3.0.2008.12.09.19.20.29

Solr Implementation Version: 1.4-dev 724936 - pjaol - 2008-12-09 19:20:29

Lucene Specification Version: 2.9-dev

Lucene Implementation Version: 2.9-dev 724059 - 2008-12-06 20:08:54

Trunk on the locallucene and Localsolr as well.

http://www.nsshutdown.com/bill.tar.gz

I've added the code from Scott's patch(#24) and ajevans85's .zip(#23) to CVS under contributions/modules/localsolr. I've also created the Localsolr project page.

This still needs a LOT of work, lets see what we can do.

This discussion should move to the localsolr issue queue.

http://drupal.org/project/issues/localsolr

Sorry I've not had chance to do further work on this yet being tied up at work on other things.... Done a 26hr+ day so far in the office because of a tight deadline.

If I remember right from a email I recivied from the mailing list local lucene is now lucene spartial and in the lucene contrib repositroy. Geotools has been replaced with code to match the lucene license.

It may be worth deleting local lucene, download trunk lucene spartial and build the latest versoion of local solr against that. Also if deploying in tomcat I delete CATALINA_HOME/tmp , CATALINA_HOME/work CATALINA_HOME/webapps/solr* to make sure the tomcat cache is cleared.

See post #40. This is the only config that works right now.

I don't really why fq does not work. It works for me. see www.hihojobs.com. I think some people are using bits and pieces, compiling some pieces, etc...

I am going to zip it again. See http://www.hihojobs.com/billbell.tar

By the way, post your jobs or resumes here at www.hihojobs.com

Thanks!

I see what you mean now. The project was split into Lucene-Spatial and Solr-Spatial. Unfortunately the Apache team is arguing on how to integrate the Solr-Spatial into SOLR as a contrib module.

Copy the lucene-spatial-2.9-dev.jar into your /lib directory.

The trunk of LocalLucene is now at http://svn.apache.org/repos/asf/lucene/java/trunk/contrib/spatial/ so Patrick included a built copy for you.

rm lib/locallucene.jar

after searching a while i found a working library.

http://www.jteam.nl/news/spatialsolr

it's now called spatialsolr, and the config files have changed quite a bit.
There's also a good documentation in the download archive, but i'm not really into what needs to be adjusted to work with the drupal module.

This sound VERY interesting to me:

Could this solve the following scenario?

1. Search for searchword "baby"
2. Submit in background the zip code or the lat/lon of the searching person
3. Get searchr esults
4. Sort search results by distance

What's the latest on this? It looks like development stalled on both this thread and at http://drupal.org/project/localsolr.

Anyone still working on location-enabled Apache Solr?

subscribing

I reopen this issue because I don't totally understand why in #42 it is marked as duplicate.

http://drupal.org/project/localsolr have two module one "local lucene based geospacial search" and the other "Location module integration".

But this module require to patch http://drupalcode.org/viewvc/drupal/contributions/modules/localsolr/loca... Apache Solr Search Integration to change the schema.

I think Apache Solr Search Integration still need "LocalSolr Support" at least for the schema. So other module like http://drupal.org/project/geo can be integrate with Solr with simple code like http://drupalcode.org/viewvc/drupal/contributions/modules/localsolr/loca...

The schema is, in a way, outside of the apachesolr module. It's included so that people have a reasonable default schema, but the expectation is that if you want to enable/configure other features of Solr, you can edit the schema.xml. We aren't going to be able to find a one-size-fits-all schema.xml. It's perfectly fine for other modules to include patches for the default schema.xml that is distributed with the apachesolr module.