Trifork Blog

Geo-Location Search with Solr and Lucene

August 3rd, 2009 by
|

Like many people, I use Google Maps to find businesses near my house. This kind of search differs considerably from usual free text searches since I’m no longer just asking for companies that include the phrase pizza, I’m also asking for companies that are near a certain point. This functionality has until recently been found mostly in closed source commercial search applications. However, in the last 6 months support for spatial search has begun to be added to Apache Lucene and Solr, much of which has been developed here at JTeam.

Spatial Lucene

Spatial Lucene, a Lucene contrib which has been extended in LUCENE-1732, is at the heart of the spatial search support in Lucene and Solr. It provides a proper Lucene Filter called SpatialFilter which filters out those documents in the index that are outside of the radius of a certain point. Conceptually the filtering need not be very complicated – calculate the distance each document is from the point and filter out those that are too far away. However if this were done for each document in an index of say, 1 million documents, then the filtering would take 10s of seconds – unacceptable given that normal free text searches usually take 10s of milliseconds. Consequently SpatialFilter uses a two step filtering process which considerably reduces the total time needed.

Cartesian Grid Filtering

The first step is applying a Cartesian grid filter. This filter works by wrapping a grid around the Earth, storing in each document which grid square it is in, working out which grid squares are within the radius of center of the search, and filtering out those documents which are not in this squares. This process is remarkably efficient since the calculations of which squares each document is in, is done when the document is first indexed, and finding those documents that are in certain squares can be done by TermQueries. In fact for an index of 1 million documents and a search radius of 30km, this process takes a mere 40ms.

Example Cartesian Grid applied to The Netherlands.  Each document in the index is plotted on the map so that its grid square can be identified.

Example Cartesian Grid applied to The Netherlands. Each document in the index is plotted on the map so that its grid square can be identified.

See here for more information about the Cartesian Grid filtering process.

Distance Filtering

Depending on the size of the grid squares and how much they were overlapped by the search area, there is likely to be many documents that passed the Cartesian Grid filtering which are not in the search area. Hence the second step in the filtering process removes these by calculating distances from the center of the search, to each of the documents that passed the first step. While the mathematics behind these calculations is very well known, it is very complicated and involves arc trigonometry. Done sequentially, it can take 2s to calculate the distance for 200,000 documents – still unacceptable. Consequently the distance filtering is distributed across multiple threads which results in the time taken to calculate the distances for the same 200,000 documents using 2 threads, being reduced to 400-500ms – much more acceptable.

The time taken to carry out the calculation for each document can also be reduced by assuming that the world is flat. While this is not going to be acceptable over long distances, for many smaller areas the error this would introduce is minimal. Consequently Spatial Lucene allows the user to choose between two implementations of a GeoDistanceCalculator interface – SphericalGeoDistanceCalculator and FlatPlaneGeoDistanceCalculator.

Latitude, Longitude and Geohashes

I have been intentionally vague on exactly what information defines the location of a document. This is because while the distance calculations done in the distance filtering process assume each document has a latitude and a longitude (or simply x and y co-ordinates), Spatial Lucene does not require this information be stored as 2 distinct fields. It also supports the data being stored in a geohashes, which are decoded when necessary.

Using Spatial Lucene

Lucene users can use the SpatialFilter directly, but are responsible for adding the Cartesian Grid information to their documents. Solr users can use Spatial Lucene through the QParser and UpdateProcessor contributed in SOLR-773, otherwise known as Local Solr.

Local Solr

To Solr developers and users, Spatial Lucene should be blackbox. Instead the focus of Local Solr is how to best to incorporate Spatial Lucene, whilst having the least effect on the standard Solr indexing and querying process. To do this, Local Solr contains 3 major components: the SpatialTierQParser which supports translating spatial search queries into instances of SpatialFilter, SpatialTierUpdateProcessor which adds the Cartesian Grid information to documents, and the DistanceFieldValueSource which adds the calculated distances to the search results.

