Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change 
notification.

The "SolrAdaptersForLuceneSpatial4" page has been changed by DavidSmiley:
http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4

Comment:
1/2 way though

New page:
Note: This page is a working draft of documentation.  It needs to be 
migrated/merged/moved/renamed into the existing Solr spatial wiki content 
somehow.

= Lucene / Solr 4 Spatial =

This document describes how to use the new spatial functionality in Lucene / 
Solr 4.  The bulk of the implementation lives in the new Lucene spatial module 
in v4 committed on March 13th.  It replaces the former "Lucene spatial contrib" 
in v3.  The Solr piece is small as it only needs to provide field types which 
are essentially adapters to the code in the Lucene spatial module.  
Furthermore, understand that the shape implementations and other core spatial 
code that isn't related to Lucene is held in another new open-source project 
called Spatial4j.  Presently, polygon support requires an additional dependency 
-- JTS.  As of this writing, 28-June 2012, the Solr portion has yet to be 
introduced into Solr trunk. It should come into Solr via SOLR-3304 "soon".


== New features, over Solr 3 spatial ==

Note: "Solr 3 spatial" refers to the spatial support introduced in that version 
of Solr which still exists in v4.  Solr 3 spatial does ''not'' actually use 
Lucene 3's spatial contrib module aside from DistanceUtils.java.

These features describe what developer-users of Lucene/Solr 4 will appreciate.  
Under the hood, it's a framework designed to be extended for different 
so-called spatial strategies.  I'll assume here the RecursivePrefixTreeStrategy 
as it should address most use-cases and it's has the best tests.

 * Multi-value indexes.  This is key for any project that geocodes natural 
language documents, since a variable number of locations are extracted from 
text.
 * Index shapes with area, not just points.  An indexed shape is essentially 
pixelated (i.e. gridded) to a configured resolution per shape.  Note: If 
extremely high precision of the edges of the shape needs to be retained for 
accurate searching, then this solution probably won't scale well compared to 
other approaches such as those that index the bounding box but retain the 
original shape vector.  Note: this capability sorely needs testing.
 * A polygon shape.  It can be the indexed shape or query shape.  Note: This 
requires the JTS dependency.  The polygon assumes a Mercator / Cartesian 
projection, and consequently doesn't support pole-wrap.  As of 1 June 2012 in 
Spatial4j 0.3-SNAPSHOT, it does support dateline crossing.
 * Multi-value distance sort / score boost.  Note: this is a preliminary 
unoptimized implementation that uses a fair amount of RAM. 
 * Configurable precision which can vary per shape at both index & query time.  
This enhances the performance.  Solr 3 indexes and queries based on the full 
precision of a double for latitude and longitude, which is excessive for nearly 
any use-case.
 * Fast filtering.  The code was benchmarked once showing it outperforms Solr 
3's "LatLonType" at its own game (single valued indexed points), and a 3rd 
party anecdotally reported it was faster on his large index.  It hasn't been 
benchmarked in well over a year now though, and this is a TODO item.  Also, 
Solr 3 LatLonType sometimes requires all the points to be in memory, whereas 
the new spatial module here doesn't for filtering.

Of course, the basics in Solr 3 not mentioned here are implemented in this 
framework.  For example, lat-lon bounding boxes and circles.

= How to Use =

== Configuration ==

== Indexing ==

== Search ==

== Final Notes ==

Reply via email to