Dear Wiki user,

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

The "SpatialSearch" page has been changed by chrismattmann.
The comment on this change is: added some basic information from Patrick 
O'Leary's Local Lucene site on Tiers..
http://wiki.apache.org/solr/SpatialSearch?action=diff&rev1=7&rev2=8

--------------------------------------------------

  <<TableOfContents(3)>>
  
  = Introduction =
- 
  Many applications wish to combine location data with text data.  This is 
often called spatial search or geo-spatial search.  Most of these applications 
need to do several things:
  
   1. Represent spatial data in the index
@@ -17, +16 @@

  Most of these items are being tracked on 
https://issues.apache.org/jira/browse/SOLR-773 and it's related issues.  The 
goal is to bring spatial search into Solr in such a way as to leverage all of 
Solr's existing capabilities for distributed search, etc.
  
  = An Example =
- 
  On https://issues.apache.org/jira/browse/SOLR-1131, the example schema was 
changed to provide information about what store the products were located in.
  
  The schema changes look like:
+ 
  {{{
  <fieldType name="location" class="solr.PointType" dimension="2" 
subFieldTypes="double"/>
  
  <field name="store" type="location" indexed="true" stored="true"/>
  }}}
+ In the example docs, for example: hd.xml, the document now has:
  
- In the example docs, for example: hd.xml, the document now has:
  {{{
- 
    <field name="store">45.17614,-93.87341</field>
  }}}
  in addition to all the other fields.
  
  Then, to query, the system can use the distance Functions in Solr, as in:
+ 
  {{{
  http://localhost:8983/solr/select/?q=_val_:"recip(dist(2, store, 
point(34.0232,-81.0664)),1,1,0)"&fl=*,score
  }}}
- 
  The above computes the [[http://wiki.apache.org/solr/FunctionQuery#dist|the 
Euclidean distance]] from the lat/lon pair (34.0232,-81.0664) to the store's 
lat/lon, asking SOLR to 
[[http://wiki.apache.org/solr/FunctionQuery#recip|invert the distance]] (take 1 
/ the distance) in order to make longer distances come later in the result 
list, and finally asking SOLR to return all fields, including the relevancy 
score.
  
  = Data Representation =
- 
  One of the keys to data representation is the ability to represent points, 
etc. in multiple different ways.  Some times, a user may want a 
[[http://en.wikipedia.org/wiki/Geohash|Geohash]] and other times they may want 
Cartesian tiers or just simple lat/lon.
  
  == Points ==
- 
  === Numerics ===
- 
  The Trie* fields are perfect for representing lat/lon in two distinct fields. 
 Additionally, as of https://issues.apache.org/jira/browse/SOLR-1131, there is 
now a !PointType that supports transparently representing a point in 
n-dimensional space
  
  === Geohash ===
- 
  A geohash is a way of encoding lat/lon into a single field as a String.  As 
of https://issues.apache.org/jira/browse/SOLR-1586, it will be possible to 
create a geohash via FieldType, simply by passing in a Point (lat,lon).  Solr 
will do the work of converting the point to a geohash.
  
  See http://www.geohash.org and http://en.wikipedia.org/wiki/Geohash
  
  === Tiers ===
+ (The following information is best described on the 
[[http://www.nsshutdown.com/projects/lucene/whitepaper/locallucene_v2.html|Local
 Lucene White Paper]]. Thanks to Patrick O'Leary for providing this 
information.)
  
- <!> TODO <!>  Fill in more on Tiers
+ A Cartesian tier is the result of first flattening the world (using a 
Sinusodial projection) and then dividing up the world into 2^n grid boxes. Each 
tier (called "n") covers a particular area of the flattened earth, and as n 
grows bigger, so does the tier resolution. That is, tier 2 is at a much coarser 
resolution than say tier 10 that covers the same area.
  
  See https://issues.apache.org/jira/browse/SOLR-1586 for the 
CartesianTierFieldType, which can index points into tiers.
  
  = Indexing =
- 
- 
- 
- 
  = Filtering =
- 
  There are several different ways to filter in spatial search:
  
   1. By Range Query, as in {{{fq=lat:[-23.0 TO -79.5] AND lon:[56.3 TO 
60.3]}}} -- Already implemented
@@ -77, +67 @@

   1. Using the "frange" QParser, as in {{{fq={!frange l=0 u=400}hsin(0.57, 
-1.3, lat_rad, lon_rad, 3963.205)}}}
  
  = Sorting =
- 
  https://issues.apache.org/jira/browse/SOLR-1297 added the ability to sort by 
function, so sorting by distance is now simply a matter of sorting using the 
appropriate distance function, just like boosting.
  
  = Scoring =
- 
  Scoring by distance works just like any other FunctionQuery.  See the 
distance methods on the FunctionQuery page for examples and method signatures.
  
- 
  = Query Parsing =
- 
  <!> TODO <!>
  
+ https://issues.apache.org/jira/browse/SOLR-1578 See 
https://issues.apache.org/jira/browse/SOLR-1568
- https://issues.apache.org/jira/browse/SOLR-1578
- See https://issues.apache.org/jira/browse/SOLR-1568
  

Reply via email to