SpatialTierQParser

The SpatialTierQParser supports the following standard syntax for spatial searches:

q={!spatial lat=4.56 lng=10.89 radius=10 calc=arc unit=km}name:pizza

From this, the SpatialTierQParser will construct a FilteredQuery consisting of the user’s actual query, name:pizza, and an instance of SpatialFilter which will filter out those documents that are more than 10km away from latitude 4.56 longitude 10.89. The arguments calc and unit are purely optional, with the only required arguments being lat, lng and radius.

To use the SpatialTierQParser, a user must add the following to their solrconfig.xml:

<queryParser name="spatial" class="org.apache.solr.spatial.tier.SpatialTierQueryParserPlugin" />

and include latField=lat&lngField=lng in search requests.

SpatialTierUpdateProcessor

Solr users are used to adding documents in many different ways, whether its in XML, CSV posts or through the DataImportHandler and do not want to have to add in the Cartesian Grid information themselves. To do this for them, the SpatialTierUpdateProcessor can be added to the UpdateProcessorChain, which each of the UpdateHandlers use. This Processor uses the latitude and longitude of each document to work out what Carestian grid squares the document is in, and adds this information to the documents before they are indexed. To the user, the updating process has not changed at all and they can remain oblivious to complex processing that is occurring underneath.

To use the SpatialTierUpdateProcessor, a user must add the following to their solrconfig.xml:

<updateRequestProcessorChain>
    <processor class="org.apache.solr.spatial.tier.SpatialTierUpdateProcessorFactory">
      <str name="latField">lat</str>
      <str name="lngField">lng</str>
      <str name="tierPrefix">_tier_</str>
      <int name="startTier">9</int>
      <int name="endTier">17</int>
    </processor>
    <processor class="solr.RunUpdateProcessorFactory"/>
    <processor class="solr.LogUpdateProcessorFactory"/>
  </updateRequestProcessorChain>

And to their schema.xml:

<field name="lat" type="sdouble" indexed="true" stored="true" required="true" multiValued="false" />
<field name="lng" type="sdouble" indexed="true" stored="true" required="true" multiValued="false" />
<dynamicField name="_tier_*" type="sdouble" indexed="true" stored="false"/>

DistanceFieldValueSource

Solr user’s naturally want to see in the search results how far each document is from the center of their search. Without it, whats the point really. But distances are not fields that can be added to documents – they change from one search to the next. Further complicating the problem, Solr does not currently support anyway of adding arbitrary information to search results, only the search response, but that goes against our goal of minimizing the effect of integrating Spatial Lucene.

The solution to this included in SOLR-773 is the idea of the FieldValueSource and FieldValueSourceRegistry. FieldValueSources, which are registered with the FieldValueSourceRegistry at query time, are used by each ResponseWriter to add new fields consisting of arbitrary data, to the search results at query time. Hence the DistanceFieldValueSource, which reads the distances stored in the SpatialFilter, is able to add the calculated distances to the results being returned by Solr, as though they were another field in the documents.

To use the DistanceFieldValueSource, simply include distanceField=geo_distance&fl=geo_distance in search requests.

Multi-Threaded Configuration

In addition to these 3 components, Local Solr allows the user to configure how many threads are given to Spatial Lucene for its multi-threaded filtering. This can be done by first configuring Solr’s ExecutorService (also introduced in SOLR-773) by adding the following to the solrconfig.xml:

<executorService corePoolSize="2" maxPoolSize="10" keepAlive="2"/>

and then by including the parameter threadCount in search requests, stating how many threads Spatial Lucene should use to process the request e.g. threadCount=2

Conclusion and Future of Spatial Search

Hopefully I have shown you how extensive and mature the support for spatial search in Lucene and Solr has become and that with not much effort, your Solr users will be able to search for pizza delivery shops near their house. I would love to hear from anyone who is using either LUCENE-1732 or SOLR-773.

Future versions of these patches may include support for search with regular polygons, and the introduction of distance facets, allowing Solr users to be able to filter their results based on the calculated distances.

46 Responses

  1. August 4, 2009 at 00:29 by Mello

    I have this doubts about the jira process, could you answer to me?
    If I get from night build i will have solr with this feature? Or I need to get separated and configure?
    Thanks, Mello

  2. August 5, 2009 at 07:41 by Toolman

    Wow; congratulations thats great work, a real useful contribution!

  3. August 5, 2009 at 18:06 by Alef Arendsen

    @Toolman well, were you surprised? It’s coming from a Kiwi afterall 😉

  4. August 5, 2009 at 19:52 by Toolman

    No, us Kiwis know all about distance!

  5. August 17, 2009 at 21:50 by pligg.com

    Geo-Location Search with Solr and Lucene…

    Some more info on the new Spatial Lucene stuff….

  6. August 18, 2009 at 15:43 by Toxic

    Very interesting article, but how does this play with the integration of Solr? As far as I can see, SOLR-773 is still an open subject which seem to require manual patching and compilation of Solr itself (which by the way is incompatible with the latest nightly, solr-2009-08-18.zip due to conflicts in SolrCore).

  7. August 20, 2009 at 23:24 by Chris

    I’m glad to see progress on official LocalSolr integration, great job!

    However, like Toxic, I too had trouble with the patches scattered across the Lucene and Solr JIRA issues.

    My closest attempt at getting this to work involved the Solr trunk and your custom lucene-spatial-2.9-dev-LUCENE-1732.jar from SOLR-773, but ended up with this exception at query time:

    Aug 20, 2009 10:10:20 AM org.apache.solr.common.SolrException log
    SEVERE: java.lang.NoSuchMethodError: org.apache.lucene.spatial.tier.CartesianPolyFilterBuilder.getBoundingArea(DDD)Lorg/apache/lucene/search/Filter;
    at org.apache.lucene.spatial.SpatialFilter.(SpatialFilter.java:63)
    at org.apache.lucene.spatial.SpatialFilter.(SpatialFilter.java:95)
    at org.apache.solr.spatial.tier.SpatialTierQueryParserPlugin$SpatialTierQParser.(SpatialTierQueryParserPlugin.java:130)
    at org.apache.solr.spatial.tier.SpatialTierQueryParserPlugin.createParser(SpatialTierQueryParserPlugin.java:99)
    at org.apache.solr.search.QParser.getParser(QParser.java:256)
    at org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:88)
    at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:181)

    Any word on getting this into SVN so we’ll all have a semi-stable revision number to start playing with? Cheers,

    – Chris

  8. August 22, 2009 at 10:53 by Peter T

    I have a concern about multi-threaded configuration. In ThreadedDistanceFilter, multiple threads could iterate over the same BitSet object. According to JDK docs, “A BitSet is not safe for multithreaded use without external synchronization.” Is it gonna be a problem?

    thanks!

  9. August 25, 2009 at 08:49 by Chris Male

    Hi all,

    Thanks for reading my entry.

    @Mello: Unfortunately this is not included in the nightly build. You will need to download the patches from JIRA and configure it yourself. I have included an example configuration in SOLR-773.

    @Toxic: The Solr integration presented here is the most recently contributed to SOLR-773. The issue is an open discussion still and I will continue to update my work to reflect the directions that the issue takes. I agree that having to apply patches is a pain, which is why I hope my work becomes committed.

    @Chris: Thats an unusual error, but it could be due to updates being applied to the trunk code. I will look into that more and produce an update if needs be. Unfortunately as Toxic noted, the SOLR-773 issue is still very much open to discussion, but I hope it will be committed soon.

    @Peter T: Its not going to be a problem as the BitSet that is shared across multiple threads is read-only. Each thread builds its own read/write BitSet. We intentionally do it this way to avoid having to include any synchronization.

  10. August 31, 2009 at 21:57 by Joe Kueser

    Chris,

    Fantastic writeup. Thanks.

    My site is going to need geo search capabilities at its core. I’ve been following SOLR-773 for a while, and I feel pretty confident that we won’t see a working version of Spatial Solr in a release version for a while. I am hoping that you can help me get a working development version to fill the gap until that time.

    If I use the lucene jar that you provided, everything seems to work fine except for geo_distance, and longitudes in my home down (lat 37.03, long -94.51). I get a 500 error. The trimmed down version looks something like what I posted below.

    If possible, we would like to get our hands on the working code you have so we can tweak it to fix any problems and have a relatively stable code base.

    Thanks for your help.

    Joe

    HTTP ERROR: 500

    ExecutionException thrown while retrieving results of tasks

    java.lang.RuntimeException: ExecutionException thrown while retrieving results of tasks
    at org.apache.lucene.spatial.distance.ThreadedDistanceFilter.bits(ThreadedDistanceFilter.java:154)
    at org.apache.lucene.spatial.SpatialFilter.getDocIdSet(SpatialFilter.java:224)
    at org.apache.lucene.search.FilteredQuery$1.scorer(FilteredQuery.java:110)

    Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: Illegal lattitude value -94.51
    at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
    at java.util.concurrent.FutureTask.get(FutureTask.java:83)
    at org.apache.lucene.spatial.distance.ThreadedDistanceFilter.bits(ThreadedDistanceFilter.java:147)
    … 30 more
    Caused by: java.lang.IllegalArgumentException: Illegal lattitude value -94.51
    at org.apache.lucene.spatial.geometry.FloatLatLng.(FloatLatLng.java:26)
    at org.apache.lucene.spatial.util.DistanceUtils.getLLMDistance(DistanceUtils.java:45)
    at org.apache.lucene.spatial.util.DistanceUtils.getDistanceMi(DistanceUtils.java:30)
    at org.apache.lucene.spatial.geometry.ArcDistanceCalculator.calculate(ArcDistanceCalculator.java:38)
    at org.apache.lucene.spatial.distance.ThreadedDistanceFilter.iterate(ThreadedDistanceFilter.java:195)
    at org.apache.lucene.spatial.distance.ThreadedDistanceFilter$1.call(ThreadedDistanceFilter.java:134)
    at org.apache.lucene.spatial.distance.ThreadedDistanceFilter$1.call(ThreadedDistanceFilter.java:132)

    RequestURI=/solr/select/

  11. September 1, 2009 at 09:19 by Chris Male

    Hi Joe,

    The error is due to an odd restriction in the FloatLatLng class which limits the range of latitudes. This code comes from the Spatial Lucene contrib so I’m not entirely sure what the reason for the restriction is. From briefly looking at the problem, it seems like something that could be removed.

    In regards to getting hold of the working code, if you need this immediately then its best you use the patches included in SOLR-773 and LUCENE-1732. Otherwise if you are able to wait 2 weeks then I will be releasing a fully refactored version which will be available for download from the JTeam website. It wouldn’t make much sense to release this code just yet since I’m part of the way through the refactoring.

    Thanks
    Chris

  12. September 1, 2009 at 15:11 by Joe Kueser

    Fantastic, Chris, thanks.

    If there’s anything I can do to help out, please don’t hesitate to ask.

    Joe

  13. September 18, 2009 at 04:24 by Saadiq Rodgers-King

    This is a great write-up, Chris. I’m really eager to play with it. Have you had any luck with the refactoring you mentioned? Thanks.

    Saadiq

  14. November 6, 2009 at 16:33 by Sebastian Paul

    i seem to be missing a jar,
    Error loading class ‘org.apache.solr.spatial.tier.SpatialTierUpdateProcessorFactory

    which files should i add to my libs.
    using latest solr nightly NOV-05-09

  15. November 6, 2009 at 20:20 by Chris Male

    Hi Saadiq,

    Sorry for taking awhile to respond. Yes we have done a great deal of the refactorings and have released the code. You can find more information at http://www.jteam.nl/news/spatialsolr.

    Chris

  16. November 9, 2009 at 15:44 by Jason

    Hi, I’ve been trying to get the build mentioned above working with solr nightly 11-09-09, 11-05-09, and am now trying 11-03-09. I keep getting a “SEVERE: java.lang.NoClassDefFoundError: org/apache/solr/search/QParserPlugin” error after adding the spatial-solr jar and adding the solrconfig.xml and schema.xml modifications noted in the pdf. commenting out the solrconfig mods allows the solr example to start.

    any idea what would be causing this kind of error?

    Thanks,

    Jason

  17. […] The author of the SSP plugin- JTeam Search specialist Chris Male – explains the technical underpinnings in his earlier blog on Geo-location Search. […]

  18. November 22, 2009 at 05:14 by aaron

    great job and team.
    i have tried ssp for a while, it works fine for a small amount of records, but when i take a stress test, about 0.3 million records, i found the search response time increased to 700+ms, and after about 10 times search, the tomcat exhaust my memory, any idea what would be causing this kind of issue?

    ps: i guess the momery issue dues to the document cache.

  19. December 3, 2009 at 18:35 by Eric Pugh

    Thanks for the summary writeup. I am working with this and hoping to do some stress testing with version written up at http://www.gissearch.com/localsolr_using. Geo seems like the next big thing for Solr 1.5 (2.0??)!

  20. December 4, 2009 at 17:37 by NeX

    I’m getting the same error as Jason:

    “SEVERE: java.lang.NoClassDefFoundError: org/apache/solr/search/QParserPlugin”

    The class is there!

    Any ideas?

  21. December 28, 2009 at 04:38 by Jacob Straszynski

    Just noticed that there seem to be some discrepancies between 1) the documentation on this blog, 2) within the spatial-solr-1.0-RC3 zip file’s included pdf (‘spatial-solr.pdf’) and 3) the zip file’s own src.

    Option 1) Blog Post:

    Option 2) PDF:

    Option 3) src Directory in Zip File Suggests:

    Number 1) seems to be where things are going as patches make it upstream into the 1.5 release (which suggests that this it the latest way to do things). Except for the fact that this post was made before the most recent release… Did this spatial stuff get pulled from solr between 1.3 and 1.4?

    For 1.4 the choice seems to be between 2) and 3). It looks like you refactored the project structure slightly without updating the docs. No biggie but for a while I was confused by this exception:

    Error loading class ‘nl.jteam.geodistance.solrext.SpatialTierQueryParserPlugin’

    So just some points of confusion that I’d like to point out.

    Is there an repository where we can download up to date versions of the plugin rather than going via the archive file (which looks like it’ll need some updating on the documentation side of things)?

    This is looking great though and it’s exactly what my project needed. Thanks guys.

  22. December 28, 2009 at 16:48 by Chris Male

    Hi Jacob,

    Thanks for pointing this discrepancies out. We have made some changes to the plugin since this entry was published, and so I wouldn’t suggest using this entry as a reference for how to setup the plugin. However the documentation in spatial-solr.pdf should be kept in sync with the source code, therefore I will update it.

    I will look into what options are available for providing quicker access to updated versions of the plugin.

    Thanks,
    Chris

  23. January 14, 2010 at 16:10 by Bart Naessens

    I’m having some weird results using spatial solr: When I search for locations in 60km radius around Ghent, I do find Brussels. But the other way around, in a radius 60km around Brussels, I do NOT find Ghent. The entered lat & long are correct.

    I tried to debug, but I’m still having problems displaying the calculated distance in Solr. I’m using Solr 1.4.0 with Tomcat.
    Relevant part from solrconf.xml:

    explicit

    query

    lat
    lng
    9
    17
    _tier_

    1
    2
    60
    lat
    lng
    _tier_

    distance

    ——————–
    Example query i use: http://localhost:8080/solrlocation/select/?q={!spatial%20lat=50.8371%20long=4.35536%20radius=60%20calc=arc%20unit=km%20threadcount=2}*:*&fl=distance

    Any thoughts ? Or strategies to debug ?
    Despite this problem, many congratulations on the work done! I really appreciate it.

  24. January 29, 2010 at 19:52 by Steffen

    I, too, get this error:
    “SEVERE: java.lang.NoClassDefFoundError: org/apache/solr/search/QParserPlugin”
    Solr 1.4 with Jetty… doesn’t work. :[

  25. February 1, 2010 at 20:13 by Steffen

    Alright, fixed the NoClassDefFoundError. (had to move the SpatialSolr .jar from the Jetty lib/-folder to the solr/lib/-folder)
    Now I have the same problem Bart has: my results don’t show the calculated distances, even though I added the geodistance search component. Any thoughts on what we might be missing?

  26. February 1, 2010 at 23:34 by Martijn van Groningen

    Hi Steffen, have you added the distanceField parameter to the request?

  27. March 15, 2010 at 11:11 by Lukas

    Awesome stuff. Two questions:
    1) is there any way to affect the rank score based on the distance? ideally i would have some way to define a function that applies a multiplier based on the distance.
    2) using geohashes, i assume it should be possible to also use the query filtering on a multivalued geo location field (use case we are storing store offers which may be available in multiple stores).

  28. March 19, 2010 at 18:02 by Udi

    Section 2.2.2 of the pdf references nl.jteam.geodistance.solr.SpatialTierQueryParserPlugin. It should be nl.jteam.search.solrext.spatial.SpatialTierUpdateProcessorFactory

    The example configurations at the bottom of the pdf are correct however.

    Also, all the query examples use “lat” & “lng”, but it only seems to work with “lat” & “long”. Otherwise you get a Longitude parameter is missing error.

    Thanks!!

  29. April 16, 2010 at 18:02 by Matej

    How can I sort / boost on geo_dstance?

  30. April 21, 2010 at 12:48 by Holger

    Does anyone has an idea about Bart’s issue (see above 14/01/2010) ?
    All points east to your search point get only into your results, if you highly increase the radius.
    Example:
    Point 1 is 2 km west of Start Point, Point 2 is 2 km east
    Having radius = 3km: only Point 1 is found
    Having radius = 6km: both are found ?!?

    @Steffen: in solrconfig, did you add the geodistance search component as “last-component”?

    geodistance

    @Matej:
    add to query: sort=geo_distance%20desc

    Thanks for the infos and the nice work!

  31. April 21, 2010 at 17:59 by Matej

    @Holger:
    I have tried with sort=geodistance desc but I keep getting: can not sort on undefined field: geo_distance
    I got geo_distance field in result output (fl=geo_distance), I have configured last-components with geodistance in solrconfig.xml

  32. April 29, 2010 at 07:12 by MarkALosey

    Okay, I am trying to follow along.

    The directions above for getting distance into results is not working for me. I have added into

    dismax
    ... ...

    spellcheck
    geodistance

    I can get ssp to work in general…but I can get it to work, just not a distance field…in the results. I have also tried adding the fl=distance onto my query….

    Thanks ahead of time for any help….

  33. May 25, 2010 at 15:00 by rob ganly

    i’ve just checked-out and installed the latest solr build and am using the spatialsearch features (http://wiki.apache.org/solr/SpatialSearch).

    i am now aware from your site that solr 1.5 isn’t nec. going to be released (http://blog.jteam.nl/2010/04/14/state-of-solr/). however, as the page suggests, solr localsearch is now obsolete, thus raises the question- right now, which is the correct/recommended method of adding geo search to solr?

    pointers/discussion appreciated. thx.

  34. June 25, 2010 at 13:13 by Ivan K

    Hi guys,
    I still have the problem with latest release:

    java.lang.NoClassDefFoundError: org/apache/solr/search/QParserPlugin

    Does someone know how to fix the issue?

    Thanks,
    Ivan

  35. July 1, 2010 at 14:34 by Derek Almond

    I’m attempting to integrate this into a site that built using symfony, and am a bit of a solr n00b,

    using solr/admin

    im posting

    {!spatial lat=52 long=0 radius=30000 unit=miles } +project

    and i get no results back, if i remove the spatial search (i.e. just use +project then i do get results)

    i’m wondering if this is down to an indexing problem, as when i look at the schema browser, there are no _tier_ fields in the index, i suspect there should be?

  36. August 5, 2010 at 13:02 by Kodo

    Hi!

    I’m trying to get this going but for reasons unknown I fail to get it to work. I have a Solr1.4 instance (multicore# up and running with the RC4 version of the spatial plug-in successfully deployed. In order to test this configuration I index one document where the lat/long coordinate is specified. After the indexing phase has finished, There are eight #8# values present in some dynamic fields #_TIER_9 through _TIER_16#.

    The values stored in the lat/long fields are: 58.6;16.1833

    Now when I try something obvious such as:

    …?q={!spatial lat=16.18 long=58.6 radius=100 unit=km}

    I fail to find the record indexed and commited. Investigating the tomcat log reveals nothing – evrything seems to work fine #no exceptions etc) *but* nothing is retrieved.

    What’s wrong?

    Many thanks for any suggestions…

  37. September 1, 2010 at 16:05 by stbo

    in what folder we must put the plugin ?

    /solr/lib/ ?
    /solr/example/lib/ ?
    /solr/example/solr/lib/ ?

    another ?

    thanks

  38. September 15, 2010 at 01:17 by mquinsland

    Local Solr works very well for me until my except in some extreme situations e.g. distances greater than 1000 miles or sometimes when crossing the equator.

    Biggest question is how to determine the coordinates of the various tiers. If a given latlng is stored as a certain value for a given tier, how do I find out the bounding box coordinates for that value at a given tier? I need to do some statistics that show the distribution of my document sources. The various tier levels are a perfect idea – but how to convert grid#x at tier 12 to a polygon on google maps.

  39. October 13, 2010 at 07:53 by Charton

    Some tips to avoid the problems we ran into:
    1) Make sure to use the stable solr 1.4 release instead of the nightly builds minimize incompatibility with the plugin
    2)Put the jar file under example/solr/lib, you will need to create the lib directory
    3) Make sure the namespace you put in the solrconfig.xml for all the classes correspond to what was actually used in the plugin. The configuration stated on this blog might not be updated, the one on the PDF is usually more up to date.
    4) use tdouble for the type attribute for the lat/lng field declarations.

    Hope this helps

  40. […] does not have native support for this, we decided to try out spatial-solr-plugin from jteam. This blogpost describes how the plugin works and you should definitely read it since it covers much more aspects […]

  41. November 19, 2010 at 01:58 by Anthony

    The solution, for those of you getting the NoClassDefFoundError exception thrown, is to put the jar file in your example directory, under:
    solr/work/Jetty_0_0_0_0_8983_solr.war__solr__k1kf17/webapp/WEB-INF/lib/

    Weird, I know, but it works. 🙂

  42. December 8, 2010 at 20:49 by Adam Estrada

    All,

    I can’t get this working for me at all! I get the same error over and over again. I’ve tried two different jar files. 1. from https://issues.apache.org/jira/browse/SOLR-773 and the other I downloaded from this website.

    SEVERE: Could not start SOLR. Check solr/home property
    org.apache.solr.common.SolrException: Error loading class ‘org.apache.solr.spati
    al.tier.SpatialTierQueryParserPlugin’

    I placed the file at SOLR_HOME/lib and also in ../../SOLR_HOME/lib as part of the LUcidWorks configuration. Any tips on this would be great!

    Thanks,
    Adam

  43. May 4, 2011 at 02:40 by Gavin

    I used Anthony’s instructions (creating directories solr/work/Jetty_0_0_0_0_8983_solr.war__solr__k1kf17/webapp/WEB-INF/lib/) and got the example & Jetty to work.

    Although, the first time I ran `java -jar start.jar`, it seems to have deleted the SSP jar file. So I had to re-copy the jar file into the `…WEB-INF/lib/` folder.

  44. May 4, 2011 at 17:34 by Eric London

    I am also getting this error:

    SEVERE: org.apache.solr.common.SolrException: Error loading class ‘nl.jteam.search.solrext.spatial.SpatialTierQueryParserPlugin’

    Here are some specs of my setup:

    $ tomcat6 version
    Server version: Apache Tomcat/6.0.29
    Server built: October 18 2010 2002
    Server number: 6.0.29.29
    OS Name: Linux
    OS Version: 2.6.18-238.9.1.el5.centos.plus
    Architecture: amd64
    JVM Version: 1.6.0_17-b17
    JVM Vendor: Sun Microsystems Inc.

    My solr/home property in /etc/tomcat6/Catalina/localhost/solr.xml points to here:
    /var/lib/tomcat6/solr

    I am using apache-solr-1.4.1 and spatial-solr-2.0-RC5.

    I copied spatial-solr-2.0-RC5.jar into this folder: /var/lib/tomcat6/webapps/solr/WEB-INF/lib

    Contents of /var/lib/tomcat6/webapps/solr/WEB-INF/lib/ directory :
    apache-solr-core-1.4.1.jar
    apache-solr-dataimporthandler-1.4.1.jar
    apache-solr-solrj-1.4.1.jar
    commons-codec-1.3.jar
    commons-csv-1.0-SNAPSHOT-r609327.jar
    commons-fileupload-1.2.1.jar
    commons-httpclient-3.1.jar
    commons-io-1.4.jar
    geronimo-stax-api_1.0_spec-1.0.1.jar
    jcl-over-slf4j-1.5.5.jar
    lucene-analyzers-2.9.3.jar
    lucene-core-2.9.3.jar
    lucene-highlighter-2.9.3.jar
    lucene-memory-2.9.3.jar
    lucene-misc-2.9.3.jar
    lucene-queries-2.9.3.jar
    lucene-snowball-2.9.3.jar
    lucene-spellchecker-2.9.3.jar
    slf4j-api-1.5.5.jar
    slf4j-jdk14-1.5.5.jar
    spatial-solr-2.0-RC5.jar
    wstx-asl-3.2.7.jar

    I also updated my schema.xml and solrconfig.xml files per the instructions.

    Am I missing something else?

    Thanks for everyone’s hard work on this package!

  45. May 25, 2011 at 23:59 by Yasir Malik

    I have installed Apache Solr on Windows with Jetty Running as a Service via NSSM. Following the instructions from this URL

    http://beckelman.net/post/2011/02/22/Setup-Apache-Solr-on-Windows-with-Jetty-Running-as-a-Service-via-NSSM.aspx

    After running SOLR now when i tried to install plugin “SSP 2.0 – SPATIAL SEARCH”. I am getting following error

    “java.lang.NoClassDefFoundError: org/apache/solr/search/QParserPlugin”

    Could anyone let me know please on which Lib directory i have to put “spatial-solr-2.0-RC5.jar”. I have read many forums in last 2 days and tried to put it on many libs but still not getting success.

  46. April 20, 2013 at 04:45 by projector screens

    Great information. Lucky me I found your blog by accident (stumbleupon).
    I have book-marked it for later!